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?

@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.

It just occurs to me we’re now building some kind of control structures or commands with (edit:…) and (delete:…) into feeds. It’s not just a simple “add this to your cache” or “replace the cache with this set of messages” anymore. Hmm. We might need to think about the consequences of that, can this be exploited somehow, etc.