Thread

👀

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

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.

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.

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.

I still think we should just have a regular event for follow and delete it to unfollow

You'd have to download ~250000 events to build basic web of trust though, I just don't feel it's worth it