Nostr Web Client

Let me clarify that a little bit. Relays can be used for all kinds of things. AUTH-to-read is perfectly fine in many contexts.

It is only the OUTBOX context that I'm talking about.

IMHO nobody should have an OUTBOX relay that is AUTH-to-read.

I completely agree. Normalising AUTH-to-read for outbox relays creates incentives for relays operators to track each user's reading habits and and sell the data to advertisers.

The clients can already do that.

I can choose my clients but I can't choose other people's outbox relays.

That's true, but some clients ask you to approve AUTH to a new relay. If that's important to you, use those clients or ask your client dev for that feature. It could just be a toggle, or something "ask before AUTHing".

Or even, "deny all AUTH".

Like in Nostrudel:

I just deny all AUTH in my signer. That waybindont have to find the setting in every client / believe they will honour it.

Well, then I'm not sure what the problem is.

If relays deny requests for public events unless they have received an AUTH response, then it becomes a big problem. I won't be able to read a users public events from their outbox relays.

Oh, you mean, if all of their relays are AUTH relays, but not read-limited? Yes, that could be a problem.

What do you mean by read-limited?

When they use auth, but anyone can read the notes, who isn't blacklisted.

What about zap-to-read?

There's no relay that offers that, so far.

if you dont run auth on your relay you get overwhelmed by 5 million cloudflare scrapers each with different IP, with auth, you have more control over the req rates on the websocket.

So charge them and make money?

yes, you could do this, with auth

Zaps don't need AUTH

Well, lightning payments don't need AUTH. Not sure about nostr zaps

All events need AUTH, including zaps, but the payment can still work.

I'd prefer to include ecash in requests than to auth

I wouldn't mind that, as an alternative "entrance fee", but I don't think my relay allows for both.

It would be a high fee, though.

Is the goal to cover costs, or to deter reading?

im open to ideas..

many times i am developing solutions for these relays while balancing keeping them online and responsive. there are so many ways you could use this auth scheme.. partial/hybrid/auth/ecash auth.

i appreciate everyones feedback, and nostr:nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgpypmhxue69uhkx6r0wf6hxtndd94k2erfd3nk2u3wvdhk6w35xs6z7qgwwaehxw309ahx7uewd3hkctcpypmhxue69uhkummnw3ezuetfde6kuer6wasku7nfvuh8xurpvdjj7a0nq40, i will keep in mind what youre saying about public un-auth reads.. i just am unsure the best ways to throttle in that mode. websockets put the burden on the relay software itself as all traditional http throttling simply does not work.

I think using a zero knowledge proof that I am one of a number of npubs is more practical as it doesn't require users to have, and want to spend ecash on privacy.

so like, you know a relay can profile you super easily just with client fingerprinting right? being annoyed with auth, i hope its for good reason and that youre aware that clients already send telltail signs of what pubkey you are just from making reqs every time they open.

if you already know this and have your own client or etc, or do not feel this fingerprinting is as annoying as auth .. you can use a shared auth key with multiple people, and have the same level of obfuscation for your reqs that you would without auth.

the benefits of auth are many on the operation side (dynamic req limiting) and client side (DMs etc). so i think its very important to head this direction.. whether its pubkeys, zaps, ecash, or zkps i dont know? nostr does not have the equivalent of a robots.txt

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

there is also the possibility of requiring auth but being a free relay, but having a scaling rate limit that allows more traffic the longer you use the same one, this permits rate limiting and the client can make up a session key for this and not persist it

you can only impute this via request fingerprinting and IP addresses otherwise, so it would allow free tier service to be more generous without being an open back door for spam

I'm aware that right now most clients make finger printing pretty easy right now (see nostr:nevent1qvzqqqqx2cpzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uqzp3qu0jnya9ds0dnw5wa0q8y7p9g9t9eq38n3dpztnhlmu6ye2ejxy6acyk), but normalising auth-to-read removes all doubt and possibility for clients to resist this later.

I've thought more about zkps and either the relay must reveal their whitelist or the user sends a list that could easily fingerprint them.

I don't have any easy answers for an alternative. attaching ecash to request messages could be interesting.

Are you seeing clients that get disconnected immediately reconnect from a different IP to make the same request, or are you just assuming such?

