I agree with everything you said and updated the article to more clearly acknowledge the shortcomings.

I know this isn’t how relay selection works in the wild but my goal was to show that if we succeed in enabling more diverse relay sets the issue gets worse. If the end goal is to increase relay diversity than the solution should be something that scales well with accomplishing this goal.

If we think we are destined to end up on 10-20 hubs anyway then why wouldn’t some of those hubs just aggregate from small user relays? That’s a real value prop for users. Why gossip at all?

Reply to this note

Please Login to reply.

Discussion

Because those hubs would then have the ability to censor the network. Very few people will get censored, but it's important that they not be demoted in nostr's "algorithm" as a result of a handful of relays (which are under greater scrutiny because of their scale) decide to "curate" their database. If someone's write relays don't include the big 10, clients shouldn't expect to find their notes there.

the goal is not to randomly distribute to to network. One of the things that nostr got very right is not trying to optimize for non-natural edge-cases.

the goal is censorship-resistance, that means that a censored person should not become a second-class citizen. They should be able to very easily move to their a new/their own relay and users interested in that pubkey should not even be able to tell that the person was censored.

And even if you are not concerned with censorship-resistance, niche/specialized relays not being second class citizens and *just working* for users is a MASSIVE win for everybody.

NIP-65 doesn’t even mention the word censorship. The motivation talks about centralization in large relay operators and duplication of events throughout the network.

Is it not reasonable to assume that at least part of the goal was to allow the spread of user events out to different relays?

The more we spread the events the worse gossip performs. Isn’t that a problem? It seems weird to me that our solution for censorship resistance breaks if too many people exercise the option.

That's fair, maybe that section could be re-worded. But it is an accurate, if incomplete problem statement. The current very naive use of the network is maximum duplication (looking at you, blastr). Reducing duplication by centralizing content is better in one dimension (resource allocation), but worse in another (redundancy). A good solution will balance those concerns.

The original motivation behind NIP 65 didn't grapple with the problem you're articulating (I brought this up in at least two TGFN podcasts last fall). But fiatjaf persuaded me that it basically doesn't matter, because the network will never be anywhere near fully distributed.

I think he’s probably right about that for now but even if we only partially distribute as nostr scales the connections number will still be high.

Even if we stick with just 600 relays (no growth) and say only 10% of your follows choose their relays at random instead of 100%. We assume the other 90% all select the same 1 relay. If you follow 1000 people that’s still ~170 unique connections on average without the network being very distributed.

I don't think so, if you have 1000 follows, and 900 of them are on one of 20 relays, that's 20 hubs + 100 self-hosted relays, a maximum 120 connections. In practice you're probably closer to 60-80. Which is still a lot! So proxies are useful for reducing that number, but even 100 connections isn't prohibitive.

10% choose 2 relays at random from the pool not self-host one each.

Perhaps you could get away with only one connection per user though depending on how they labeled them.

I think people who are most at risk of censorship (and have a following that wants to view their content) are the ones who will run their own relays and the people who want to follow them will happily add those.

As long as nostr is open and interoperable and users own their identity and events - it doesn’t have to be perfectly decentralized.

This is equivalent to saying people can always switch clients if the client starts censoring. That has major costs in terms of user experience.

Imagine I'm following Alex Jones, and the hub relay I use starts censoring him. Not only do I not get any notice that that's happened (shadow bans are notoriously hard to detect), I have to manually find his relay out of band and add it to my client to see his material again. The gossip model (in its ideal form) is just the client doing this automatically.

How would you know his kind 10002 changed if the relays you’re on are censoring him?

Relay hints.

Kind:10002 relays.

The next time I reload his metadata, I would pull it from all relays in his old 10002. This would fail only if the old 10002 only specified relays that had banned him. This is unlikely for anyone high profile enough to be banned, they're definitely going to run their own relays and publish those selections just in case.

It's easy, if Alex has a nip05 of alex@infowars.com he just updates it.. 💥💥💥 gossip+nip05 is unstoppable..

That's a great point

Agreed. I think we should go back to encouraging relays in NIP-05. Having an out of band option seems like an important backup.