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

@lyse@lyse.isobeef.org This is why hashes provide that level of integrity. The hash can be verified in the cache or archive as belonging to said feed.

@prologic@twtxt.net So, this is either me nit-picking or me not understanding the hash system after all. 😃

An edit twt would look like this:

2024-09-20T14:57:11Z    (edit:#123467) foobar

So we now have to verify that #123467 actually exists in this same feed. How do we do that? We must build a list of all twts/hashes of this feed and then check if #123467 is in that list. Right?

You’re kind of implying that it would be possible to cryptographically validate that this hash belongs to this feed. That’s not possible, is it? 🤔

@movq@www.uninformativ.de Is t it? You read each Twt and compute its hash. It’s a simple O(1) lookup of the hash in that feed or your cache/archive right?

@prologic@twtxt.net Okay, looks like I misunderstood/misinterpreted your previous message then. 👌

@movq@www.uninformativ.de Am I missing something? 😅

@prologic@twtxt.net Nah, just language barrier and/or me being a big stupid. 🥴 All good. 👌

@movq@www.uninformativ.de Ok 😅

@lyse@lyse.isobeef.org Yes you do. You keep both versions in your cache. They have different hashes. So you have Twt A, a client indicates Twt B is an edit of A, your client has already seen A and cached and archived it, now your client fetches B which is indicated of editing A. You cache/archive B as well, but now indicate in your display that B replaces A (maybe display, link both) or just display B or whatever. But essentially you now have both, but an indicator of one being an edit of the other.

The right thing to do here of course is to keep A in the “thread” but display B. Why? So the thread/chain doesn’t actually break or fork (forking is a natural consequence of editing, or is it the other way around? 🤔).

If OTOH your client doesn’t store individual Twts in a cache/archive or some kind of database, then verification becomes quite hard and tedious. However I think of this as an implementation details. The spec should just call out that clients must validate/verify the edit request and the matching hash actually exists in that feed, not how the client should implement that.

@lyse@lyse.isobeef.org This is true. But the client MUST supply the original too! Or this doesn’t work 😢

i.e: there must be two versions of the Twt in the feed.