nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku nostr:npub1gnwpctdec0aa00hfy4lvadftu08ccs9677mr73h9ddv2zvw8fu9smmerrq nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 maybe we really should think up a less-invasive form of AUTH. 🤔

That might help some npubs feel less like they have to be strip-searched to read replies and shitposts.

Reply to this note

Please Login to reply.

Discussion

I need to read up on how how auth currently works.

it's the same as all auth systems... you have a secret that the protocol allows you to prove you have without giving it to the other side (for nostr that is signing an event, the signature validates on the public key, on normal login systems you send the password but they immediately hash it and compare to the hashed password of your account)

the nostr auth protocol is stronger than standard logins, a LOT stronger

Would it be possible to perform some task, rather than signing? Or somehow proving that you are a whitelisted on the relay list, without revealing your specific npub? That would at least allow for some obfuscation.

Or, wait a minute, could you use some other key, that is once removed?

Or submit some hash that only makes sense, if an npub on the whitelist created it?

I don't know. Something slightly indirect.

i've already said this, the clients should be able to make up a new npub for each websocket, you want to identify yourself to paid relays but everyone else should get whatever

you can mix it up also with different policies - different every time, change every x minutes or x times on each relay, etc etc

the problem is not asking for auth it's the dumb clients not thinking about what it means (and that's a problem because most of the NIP guardians are client, not relay devs, and cryptography and game theory are not their strong points)

Yeah, we've noticed.

Get me a new NIP or a NIP PR and I'll push it with you.

I'm gonna need to understand how current AUTH works, first.

What is the problem you've seen with it?

Well, isn't the point of auth to prove who you are to the server. Otherwise why would the server trust you? I think the concern that others have raised is associating an npub to an IP address? Isn't that already happening when requesting things like lists anyway? I guess it doesn't PROVE who you are, but it's pretty obvious when ip 56.28.99.36 continuously requests kind0 events for npubxxxxxx? It's kind of the point of identifiers.

Just to confirm I'm not an idiot, refreshing the page it's pretty obvious to a relay who I am when loading metadata

["REQ","zqdyobdM",{"kinds":[0],"authors":["036533caa872376946d4e4fdea4c1a0441eda38ca2d9d9417bb36006cbaabf58"]},...(other kind stuff also revealing only my public key)]

It's not to prove who you are, it's to prove that you are in the "trusted" group. I'm asking if you can prove you're in the trusted group some other way, like decrypting some message that only someone with a trusted npub could, and sending them the content of the message back.

Decryption is the inversion of signatures. In that case because it has to be encrypted using your npub that would still leak your identity. I guess my consideration is, is AUTH any worse than requesting my kind0 data from the server? Thats what I'm trying to understand

It wouldn't accomplish any obfuscation, unless you were one of many, like 20+.

So basically issuing a noise protocol for message data. I suppose that could be done with proxies as some sort of aggregation. I think we're still fighting the war of my IP may be linked to my npub and were fighting networking protocols here.

I was just wondering if there was some One Neat Trick that would assuage the worries of people like nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr , while still allowing us to control access.

Cuz I think the future might be all relays using AUTH.

Well It's probably worth understanding his more specific concern then. Lemme take a look

🫂 thank you!

I'm starting to think AUTH is utterly necessary for writing. I think Digler is correct in letting users read without proof, it doesn't risk any harm to the network to read. It's just going to be a relay architecture change. That and clients will just need to accept the reality and handle auth better.

At first I was sort of against auth, like who tf are you to tell me "papers please", just be a dumb relay and handle it for me wouldya chap.

Everything will eventually be AUTH to write, but some will be AUTH to read and we might end up with outboxes full of AUTH-to-read relays, which means you'll be constantly AUTHing all over the place, without noticing.

What is the cost for relays operators to let people read stuff? #noobquestion

Is there any and how does it scale?

You read by requesting the relay find information and send it to you, according to some filter. (Filters are boolean, unlike queries, so they tend to be cached after use for better performance when re-requested, but I digress.)

So, the cost is in filtering and returning the result, and possibly in caching the filter.

You can overwhelm a relay by requesting lots and lots of filters or lots of npubs requesting something be filtered.

AUTHing to read means that you have to identify yourself to the relay, and be approved, before it runs a filter.

I think. Maybe. Just guessing. Don't really know. Ask someone with more clue. HTH.

TheForest just uses AUTH-to-read because I have stuff on there, that I don't want on a public relay.

I'm sorry. I literally just pulled that explanation out of my arse. I've never actually checked how it works.

Mfw trying to sound like I have some sort of clue.

Resource exhaustion, so were just asking for a whitelist for sessions I suppose. It's still possible to overwhelm a server by repeatedly requesting auth upgrades too, deplete the RNG pool requesting challenges. So rate limiting still applies, and can mostly solve the exhaustion problem.

I think it's fair to just say whitelist may be useful for reading. I don't think it helps any more than rate limiting for resource exhaustion.

Hey, could we do simple whitelisting for reading and AUTH for writing?

Theforest was just whitelisting for writes, before, but could it whitelist for reads, or do we need AUTH for that?

Or is that a retarded question?

Guess that doesn't work, since you don't have to identify yourself to read, so there's nothing to check against. Nevermind. Retarded.

I guess that's the point of AUTH: it creates a signed event to check. Duh. Sorry.

It's a forward check.

But it's per-session, so you could theoretically AUTH once and then make multiple REQs, right, nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 ?

Rate-limiting would be per-REQ or per-SESSION?

Or is this again a retarded question?

