↳ In-reply-to » I’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to add stuff to the protocol.

@prologic@twtxt.net Kind of. But the (edit:) spec has similar problems in its current form:

1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
   
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
   
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
   
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
   
5. Delete your first update from your feed, the one with the birds. Not with (delete:), just remove the line.
   
6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”
   

You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.

This raises two questions:

• The easy question: What do we do when the twt that an (edit:) line refers to is removed later on from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.
  
  • The result being a thread without a root, just like it is today. That’s fine.
    
• The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the (replyto:) situation, I think. 🤔