Nostr is not decentralized nor censorship-resistant \ stacker news ~nostr

Nostr is not decentralized nor censorship-resistant njump.me/nevent1qqsr248ee8hlp0mx0xpq56d86dgzpygdmmc3ycugwelvzgj6p82dvpczyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6k694f0

2520 sats \ 31 comments \ @ek 22 May nostr

zaps forwarded to @fiatjaf (100%)

Peter Todd has been saying this for a long time and all the time I’ve been thinking he is misunderstanding everything, but I guess a more charitable interpretation is that he is right.

Nostr today is indeed centralized.

[…]

Peter Todd is right that if the way Nostr works is that you just subscribe to a small set of relays and expect to get everything from them then it tends to get very centralized very fast, and this is the reality today.

Peter Todd is wrong that Nostr is inherently centralized or that it needs a protocol change to become what it has always purported to be. He is in fact wrong today, because what is written above is not valid for all clients of today, and if we drive in the right direction we can successfully make Peter Todd be more and more wrong as time passes, instead of the contrary.

It’s not a long post but my summary is that network effects of the most popular relays are bad for censorship resistance on nostr.

Very happy that @fiatjaf talks about this.

view all related items

226 sats \ 15 replies \ @Undisciplined 22 May

Is this a young technology issue or inherent to how nostr works?

312 sats \ 11 replies \ @k00b 22 May

I think the honest is answer is that it’s unclear whether it’s young or designed in a way that causes it to inherently centralize. It could be either and it could be both.

The argument for it not inherently tending to centralization depends on there being at some future date many many relays. Nothing about the design guarantees or strongly biases it that way though. It mostly just allows for there being many relays which is presumed to be enough to cause it to happen.

331 sats \ 2 replies \ @k00b 22 May

An interesting thought experiment: imagine bitcoin's price didn't appreciate and there was no mining subsidy or tx fees paid to miners as part of the protocol. How decentralized would bitcoin be? It could be decentralized and censorship resistant if many miners found their own way to pay for the energy and equipment to mine, or did it for goodwill. It could have many wallets and L2's if non-miners were also intrinsically motivated to make them. In such a case the protocol doesn't need to change, merely the people do.

243 sats \ 0 replies \ @elvismercury 22 May

I forget if it was Adam Smith or Russ Roberts, but one of them said something like: any scheme that requires a new kind of man is doomed to fail. This seems like that.

52 sats \ 0 replies \ @k00b 22 May

All of that said, it might not matter if relays are mostly centralized. I'm still super excited about nostr because the identities are decentralized and that's where most of nostr's awesomeness comes from IMO.

115 sats \ 2 replies \ @om 22 May

Despite the initial cocky stance of @fiatjaf that "it works because it's not P2P", I think that this article and the emergence of rebroadcasters prove the exact opposite. It is very possible that in the future P2P networks would emerge such that every node of such a network could be used as a relay and they would all give the same results.

315 sats \ 1 reply \ @justin_shocknet 22 May

It working due to not being p2p has nothing to do with rebroadcasting, but that relays are literally web servers with SSL certificates and reachability. As such Nostr works in browsers where it's needed, also the "peers" being clients don't communicate with each other, they communicate as client-server infrastructure.

0 sats \ 0 replies \ @om 23 May

I believe "not P2P" refers not to clients not communicating with each other (which is fairly common) but relays not communicating with each other. And that creates problems because relays are out of sync. Rebroadcasting is one way to address the issue.

94 sats \ 4 replies \ @026180d3a3 22 May

I think domain names are designed to move things toward centralization for the simple reason of discovery and retention.

115 sats \ 3 replies \ @k00b 22 May

They do tend to cause gravity to form around certain names more than it would if names didn't exist. But, names exist because people want to know things by name and share them by name.

42 sats \ 2 replies \ @026180d3a3 22 May

Sure. But that convenience comes at an easily manipulated cost that totally subverts that purpose.

226 sats \ 1 reply \ @k00b 22 May

So we need a solution that gives people the things they want in a way that isn't easily manipulated.

100 sats \ 0 replies \ @026180d3a3 22 May

I'd replace "want" with "are searching for" but yes.

98 sats \ 2 replies \ @ek OP 22 May

It’s a client issue if I understood fiatjaf right. More clients need to check which relays are advertised by someone you follow and these relays need to be checked, not just the popular ones

10 sats \ 1 reply \ @Undisciplined 22 May

Ok, so potentially a client could solve this, which would make that client censorship resistant?

Considering that there will always be some concentration in the most popular clients, it seems like there will always be some concern about these issues.

70 sats \ 0 replies \ @justin_shocknet 22 May

Middleware solves this, but that also would run contrary to what @fiatjaf feels clients should be...

Imagine if your email client reached out to every mail server that you wanted to receive emails from... it would be unusable. This is Nostr today, and so everyone uses a few relays to minimize connections.

(in reality email has become this too due to anti-spam rules, now the overwhelming majority of email comes from big cloud)

A middleware would act like a email server does today, its always online receiving messages for bulk users, indexing, and serving them to your client efficiently. It would be no more centralized than email, but still better due to Nostr using signing/encryption natively that could better resist centralizing forces.

