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 

 https://github.com/nostr-protocol/nips/issues/1050 

 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 

 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. 

 I'm usually ignore it, not all req require auth so I still use it as normal 

 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