I'm not well versed on relay coms, but I believe it's per session when the socket is opened. It would get expensive otherwise. However I think a relay can send an auth message whenever it feels like, but it's attached to a session id.

The only code I'm most familiar with is Grain, and he uses per kind limiting iirc. Strfy defers it to the handlers I believe, so it depends on the message kind. I would assume strfy also has per-req limiting as well.

there is usually two triggers for sending auth, one is immediately upon connection, the other is in response to an auth-required request or event envelope

strfry is quite unopinionated, it has a "sprocket" thing that it feeds incoming events to and if you have code attached to that it can filter it and send back replies and/or interact with the relay event store... relay.tools guy nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h got me to start doing some stuff writing scripts and tools for this and he's made it pretty fancy these days since back then (was december last year i did a little work on it)

the fiatjaf/mattn relayer nostr relay framework also has by default an option to enable a ratelimiter per-IP address also, and an easy thing to plug in your own filters and it is easy to enable auth with it as well (i'm in the last stages of completing a port of it to my fast, allocation avoiding, binary-focused nostr message codec right now)

I wish we could let people AUTH to read and just ignore the IP address and send the results to their npub.

well, thats what its doing.. i am still wondering what the concern is because i like the idea. its neat right? no dumb IPs, just pubkeys. i will not 'steel man' anti-auth for them because I'm still waiting to hear more reasons why. (hint: replyguy doesnt like auth either).

replyguy could auth just that usually relays that require it do so because only a whitelist of npubs are allowed to publish events

as it is, he is already making hundreds of new keys and publishing profile metadata to go with it, on top of it all

it's quite funny though, only spams replies and profile events, that is all

i'm sure whoever is doing it has an axe to grind with the relays its selecting to spam at also

yep

i am encountering it in my work too, i see it on a firehose feeder i made that pulls events from multiple relays concurrently and processes the unique ones it sees in a window of 2048 events (uses a map to implement a uniqueness invariant)

it's very easy to detect them, you literally would just look for the e, , reply tag in it, and go to the event named in the event id, and check that the content field has the same prefix data and ignore it after that

but it's quite funny, very often the reply events are showing up ahead of the replied to events in the feed

i'm sure that replyguy is just the tip of the iceberg of problems these free relays are having

i may have to write a filter like this at some point in the future, it won't be hard to do... hell, even just looking for the relay's own address at the end of the reply content field would flag them all

"but it's quite funny, very often the reply events are showing up ahead of the replied to events in the feed"

LOL how the heck?

subscriptions often come ahead of req results... usually a req starts a subscription first, and then does the search and then sends the results

in the meantime, the subscription is there and if someone publishes a matching event it sends that out, and the database could still be working at that point

makes sense, when you think about it... subscription results can come in without a search, but reqs always need a search

basically subscriptions match on newly submitted events before they go to the database, so if the req is busy but the sub is open already a reply can come first because the req thread is busy saving it first

er, searching it lol

Okay, that makes sense. Unexpected.

I like AUTH. It's here to stay. I've decided and I'm the princess of Nostrworld, so that's an official ruling.

I just want to air out the alternatives to AUTH-to-read and watch them get slapped own in public. Or not.

ratelimiting... already being done by many relays

yes, auth is once per websocket connection (in my implementation). strfry does not have any way beyond setting size of tags, or size of an individual req for doing read rate limits. so for example, there are ways to overload a meduim sized relay by forcing it to keep its cache hot, beyond its memory size by requesting many reqs over the single socket.

since i needed an auth proxy for DM protections anyway, i built one .. it could also be used with non auth, but, then you are still going to hit the problem where they will change to open more connections, and then you can throttle naively by IP address, which will cripple all users experience. the bots will always win a war using IPs. they will not however, win a war against sats. (because if they did, well, the value was never there to begin with) ⚡

Yeah. Makes sense. Is anyone working on that in strfry? I've never taken a liking on application proxies. The base software should be the one doing do the work, if not we need to fork it or replace it. Especially in the form of websocket traffic. A proxy should see nothing more than stream traffic of an upgraded connection. That's just imo.

Yeah not tmk. Auth tells the server I hold this private key, please check your whitelist sir. Otherwise I could just say I'm whatever npub I want, there is no way to prove I am who I am. IP whitelists only work because I can't lie about my IP if I want you to send data back to me. :|

Right.

And all that filtering and sending stuff back has an energy cist? That is significant?

I'd to know what the difference is for nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h in his running costs between:

A. Relaying 1GB of events for me

B. Relaying 1GB of events for Bruno Mars

(I have the same question for media servers too btw)

it depends on the level of service. and the underlying server architecture. the operator of a hub will be running these calculations and charging accordingly..

yes it does cost more to have a more popular relay, or a relay with lots of data that is wide open to reading.

Do you save money, then, now that I have AUTH-to-read setup? Or is my traffic too low, to make a difference?

I don't actually know, if anyone else uses my relay. 🤷🏻‍♀️ They could all be reading and responding from someplace else.

your relay's database size is not big enough yet to have performance implications from auth/non-auth.. because you didnt let it fill up w buncha junk 🙏

I just haven't seen the point in storing things I'd never look at. I'm stingy about bandwidth and storage.

Probably being old-fashioned. Resource-management doesn't seem to be a topic, anymore.

it will be again..

your relay has on avg 50 simultaneous connections

...and 35 are from me. 😅

But, that's interesting. I thought maybe 5 or so.

#soon there will be chartjs showing of the influxdb data 🐳🐡🐝🐛

🙏

That's where NVault comes in :) Know during (prompt) or anytime after if you auto allow things. Eventually I want it to be very granular.