These numbers don't make any sense to me. 200 follows, with 2 relays each == 291 connections? This ratio is nowhere near what I think the reality is or will be.
Mazin from nostr.wine wrote this convincing article where he says having gazillions of connections is not a good idea.
https://habla.news/u/mazinkhoury.com/1710959004510
I agree. This huge # of connection requirements won't work. Especially on mobile. If we were RSS syncs, it could. But we are more like twitter. People want real time interaction imo.
A way to decentralize relays could be:
Let there be 8 big relays.
relay 0 only accepts event id's ending with 000
relay 1 ending with 001
...
relay 7 ending with 111.
Kind of like RAIDs. If you want more reliability do 16 and there will be 2 copies of each.
All relay ops should go along with this vision of course... Politics needed.
It will also reduce the amount of duplication of events (less mobile traffic) for clients.
It will also reduce the amount of data each relay has to hold and forward..
Each big relay will be responsible for 1/8th of what is happening on Nostr (I mean I don't want to be responsible for all the illegal stuff on Nostr, lol)
The institutions that want the stuff banned on Nostr will see at least 8 different operators when they want to contact Nostr. I know some institutions already contacted client devs for stuff like copyright issues..
But some relays are paid. It will be hard to incorporate paid relays into this equation: "Hey I paid for this relay, why can't I write to it? What do you mean sharding?"
What will happen to the 9th biggest and so on? Well every operator chooses a shard from the list 0 - 7. Whatever the relay chooses it advertises on NIP-11.
When a relay doesnt behave, we all booo it.
If things go wrong, instead of 3 now you have 8 people to deal with, lol.
Thoughts?
nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
Discussion
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 🤷♂️
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..