This is gossip protocol like in hashgraph?
Discussion
This allows clients to essentially go out and find the relays where an npubs notes are located so you don't have to technically have a relay in common. This enables relays to be decentralized and clients to do the legwork to find the content based on the relays attached to the nprofile.
At least that's how I see it. I could be slightly incorrect in my understanding here nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 are experts on this topic and can help correct me.
yes, that;s correct.
This model depends on self-reported data, which is the thing that I find problematic on the gossip protocol; the way NDK will extend this is (doesn't yet but I already laid down the infrastructure for it) it'll keep a score of the number of events for different pubkeys it sees in different relays and will add into different pubkey inferred relay lists.
So yeah, the intent here is to further decentralize. I'm going to be experimenting with penalizing relays that are at the top of the list of many npubs to try and favor smaller relays (if it doesn't impact speed/event visibility).
The idea is that, sort of like bitcoin miners abandon pools when a pool becomes too powerful, NDK-based clients could favor smaller relays if a vast amount of events are happening in a handful of relays.
(Again, this behavior would only be triggered if it doesn't sacrifice speed/finding events)