@<lyse https://lyse.isobeef.org/twtxt-2021-02.txt> "@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."

Sun, 14 Feb 2021 19:00 Z (3 years ago)

@anth@a.9srv.net @movq@www.uninformativ.de @prologic@twtxt.net @darch@twtxt.net @xuu@txt.sour.is 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.

#tfe43va