Rabble on Nostr: We’ve got an issue with a few event types in Nostr. Most of the time an ...

We’ve got an issue with a few event types in Nostr. Most of the time an individually signed event without any kind of signature chain is a huge advantage. It makes Nostr faster and simpler.

But in the case of replaceable events we have a problem. Clients are getting old versions of lists and then updating those and republishing them. It accidentally removes follows / mutes / bookmarks / curation lists.

There are a bunch of potential solutions to this problem that we can see in other related protocols. We just need to pick one and adopt it.

quoting note1gaa…mmtd

Putting the Nostr follow list into a single event was a mistake. Because there is no single source of truth in Nostr an app can never know if it has the latest version of the list before publishing a new version. If it doesn’t have the latest version of the list then the user loses data. This is true of every other kind of Nostr list too.

A better model would have been to publish a separate event for each follow with a single p tag, like this: `{ id: “1234...”, “pubkey”: “283h2ea12…”, kind: [follow], “tags”: [“p”, “2ekac887…”] … }`. When you follow someone you just publish a new follow event. When you unfollow someone you delete the event. Or if you hate delete you can publish a new “unfollow” event for that person, it’s really the same thing. This is how Secure Scuttlebutt models the follow graph and it works well enough.

If you want to get really fancy you could arrange all the follow events in a tree and use a CRDT or use range-based set reconciliation to make an eventually consistent list of people you are following. This is how the Willow protocol works if I understand it correctly. But that is way too fancy for Nostr, which is kind of predicated on the idea that things are simple to implement and the UX is good enough.