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.
Discussion
So charge them and make money?
yes, you could do this, with auth
I'd prefer to include ecash in requests than to auth
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
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.
🤔
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.
