I state pretty clearly in the article that I understand that isn’t how relay selection works now or will ever work.

You can be much more conservative with the numbers and you will still ultimately come to the same conclusion. There are already clients saying they are going to randomize client relay lists.

Even if only 10 or 20% of your follows randomizes relay selection, if there are many relays to choose from and you want to read from 2 per user for redundancy the connection overhead grows rapidly.

“We won’t ever spread out that much”might be true but it’s a pretty poor defense of the scale.

Somehow then I got labeled as a big relayer who hates all small relays and decentralization 🤷‍♂️

Reply to this note

Please Login to reply.

Discussion

most clients are pretty random... some probably feed off relay data spidering services even... with how they select your relays

the client-focused solution is contained in NIP-65 and requires NIP-42 to gate access on read and write side for various reasons i'm sure you are aware of

i keep hammering at NIP-42 because i see it as the biggest blocker for progress right now, and until every client supports it i am not gonna stop screeching at the client devs, i have even been blocked by one or two so i'm not unaware of how repetitive i'm getting

Hahah, ah man. Don't worry, we know you don't hate relays nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz. 😅

I do think that gossip pooling requests onto a set of connections that is based on everyone's relay list will scale ok.. but it is very hard to see it in action until everyone's clients start doing smarter things to help them manage their nip65 list.

Randomizing does not seem very smart.. more of an invite system, where you get an invite that contains a small relay set to start. (Like Japan invites someone, they get some Japan relays that make sense). Once those first few relays connect, it's easy to crawl the relays from that starting point..