Replaceable events vs Versioned events -- Signalled Replacement

[mikedilger]

Right now, if a relay receives a replaceable (or addressable) event newer than a previous one, it can delete the previous one.

But we have multiple problems with this

• The previous one might not have been taken into account by the client publishing the new one, leading to things like contact list clobbers
• People sometimes reply to the previous event, and if relays are deleting it, the history of what they actually replied to gets lost.

I suggest we solve these in the following way:

1. Create a new tag supersedes with the event IDs of the old events that a newer event intends to replace. This signals that the client/author accounted for these specific previous events and that the newer event supersedes them. This doesn't need to be "e", or even searchable, but does need to specify event IDs. If a prior event wasn't specified, relays don't remove it, and clients can still find it and so destructive clobbers will only still happen by really dumb or malicious clients (IMHO CRDTs are still needed for syncing these forked event and forked events at other relays, and this change would make them work better).

2. Versioned events just don't specify such tags, and so the multiple versions persist.

This would be a breaking change.

Unlike #1634 it would not require AUTH or a separate REPLACE verb since the events being replaced are inside the author-signed event. And the replacement data would propogate as other relays and clients became aware.

[vitorpamplona]

Let's say:

1. Relay 1 and 2 get v1.
2. While Relay 1 is offline:
   2.1. User Updates Relay 2 from v1 to v2, deleting v1
   2.2. User updates Relay 2 from v2 to v3, deleting v2
3. Relay 1 comes back online:
   3.1 User tries to update both relays from v3 to v4: Relay 1 fails, Relay 2 works.

In order to bring Relay 1 up to speed, the user must publish the old v2 to Relay 1. But v2 is not in any relay anymore. Relay 1 then gets stuck in a past version.

[mikedilger]

Relay 1 doesn't get stuck.

You can publish v4 to relay 1. Then relay 1 will contain 2 events: v1 and v4. Users will notice v4 is newer and what happens next is based on the kind and the understandings about that kind

case 1: If the kind is known to always be replaceable (rather than versioned) users getting both events would just use v4 and ignore v1. The author can delete v1 two ways: add the ID to the next version as superceded, or use a kind-5 (nip-09) delete

case 2: If the kind is known to be versioned, the old versions are not a problem they are intentional.

Also you can put multiple 'superseded' IDs into these events.