…#v5yaeha) @anth @lyse @movq Actually... I _think_ we could change the Twt Hash extension a bit here and remove the need to fully qualify and expand them into full URLs. The reason we did that in the f…

(#v5yaeha) @lyse Yes, I often read the raw messages. But more to the point, the simplicity of the format is the bulk of the appeal.

(#v5yaeha) @movq No argument that threading is an improvement. But I think (#hash) does that, and I think figuring out how to search should mostly be up to the client.

(#v5yaeha) I don't have any issue with the (foo) subjects, it's the proliferation of the (foo url) tags. They're just too long and ugly.

(#v5yaeha) And just to be clear, without the work on twtxt.net by @prologic and you other people, twtxt would be very very dead now. That would be a shame. I really appreciate your efforts!

…e (#v5yaeha) 100% agree. Fun fact: Couldn’t we actually do that? I mean `timestamp \t twt-id \t reply-id \t text`. Older clients would just include the IDs in the message, but they wouldn’t break. (I …

…ogic @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 c…

…gic @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 …

…h @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 subj…

…h @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 subj…