I know we've had like a billion proposals for conflict-free lists, but I think I found a pretty clean way to fix them:
https://github.com/nostr-protocol/nips/pull/2123
Follow list nuking continues to be very common. This PR basically just upgrades kind `1xxxx` into kind `3xxxx` lists in order to avoid conflicts.
I can already say now, that this change, will make the situation much worse than it already is.
Adding complexity to the protocol, with the introduction of data fragments like this, will create a whole set of other issues.
Each app should simply keep a backup of the following list, perhaps a historical backup and potentially some merge functionality. That's enough to mitigate this problem, doesn't need added protocol complexity.
That's not any less complex, and doesn't solve the case where a user visits a new app that is poorly coded. In my PR, well-written apps can protect users against poorly-written apps
All backends must be updated.
All frontends must be updated.
This will be more complex, you will have clients that suddenly supports way more following list than standard kind 3, what then? You have massive fragments between the apps that the user uses.
How does one choose which of the thousands of following to keep in sync with the legacy kind 3?
There are so many potential scenarios that is problematic already today, this introduced its own set of scenarios that must be handled and mitigated, not just by frontends, but also backends.
My notification service will now need to listen to both kind 3 events, and to multiple 33000, and have some advanced logic other than: "send notification to the last pubkey added to the list".
I get the wish for this, but I'd rather not extend existing patterns with even more complexity, if it doesn't really bring a whole lot of benefits that makes it a no-brainer.
No relays need to be updated, and clients that want to adopt the new nip need to be updated. Your service can keep using kind 3, especially because it doesn't have to care about lists getting nuked because it only checks new entries.
Slight discrepancies between which lists have which entries is much better than catastrophic data loss. This NIP also allows clients that fail to fetch a user's list to add follows with confidence, and repair kind 3 when they're eventually found.
