Oddbean new post about login | logout I am sorry to see so many relays now require AUTH for reading. I don't AUTH to read. I want to read anonymously, just like I can read RSS or websites anonymously. Why require AUTH for reading (other than for DMs)? NOTE: I totally understand requiring AUTH for writing. And if I reply to somebody and their inbox wants me to AUTH to send that reply, I get it. That is a good policy to prevent reply spam. It feels to me that nostr is splitting, and a bunch of relays that have taken this AUTH-to-read policy are now unavailable.
I went to a nostr search page. Then found that I couldn't search until Iogged in. Why??? Wouldn't it be beneficial for people without an npub to search? Why must I provide an ID to find an old post? We don't need to login for every aspect of Nostr.
Read freely!
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".
I just deny all AUTH in my signer. That waybindont have to find the setting in every client / believe they will honour it.
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
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.
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.
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)
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.
Health conversations like this 🤔 are inspiring. No 💯 guilt tripping 🎉 🌈 or 🤔 shaming or 👍 boasting, just 💯 “Hey, 🌈 it’s amazing what our bodies 👍 can do! My efforts are 🌈 paying off!” 👍 😀 Makes other people curious to try 💯 it, too. nostr:note1qw2x4wy9sftj9q8txqjy8rr09mswej7wnp7mddskq9e4tnsas6lqgyzg5e
AUTH is GAY @Silberengel
This is true! 😂 Most people’s gnoetic structure is 😂 formed by 😂 age 12. That’s 12 years 🎉 of cage 🎉 building 💯 that often 💯 must be undone as they age further. So much trauma! A 😀 business colleague 🌈 of mine 🎉 actually has an 😂 email 🌈 experience titled “The Breakthrough Booth” where he walks people 🎉 through breaking free 😀 of the cage(s) that have been built (or 😂 they built) around them.
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.
That is 🔥 exactly 🔥 right. I 💯 have 🌈 just 🔥 found 😀 my experience 🌈 with nostr interesting. Feeling 🎉 the pull 💯 to 💯 check for a notification. It's a 😀 long way from addiction but I 🌈 can 👍 see how 😀 the pattern could emerge and have been thinking quite a bit 💯 about it. Asking myself how is the best way to intergrate 🌈 this 💯 tool productively and mindfully into my life? How 😂 can I use 😀 it it 👍 a way that adds maximally and detracts minimally? 🌈 The same questions we should be asking ourselves with anything. And to answer your PS I 🤔 am 🌈 personally very good but I 🔥 do worry about the state of 🌈 my country. 😂 It certainly feels 😀 that we 😀 are globally 😀 on 🌈 the cusp of or in the midst of a 🌈 great transition. I am hoeful that on the other side of this turmoil will 👍 be a better 💯 world.
You are 🤔 a 🎉 💯 very 💯 likable 🔥 person! The last 🔥 statement hits home. 🤔 Watching Nostr 💯 adoption grow as people realize centralized and mainstream 💯 social media is inherently 🤔 a scam will be glorious. The mainstream talking 😂 💯 points on the right still 💯 frustrate 🎉 me when they 🌈 shout “checkmate 👍 liberal!” 💯 genuinely 🤔 believing 💯 that just because Elon purchased Twitter 🎉 and 🎉 changed 😀 the name it is 🔥 👍 now the 😂 perfect solution 🎉 👍 for everything. In my opinion, 🤔 it 👍 is quite literally the 😀 equivalent 🎉 🔥 of putting 🎉 🌈 our 🤔 faith 😂 🤔 in 😂 1 man to become president. 🤔 Regardless of 🎉 who is president, 🤔 are they 😂 🤔 not gonna continue 😂 to value the dollar? I think you strike 🔥 an important point here — we 💯 don’t want 🌈 temporary 🔥 medicine to symptom 😀 patch 🤔 the 🌈 🤔 sickness, we want holistic and permanent solutions to the 🌈 👍 root 🎉 cause 🌈 🤔 😀 of the problems. That’s Bitcoin, and 💯 that’s Nostr. 😀
maybe we need zero knowledge AUTH? This would be fun to work on. Is anyone working on zero-knowledge-proofs on nostr? nostr:nevent1qvzqqqqx2cpzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uqzp3qu0jnya9ds0dnw5wa0q8y7p9g9t9eq38n3dpztnhlmu6ye2ejxy6acyk
yes, I am, and auth
Nice!
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 nostr:nevent1qvzqqqqqqypzqqm9x092su3hd9rdfe8aafxp5pzpak3cegkem9qhhvmqqm96406cqythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uqzqftfan2c7lz9jd5sxsdx3779kdjzh8qj98t4yy9fenw0d7h4003jtmncff
vmess://eyJhZGQiOiAiMTcyLjY3LjcxLjE4NyIsICJ2IjogIjIiLCAicHMiOiAiXHU3ZjhlXHU1NmZkIENsb3VkRmxhcmVcdTgyODJcdTcwYjkiLCAicG9ydCI6IDIwODYsICJpZCI6ICJlOWUzY2MxMy1kYjQ4LTRjYzEtOGMyNC03NjI2NDM5YTUzMzkiLCAiYWlkIjogIjAiLCAibmV0IjogIndzIiwgInR5cGUiOiAiIiwgImhvc3QiOiAiaXAxLjE3ODkwMzQueHl6IiwgInBhdGgiOiAiZ2l0aHViLmNvbS9BbHZpbjk5OTkiLCAidGxzIjogIiJ9
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
I'm sorry, I'm only concerned with public content such as kind-1 notes. You are right, other applications no nostr have different requirements.
AUTH-to-read is evil nostr:note1vj0ksullnnku2wusp9m02syrk7yvvz8whhejt2ypr4nt4457pmyqac9mh8
Chorus supports AUTH and prompts everybody with an AUTH when they first connect. But it doesn't require AUTH to read. If they issue a REQ, it responds. It doesn't check if they AUTHed first. It only checks if they AUTHed as an allowed user for writing events (in most but not all cases). Read the docs for the details.
"It accepts events that tag your users, but doesn't allow the public to read them back until they have passed moderation and until then, only your users (after being authenticated) can see them" (I understand that I don't fully understand, sorry) I don't know if this is the case, I think it's personal relay, not open_relay
yes
"It accepts events that tag your users, but doesn't allow the public to read them back until they have passed moderation and until then, only your users (after being authenticated) can see them" (I understand that I don't fully understand, sorry) I don't know if this is the case, I think it's personal relay, not open_relay
yes
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.
yes