Oddbean new post about login | logout Nostr's censorship resistance doesn't come from asking relays nicely not to censor It comes from the ability for anyone to run a relay as they see fit There is a relay that only accepts notes that say "gm" - does that mean we have a censorship problem because everything else is blocked on this relay? This argument that relays should be completely open because we hate censorship is SO STUPID
Distributed redundancy
Clearly, we need MANY relays that ONLY accept notes that say "gm". Just in case few of them block you.
Relays are important man. Running your own smart relay is the ultimate in owning your own feed. You don't need anyone's permission.
this comment is unrelated to the point above
Amen! I particularly like that you didn't demonize the word 'censorship'. It is simply a reality that some content will get censored by some relays; and, frankly, this is a good thing. There seems to be a lot of energy wasted trying to claim that this isn't 'censorship'. I think this is a mistake. It provides a false point of contention. I believe it would be more productive to simply embrace the fact that individual relays will conduct 'censorship' within their own individual jurisdictions as it were - but as you correctly point out, this does not present a censorship problem for the network as a whole.
I censor the shit out of replyguy proudly
It's all about choice. Don't like the way a relay works, change relay. Don't like a certain client, change client. Don't like the algorithm you're using, change it. This is the beauty of nostr, where we always have a choice. In contrast to current centralized platforms, where we don't.
The problem is if for some reason you don't want to trust your signatures trail (events) to any relay, and your nsec to any client or bunker - you have to run your own relay and make your own client))
The second problem is - why you need Nostr if you don't trust it's infrastructure? Why will you run your own relay, who will read it and for what?
I find that dumb too. Relays are likely to have a ton of different policies when it comes to content, which I think is a good thing. It would be nice if this info was easy to find though so that people can choose relays to suit their needs.
Apparently many people aren't mentally equipped to have free speech. They confuse it with having the right to be a total dick online or to spread content the average normal person wouldn't look at twice. Anyone who has a problem with relay moderation should run their own relay. In particular fucking pedos.
Nostr has censorship resistence in theory, but in practice there is very little transparency when it comes to the rules and policies of individual relays. Just the other day I saw someone replying to a post I wanted to see but couldn't. How am I supposed to diagnose that? Just keep on adding relay after relay until 100 relays deep I find the magic one? Maybe Amythist is just a shitty app, but it would be great if the user could be more directly in control of their own experience and in a more transparent way. Heck, theoretically the regular internet is censorship resistent too, because you can always just republish your blog from a different web host, but as the consumer I'd prefer not to have to write my own fucking web-spider just to be able to know what content I'm filtering out. I may be a scoundrel, but when every new user is complaining that they can't tell what the difference is between any of the 70 relays they have to choose from you know you have a problem. Mastadon may block at the instance level rather than each individual post, but at least Mastadon instances make their blocklists public!
Clients need to do a better job of finding the outbox relay of the people you follow, instead of you having to pick read relays We'll get there
What if I don't follow the person? The only evidence I had that the post existed was that someone replied to it. Do clients have a way to find out what relays are hosting a comment? Is that even included in the Nostr protocol? And what about if I don't even have that much? Is that still just a client problem? And you didn't address my complaints about relay transparency. Is there anything that could substitute for this lack of transparency in relays and a protocol that doesn't facilitate such relay transparency?