Primal is the only Nostr client I'm aware of that's doing something like this, and therefore most usable. I hope to eventually get around to making something more generalized to integrate Nostr closer into our apps.

192 sats \ 0 replies \ @petertodd 22 May

Finally!

I hope the nostr team eventually makes me wrong. Of course then I'll just change my opinion and be right again. 😁

50 sats \ 0 replies \ @Car 22 May

worth reading @janetyellen post on it #131593

57 sats \ 0 replies \ @BlueSlime 23 May

Nostr is a naive protocol. The relays are meant to be dumb and agnostic.

Anyone can extend the protocol to build literally whatever they want. You can use other relays, or run your own.

The core protocol fits entirely inside a single proposal (NIP-1). If your custom protocol is NIP-1 compatible, then your protocol will work on any relay.

If users want decentralization, they will build and support clients that offer decentralization. Anyone can build a p2p protocol over dumb nostr relays.

Nostr shade is the new javascript shade. Haters are gonna hate, builders are gonna build.

11 sats \ 0 replies \ @nerd2ninja 22 May

TRUE! Its just a reimplementation of RSS basically XD, but it is useful because of how easy it is to switch websites (or add more websites), keep the same UX and continue posting

11 sats \ 0 replies \ @didiplaywell 22 May

That was the very first article I read on Nostr!

I think that the argument should be obvious. It's like blaming bitcoin for not being decentralized when the only one processing transactions was satoshi himself. It should be obvious that's physically impossible to start decentralized, and that what must be judged are the incentives for decentralization, despite being possible.

10 sats \ 0 replies \ @tolot 22 May

Indeed Nostr seems to create a tendency in clients to efficiently retrieve notes, which leads to inevitably connect to the most-connected relays. A feedback loop that cannot be altered in any significant way, I suppose. Nonetheless, if users where able to push other's notes to relays it would be great and possibly diminish this centralising tendency.

Could be that adding a new flag to the note standardised format will simply do the job...a flag like the RBF but in this case the flag signals the willingness of the creator to see his/her note pushed also to other relays.

Then adding a simple option like the "boost" button to let users "relay" a note to their relays. Since notes are uniquely identified I guess relays could just trash the copies of one note.

Or this may is already how the "boost" function works, dunno honestly. But adding the flag for the willingness of the user to see his/her note relayed could be nice.

End of the riffing

268 sats \ 1 reply \ @k00b 22 May

I agree with fiatjaf in the sense that what’s centralized today might not be tomorrow, but what do clients need to change to fix this? If it’s obvious what clients need to do to fix this, why will they do it tomorrow when they don’t today?

100 sats \ 0 replies \ @rheedi0 22 May

I think the fear that Nostr is too centralized right now is a bit overblown. With such a small group of users, all with similar ethos, there is no pressing need for decentralization right now because there are so few risks even if things are centralized. When the user base grows into something more substantial and starts fracturing into different ideologies and interests then decentralization becomes a lot more important. IMO it'd be a waste of time and resources to build out large swaths of infrastructure and services just for decentralization's sake when the demand for those resources just aren't there.

10 sats \ 1 reply \ @janetyellen 22 May

Nostr sucks

10 sats \ 0 replies \ @fiatbad 23 May

Perhaps.... but aren't all the alternatives even worse?

I'm a fan of the saying, "don't let perfect be the enemy of good".

I read through your post from last year about Nostr sucking. I agree with your points, but I can't shake these two thoughts:

What's the alternative? Nostr might suck, but it sucks less than everything else.
Many of your concerns might be addressed with further development. I understand some of your concerns are human-nature, and may never be solved by developers. But I still wouldn't write off the potential of further development.

I consider myself neutral and mostly ignorant in this debate... just a Nostr fanboy trying to learn as much as possible.

21 sats \ 0 replies \ @fiatbad 23 May

Bitcoin is going to be quite centralized in a world that is mostly at peace and trading with one another normally. There will be Federations and LN Hubs and Bitcoin Banks all over the place. And that's okay, as long as we retain the ability to run our own nodes, and exit the centralized system when shit hits the fan. Optionality is what Bitcoin offers that fiat never could.

The same goes for Nostr. It will centralize. BUT, we have the OPTION to decentralize when we need to. When the shit hits the fan.

A politician or media persona being censored on one relay has the option to run their own relay! The incentive is strong, because they have a public platform already and wish to retain control over it. Nostr gives these individuals the ability to decentralize when necessary.

Sure, the average person will use it in a centralized way 99% of the time, but the real power comes from OPTIONALITY.

Would love to hear other people's thoughts on this.

0 sats \ 0 replies \ @martinko21mb 23 May

I was hoping to get a little more about how the the problem may be tackled :)

0 sats \ 0 replies \ @jgbtc 23 May

It's as decentralized and censorship-resistant as it needs to be. If it needs to be more it can be more. It's pliable in that way.

0 sats \ 0 replies \ @Silent_Hodler 22 May

Nostr is as much about decentralization as it is about owning your own data. Decentralization is fine and will be achieved over time, as the protocol matures. Right now I’d lean more of being able to keep what’s yours easily, which is also pretty important imho.

0 sats \ 0 replies \ @BitcoinMaximan 22 May

It is, in fact, inherently centralized because there is no incentive to run a relay. This shouldn't even be a discussion.