nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpzpmhxue69uhkummnw3ezumt0d5hsqgzxpsj7dqha57pjk5k37gkn6g4nzakewtmqmnwryyhd3jfwlpgxtsphu0c4 nostr:nprofile1qqs0cuy9cwpm5ut52uztmswxal8hl2cpjagpmevcchnv2davpve2fjcj0xusc I don't want to read all the old PRs so I will rely on your memory to tell me if this has been proposed before.
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.
Discussion
Not a bad concept, but I don't see this actually deprecating Kind 3 or any of the NIP-51 lists.
Also, you are turning the risk of one race condition into many smaller race conditions.
Your PR is original afaik, interesting one.
The idea of creating a shard only when you couldn't find a previous one on relays does would stop a client from inadvertently resetting a list.
I couldn't find directions on preventing a said event kind from multiplying too much. I guess if a client retrieves many shards, the best thing it can do is to merge them into one.
Yeah, I almost specified that "clients may consolidate" but I really don't think a lot of shards will end up existing. Plus, the whole nip creates a flexible structure that could be used in other more sophisticated ways to further reduce the odds of a collision.