What's the case for putting your own *write* relay behind auth for all readers?
I see an increasing trend for this kind of config, and I cannot I understand the utility, aside from avoiding stressing the relay, and collecting data.
Login to reply
Replies (23)
Well, maybe to avoid going global.
How? Technically I can spin up a new keypair every time and use it.
P. S. @Vitor Pamplona idea for a privacy option.
Yes, but for some relays, you need to be inside the WOA (database).
Sure, but this is a totally different and specific use case. I'm talking about the standard outbox config that you use for social media / long form.
Many people don't like the idea of their posts being available for everyone and restrict who can see themselves by auth.
You don't just go around changing configurations, and what would you put in instead? You only make changes when something isn't working.
I don't understand this point.
I'm just saying that write relays should not have auth by default, since it is useless.
But if I can just create a fresh keypair and use it, the auth barrier makes little sense.
If they block by a white list, the new key won't work
Mostly it's abuse control, and it lands on the read side because the read and write paths share one WebSocket, so you can't gate only writes. Once every subscription is tied to a pubkey you can rate-limit or ban the heavy queryers, and a lot of the load on a public relay comes from those broad scans rather than people reading their own notes. The catch is that anything that can't sign a NIP-42 event is now locked out, so you trade a bit of openness for a relay that survives.
I suppose rank is a specific Gossip setting.
Btw, interesting discussion, it proves that the problem is real, and not recent.
If.
I doubt this is the setting of a standard relay for social interactions. Do you know a relay that have a similar settings, maybe controlled by a WoT?
yes it was one of the options
I tried to find it again, but this was common about 8 months ago or so. I remember seeing 3 or 4 users with issues because of those rules. I am not sure if they are still around. But I can see this growing, since each app now has its own Nostr sub-community. With 40,000 relays now, things are starting to diversify beyond the standard kind 1 use cases, finally.
There's only a single acceptable auth use-case:
I was referring to read activities, auth yourself for writing is fine, it has near zero overload.
Imo even for writing it isn't fine (except for what I mentioned) because the signature already proves who's the author of the event.
Requiring auth for reading would be similar to what X/Reddit do when asking for money to access their closed apis, which goes against Nostr selling point. It may also be interpreted as the relay inability to stop spam by other frictionless means.
You want some exclusive content to be seen only by people who pay you, or by your friends.
You thought about one very niche use case that I had never considered, then you proceed to proclaim that it is the only valid use case.
You could perhaps have some humility to imagine that other people might have other niche use cases too.
Nostr was never about being fully open for everybody, only that there is no single central authority deciding on behalf of users.
In a case like this, I would use a relay other than the default one, which should be an open relay.
And maybe NIP-65 should permit to flag a relay as restricted with a reason, to facilitare clients in the job of showing an intuitive interface.
What about all the interop effort on the NIPs repo? It is impossible to interoperate with closed apis.