Subnostr

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

Reply to this note

Please Login to reply.

Discussion

cloud fodder 1y ago

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 1y ago

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 🤷‍♂️

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

cloud fodder 1y ago

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

cloud fodder 1y ago

Did you catch all the relay talk last week? Just curious.. haha, this article was part of what kicked it all off, a proper nostr festival 🎉

someone 1y ago

which talk? I just saw this article

cloud fodder 1y ago

Lots of discussion about big relays, small relays, gossip outboxes, inboxes.. 🤔

VelvetBlue_art 1y ago

All things reach a scaling problem.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

oof... totally not the right way to do it

needs to be much more open than that

we have NIP-65 so that users can pick where they want to use (including, where supported, AUTH restricted access paid relays - if the damn clients would damn well implement it, damnit!) and they advertise those around, and the various gossiping, syncing relays that want to catch everything specifically should ensure they catch these ones, above all else

as for expanding the storage capability in a collective sort of way, you could have federations of relays that link up to a common large storage back end, or several

there is already massive ad-hoc replication of data on the network, and i see no problem with this but for larger blobs of the system like these shared back end stores (i'm working on a project involving one) definitely there is no practical way to make a One Ring of Relays To Rule Them All you are totally missing the point of what makes nostr good, it's that permissionless, ad hoc, disorganised structure, it's not a bug, it's a feature

i mean, yes, you could have this sort of solution at some level but pushing it out into the main protocol would be completely impractical and nobody would ever agree with shrinking our censorship resistance and permeability this much

fiatjaf 1y ago

This is just turning relays into a stupid DHT. Mazin's assumptions are ridiculous because no way in the real world someone will be following 1000 people each in a different relay, or even 2 per relay, or 5 relays. The average will much more likely be closer to 100 per relay. Most people will do just fine in big relays or relays that accept people from a certain group (remember the Bitcoin Mastodon server from nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8?).

Stop treating Nostr as a p2p network.

someone 1y ago

So 10 big relays are better than current situation? How do you measure decentralization?

I think premium/freemium model will allow relays to specialize in providing certain services. Right now choosing the top free relays makes sense because they are no different, yet more popular. But having special freemium features for users can allow relays to differentiate and attract more users. Having an economy will allow more diverse set of features and actors within the game. A smaller relay can just copy the service but offer more cheaply and get noticed.

What do you think? Do u think premium/freemium for my relay will help Nostr as a whole in the end? I don't want the headache of freemium but if it helps Nostr, why not.

fiatjaf 1y ago

As you noticed, this breaks the idea that relays are privately owned and can impose any restrictions they want on anything, which is fundamental for incentives to be aligned, so even if it was a good idea to make Nostr a DHT it still would not work in practice.