@movq@www.uninformativ.de @prologic@twtxt.net Another option would be: when you edit a twt, prefix the new one with (#[old hash]) and some indication that it’s an edited version of the original tweet with that hash. E.g. if the hash used to be abcd123, the new version should start “(#abcd123) (redit)”.

What I like about this is that clients that don’t know this convention will still stick it in the same thread. And I feel it’s in the spirit of the old pre-hash (subject) convention, though that’s before my time.

I guess it may not work when the edited twt itself is a reply, and there are replies to it. Maybe that could be solved by letting twts have more than one (subject) prefix.

But the great thing about the current system is that nobody can spoof message IDs.

I don’t think twtxt hashes are long enough to prevent spoofing.

@falsifian@www.falsifian.org Yes;

I don’t think twtxt hashes are long enough to prevent spoofing.

The current spec needs to be updated to expand the hash length to 11 characters to avoid hash collisions (which will happen at some point with 7, if not already).

The issue isn’t dealing with “spoofing”, it’s about solving how clients in a decentralised model agree on the threading model and identity of a thread. Message ID(s) suffer from the fact that as @movq@www.uninformativ.de points out, clients have to “obey” this unwritten rule, but they’re otherwise just arbitrary. Whereas Twt Hashes (I didn’t come up with the idea originally, some smart fellow in cryptography did) are content addressable, meaning that clients don’t have to agree on anything, they can trust that the hash is a cryptographic representing of the thread they’re replying to, no matter what.

@prologic@twtxt.net you wrote:

“[…] they can trust that the hash is a cryptographic representing of the thread they’re replying to, no matter what.”

It isn’t about trust, is it? There has to be some kind of check to verify the hash is valid, no?

@bender@twtxt.net Sorry, trust was the wrong word. Trust as in, you do not have to check with anything or anyone that the hash is valid. You can verify the hash is valid by recomputing the hash from the content of what it points to, etc.