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


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


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


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


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


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


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


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


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 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


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


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


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, 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


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


you have it on your nip-65 right?


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.


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?


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


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


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


ah awesome!


Wait until we get relay apps running on phones :)


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


but how does a relay deal with this? you didn't even think about that!

no, the relay just holds the connection open, pings and pongs, and ignores all inbound messages

that's the way that minimises traffic and computation


i'd say it doesn't disconnect, because i have not seen that, but it definitely is silent

that's the right way

i'm quite sad that you have such poor understanding of spam management and bad protocol implementations handling


where is reject bro

WAT REJECT?


reject is drop the message, ping pong and gfy


and then what do you think dumb clients are going to do after that?

reconnect, and try again

and you just not only sent your fancy protocol message, and closed your socket, you were forced to reopen it, and answer the same shit again

you don't get it


you are closing the gate after the goats have escaped

the clients are gonna do dumb shit

don't expect goats to not be dumb

do what is required to minimise their damage

i can't believe what nonsense i'm reading

have you actually studied the bitcoin protocol?

you know, this stuff is well and truly done and dusted, you aren't going to innovate

just like no shitcoin is gonna improve over bitcoin


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.


Client: "Did you hear anything from bob?"
Relay: "Bob doesn't live here."
Client: "Did you hear any thing from bob?"
Relay: *oh brother*


this is a great approach


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?


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?