Trying to sum up the current proposal (keeping hashes):

1. Extend the hash length to avoid collisions.
   
2. Introduce the concept of, what shall we call it, “update twts”.
   
   • A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
     
   • A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
     

Right?

For implementations, it would be nice if “update twts” always came after the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will have to be able to cope with any order, because feeds cannot/should not be trusted. 🫤

@movq@www.uninformativ.de Thanks for the summary!

So, what would happen if there is no original message anymore in the feed and you encounter an “edit” subject? Since you cannot verify that the feed contained it in the first place, would you obey it?

Some feed could just make a client update something from a different feed. In the cache, the client would need to store in a flag that this message was updated, so that when it later encounters the message from the real feed, it has a chance of reverting that bogus edit. Hmm. The devil is in the detail.

It’s much easier with a delete subject. When it finds the message in its cache and the feeds match, remove it. Otherwise, just ignore it.