client developers:

if you see an `AUTH` from a relay and you don't want to `AUTH` do you:

* disconnect?

* don't send REQ/EVENT's to it?

* try to REQ/EVENT and see if you get an `auth-required`?

cc nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku nostr:npub1zfss807aer0j26mwp2la0ume0jqde3823rmu97ra6sgyyg956e0s6xw445 nostr:npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg nostr:npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s

Reply to this note

Please Login to reply.

Discussion

Coracle stops sending stuff to it. I can't remember if it actually disconnects.

it should disconnect and not try it again

i watch my relay constantly being connected to and if i make my relay disconnect when auth is required they just keep trying and keep being disconnected and it's bullshit, so i just let the connections stay up, ping them, and drop all their messages

no, if you want to require auth you should close the connection and respond with `auth-required` to make it explicit that you won't let them pass until they AUTH

there's an in-between state (in which I am and why I ask) in which I want to allow people to AUTH but not require it.

We already have these as separate verbs so the protocol allows for this expressivity, but I doubt clients will not interpret AUTH as an possibility to auth rather than a requirement

there is a fairly high cost in handshaking that's the reason why i stand by what i say - just accept the connect, drop the messages, think like a firewall, what do you do to defeat a spammer? first port of call is ignoring them

no, I understand that if your relay keeps getting bombarded with clients that are not getting the hint that they won't pass without AUTHing ignoring them makes a lot of sense

it's what the relay should do if the clients don't respond with auth, to conserve resources

yeah, or you can just rate limit at the http level or firewall level which might serve more resources

btw, i see your client is sending your events to my relay... haha

you have it on your nip-65 right?

lol these stupid codes

i suppose if #coracle sends them out then it sends them out

ffs how exactly did this improve over relay lists?

also, when can we migrate from the retardation of bureaucratic number lists to human readable codes? you know, bureaucracks are fucknig inhuman right?

also, what makes you think that a client sending an auth envelope with a challenge is not a requirement????

you mean a relay right?

in my relay it's not a requirement, but because there's no way for the client to initiate the AUTH my relay needs to send an AUTH out of the gate but if the client doesn't want to AUTH it's fine, they can keep using the relay, just with a "limited" view

whereas if a relay tells you "auth-required" that's a more explicit signal that you need to AUTH to talk to it (or at least to execute that filter)

yeah that is retarded

nip-11 already says auth-required

i send auth

i want auth

no auth

silence

ping pong ping pong ping pong

and no REQ

that's what works in the real world, i've kept my client open most of the time in order to gather intelligence about how retarded the clients are and that's my conclusion

unless you can forward a GTFO request upstream to your reverse proxy then just entertain them with silence

many libs didnt recognize AUTH so for those the client wont know and that message gets ignored and client retries?

i added auth to a fork of calle's fork of python-nostr awhile back. i now have to look for auth, and if encountered, handle it and resend original message

yep that's the correct way to handle it

but for relays, just gonna say it, it's less work to just keep the connection open and drop the messages because otherwise the dumbass clients keep reconnecting, and that's more noisy and higher bandwidth than just holding a ping pong

of course drop the connections if your websockets count is getting out of control but i think that's a pretty high bar to reach

Client: "Did you hear anything from bob?"

Relay: "Bob doesn't live here."

Client: "Did you hear any thing from bob?"

Relay: *oh brother*

i posted an issue about client's preempting auth in the NIP repository btw, maybe you saw that?

clients don't have any capabilities signalling and as it stands, relays hardly have it either, and neither side are really dealing with this problem, it's very elementary, bitcoin has had this since very early on with version bits

I don't think I saw the issue you're referring to

This has been discussed infinite times. If the relay wants clients to authenticate the relays can send an AUTH message immediately upon connection.

infinite times

where does it say this in the spec fffs

for fucks fucking sake

no, it does not say that in the spec

it does not say the client can initiate it

mister fiatjaf

please

stop being a twat

no wait

you didn't get it all

if the CLIENT wants to auth

there is no spec in the fucking protocol you moron

no spec in the protocol

no spec in the protocol

it does not say anything in the protocol about clients initiating auth

shut the fuck up, it needs to be in the protocol

put it in the protocol

or prepare for continuing harassment about your shitty go code

no i lied, i'm gonna rag you about your broken concurrency until kingdom come

you can't call yourself a go programmer if you fling around channels and goroutines like they are nothing

you are a noob, get over it, learn, become better

OK, I accept it, I am a noob. Can you tell me what is wrong with my concurrency code so I can get better? Give me an example.

what is that? Having many parallel threads running concurrently?

Why would the client want to authenticate to a relay that is not expecting that or prepared to handle that AUTH message? Or are you saying that the relay is prepared for it?

I just ignore it if we/the user doesn't want to auth in that relay.

ignore it as you stop sending REQ/EVENTs to it but don't disconnect?

or ignore the AUTH and continue talking to it?

no, I keep sending filters because some (many?) relays return the public, non-authed part of the relay just fine.

Thank you. This is how it should be I think. At least since (I think) we fixed NIP-42.

Wait until we get relay apps running on phones :)

ah awesome!

many clients continue to send requests. closing the connection usually results in immediate reconnections. I have an ip block list with over 100 ips of clients like this within 48hrs of having my private relay on the public internet. would be nice to get broader nip42 client adoption.

try to REQ/EVENT and see if you get an `auth-required`. Some relays still allows you to get stuff despite asking for AUTH.

I don't AUTH to it. But I just keep rolling with subscriptions.

But if I get an 'auth-required' for a subscription and I don't want to auth, I save that subscription in a list of "failed subscriptions" which I do not retry (for the duration of the session).

If I *do* want to auth, then I put the subscription aside, do the auth, and once that is completed I retry the subscription.

If I get an auth-required after I think auth was completed, I just drop the subscription but I don't ban it into the "failed subscriptions" list.

this is a great approach