Chorus blocks reconnections by IP address for 1 second to stop any kind of overwhelming. I don't know how well it works because of course my relays isn't heavily used:

* it has 107 open clients at the moment, which is the highest I've seen... it times them out too so they aren't just hangers-on

* Since it started, Inbound: 595880001 bytes (803.1994 B/s) Outbound: 1588855136 bytes (2141.6519 B/s)

I'm not looking at the IPs no, scrapers and such will not usually disco. if they want to re-scrape data from months ago over and over uselessly, or an app has just gone wild after being put out to pasture and it's causing a REQ loop, they can make their pubkey known to the relay and use their allotment of REQs. Workers such as blastr, is why I refer to assuming there are many IPs and it being somewhat useless to base your filtering on.

also just to mention, some of the relays that need auth, are just asking for a key. ANY key.. so you could auth with a different key, and then if the relay is open like this, send and req any valid events on that connection, except DMs as those require auth by your main key.

balas 1y ago

🤔

It is not a bad workaround. But given the workaround exists, AUTH isn't achieving anything.

Nonetheless I'll implement it simply because it is easier to change my code than to change other people's thinking.

freedom isnt free 😅 or ur the product etc. reading a relay, i dont see a point in someone writing to a relay only to have everyone centralize to the biggest aggregators. those aggregators wouldnt exist, without homegrown relays, so they will need to pay for this, or relays ded.

Иван 1y ago

With all this authorization crap, we're going back to the era of the WWW, and even worse.

Once nostr embraces CORS, I'm out.

blame websockets. traditional methods of rate limiting will not work here (im talking http)

furio 1y ago

If the protocol allows it, use another relay.

This seems like a feature to a FOSS platform and a “write your congressman“ type of situation.

Leo Wandersleb 1y ago

Reading also incurs a cost on the relay.

I would run a public relay if I could meter access.

Paying customers get X GB per month. Their follows get Y GB per month etc.

If you want to be completely anonymous, add Chaumian Cash to your request.

I think it's fine, to have relays with different levels of access.

Maybe we are writing things that we don't want everyone to read, or storing things like drafts or events addressed to a particular community. Or maybe we don't want to open ourselves up to constant ridicule and threats, or just want to talk amongst ourselves. Or we want to have more control over the ability to edit or replace events.

AUTH on reading doesn't stop information from spreading (there is no technology that does this), but it slows it down, considerably. Feels more like writing on Telegram.

73eaa004... 1y ago

AUTH is GAY nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z

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

you know the client can make up a one time key for eath auth that isn't tied to a subscription right?

that's one extra boolean flag in your relay data structure and an extra field to set one of the stored user keys for these

users leak their npub constantly with their queries because almost every single one includes the same npub, it makes zero difference if you don't use an anonymising proxy either way

put the security features in the right box, if you muddle the layers up they will become brittle and eventually this will prove to be insecure

anonymisation is a network layer, not application layer issue

I have implemented this work around.

nostr:nevent1qvzqqqqx2cpzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uqzp3qu0jnya9ds0dnw5wa0q8y7p9g9t9eq38n3dpztnhlmu6ye2ejxy6acyk

maybe we need zero knowledge AUTH? This would be fun to work on. Is anyone working on zero-knowledge-proofs on nostr?

Melvin Carvalho 1y ago

yes, I am, and auth

nostr:nevent1qvzqqqqqqypzqqm9x092su3hd9rdfe8aafxp5pzpak3cegkem9qhhvmqqm96406cqythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uqzqftfan2c7lz9jd5sxsdx3779kdjzh8qj98t4yy9fenw0d7h4003jtmncff

Nice!

ChipTuner 1y ago

What exactly are we worried about? My concern is that AUTH isn't any worse than me asking for kind0. I see dozens of REQ that can be associated to my npub

namosca 1y ago

In a community server, where you expect to talk and be heard only by people inside the community, I'd say that's a very important requirement.

nostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhgprdmhxue69uhkwmr9v9ek7mnpw3hhytnyv4mz7un9d3shjqgcwaehxw309ahx7umywf5hvefwv9c8qtmjv4kxz7gpzemhxue69uhhyetvv9ujumt0wd68ytnsw43z7s3al0v is making ditto as a community server and I think it would be a good default option that no conversation is "overheard" there