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)