@anth (#v5yaeha) I was reluctant, too, at first, but proper threading seriously improves the twtxt experience. This should have been built-in from the start.

(#v5yaeha) @movq I _really_ appreciate you saying this! Thank you! 🙇‍♂️ To be fair @anth we just took something that we were observing happening in the real-world and "formalized" it. You can thanks @dbohdan for the initial work on Twt Hash(es) really, and @lyse for making a a format document for it!

@anth @movq @prologic (#v5yaeha) The hashes are certainly not very elegant, but as an afterthought make the twtxt universe much more pleasant as movq said. Are you really reading the twts in in its raw form, anth?

(#v5yaeha) @lyse How _could_ they be made "more elegant"? 🤔 Is it just a presentation thing? (UX)?

(re: #v5yaeha) @prologic @lyse @anth One way to make the raw txt easier to read would be to move the (hash) to the end of the line. Another thing would be to add `re:` to it so it would be cleared that code-thing is a reply or is in relations/reaction to something else (re: #v5yaeha) **EDIT:** right now the twt.social client does not allow you to move the (#v5yaeha) ...

(#v5yaeha) If we're strictly talking about about presentation / UX issues here, @xuu already largely solved this already in changes to how the parser works. See for example: It would just be a matter of stripping out the "Twt Subject" out now from the presentation layer. But somehow I don't think @anth is talking about this, or is using an old client with a more bland UX?

@darch > EDIT: right now the twt.social client does not allow you to move the (#v5yaeha) … No it does not. 🤣 Its meant to be "idiot proof"! Recall that the goal here is to bring the simplicity of what Twtxt provides to the masses. There's no good in having a set of standard well document specs if we don't follow them 😉

@darch @prologic (#v5yaeha) Technically it should be at the start.. Though the parser doesn't currently care where it is. Though that leads to artifacts like any random string inside perens becoming a subject.

@anth @movq @prologic @darch @xuu (#v5yaeha) In my opinion twt hash and subject ideally would be dedicated fields in a twt, similar to `Message-ID` and `In-Reply-To` e-mail headers. Something like `timestamp \t twt-id \t reply-id \t text`. But since twtxt was invented as simple "status" thingies, nobody thought of replies in the beginning, I reckon. And then it happend, what will usually be the case: people use it differently than originally imagined. So the twt hash and twt subjects were bolted on. It obviously works, but it also has its drawbacks. If the originating client would generate a globally unique ID, we wouldn't have the problem of updated twts breaking conversations.

@anth @movq @prologic @lyse @darch @xuu (#v5yaeha) Yes, the presentation layer can fix a few things. My client hides the subjects completely to save space and I rarely care about the exact hashes. For debugging they can come in handy.