Use same name within thread by default?

Would it be possible to have (possibly implemented as a checkbox to the right of the Name field) same-name-per-thread? Not anything "rigorous" like mandatory tripcodes, Not something to try to be "obvious" if someone were stirring soykaf But just for convenience in sorting out discussions (If I enter something in the Name field as-is, right now that "leaks" to other threads if I don't keep an eye on it)

liek so (only, if it would actually make me "Nell" in this thread)

no

>>5124 It would be possible to implement , but such a setting would be unlikely to be the default and would probably require client side post tracking as a minimum in order to implement.

>>5132 The names are already randomly selected, right? What if we switched this "random" seed from being randomly generated every single post to just be a hash of, say the post deletion password concatenated/salted with the OP? (including metadata such as board name, thread number, attachment name+size, etc)

>>5134 and said setting could still / even so be optional Like if the checkbox is checked, it uses the hash of your post's password plus the OP to randomly select the username and if it's unchecked, then it just selects it via the normal way

One theoretical vulnerability/pitfall I see is that someone could take the OP and a targeted user's username in a given thread, and use it to crack someone's post-deletion password in an offline/parallelized manner, which is an unacceptable risk The first solution that immediately comes to mind is to just include the OP's password in the salt, (but that is circumvented if the OP decides to publish/use his knowledge of his password to try to crack someone's password) The next solutions that immediately spring to mind are using hashed versions of the poster's (or, even, the OP's password) as inputs to the seed, but those fall apart for similar reasons. next idea is to use hashes of both the OP's and the poster's password as inputs to the seed, but I still don't like this since OP could still offline-bruteforce the hashes, at which point (passwords being not excessively long) it's a feasible journey from there (especially with rainbow tables) to extract the original password But the solution I think would work is have a secret server-wide (or board-wide, or thread-specific, even) password which gets XORed with the OP and poster's password The latter one sounds like the best course of action: airtight and not resource-intensive. It frees you up to use some random weak-ass quick hash function for the seed generation, too. Or does this sound like too much consideration/work/headache for a small feature?

>>5137 It does sound like too much work for a small feature. The whole concept of a random seed seems like too much work in general. The one implementation detail I am not sure about is how this works when posting from overboards when OP is not known for a post on the client side alone.

>>5139 I'm thinking it would be handled server-side, since if the entire thing can be calculated client-side, then it could be used to bruteforce passwords offline (unless someone more versed than I in crypto sees a way around this. I highly suspect there is one; there's just no "out" immediately obvious to me)