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