@prologic@twtxt.net When I first started using twtxt, I was fascinated by the fact that it’s just a simple text file. This is already undermined a lot today by us using multiline replies and Markdown and what not. Still, I would love to retain this property of it being just a file that needs very few external tools to maintain. (Jenny is quite bloated, one might argue. One of the reasons for even starting the jenny project was the calculation of hashes – I was using a smaller, simpler toolchest before.)

If we were to use (replyto:…), I could just copy and paste the required info into my text editor. With echo … | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that there’s no trailing whitespace in the content, little details like that. It is more effort.

This probably isn’t the best argument for (replyto:…), but it is an argument.

Would people do all this manually? I don’t know. Probably not. But part of the fascination with twtxt is that you could do it.

I’m speaking from a point of extreme minimalism here and all this isn’t strictly only related to (reply:…). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require less. Like, don’t solve edits breaking threads by adding another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesn’t need another building block on top.

This is all I have to say for now. 😃 I’m gonna let things cool off for a while.

@movq@www.uninformativ.de So I obviously happen to agree with you as well. However in so saying, one of my goals was also to bring the simplicity of Twtxt to the Web and for the general “lay person” (of sorts). So I eventually found myself building yarnd. Has it been successful, well sort of, somewhat (but that doesn’t matter, I like that it’s small and niche anyway).

I agree that the goal of simplicity is a good goal to strive for, which is why I’m actually suggesting we change the Twt identifiers to be a simple SHA256 hash, something that everyone understand and has readily available tools for. I really don’t think we should be doing any of this by hand to be honest. But part of the beauty of Twt Subject and Twt Hash(es) in the first place is replying by hand is much much easier because you only have a short 7 or 11 character thing to copy/paste in your reply. Switching to something like <url> <timestamp> with a space in it is going to become a lot harder to copy/paste, because you can’t “double click” (or is it triple click for some?) to copy/paste to your clipboard/buffer now 🤣

Anyway I digress… On the whole edit thing, I’m actually find if we don’t support it at all and don’t build a protocol around that. I have zero issues with dropping that as an idea. Why? Because I actually think that clients should be auto-detecting edits anyway. They already can, I’ve PoC’d this myself, I think it can be done. I haven’t (yet), and one of the reasons I’ve not spent much effort in it is it isn’t something that comes up frequently anyway.

Who cares if a thread breaks every now ‘n again anyway?