I'm not sure exactly, but I think it has to do with how the AUTH message is understood in different clients and relays.
It looks like mleku.realy.lol responds with an AUTH message when the socket opens and then doesn't send anything until the client responds with an AUTH
This probably doesn't work well with clients or libraries that are built expecting a NOTICE "auth-required: " message as a signal to authenticate
This seems to be an issue on both sides though, because I've started using rx-nostr and its implemented the same way. it considers AUTH messages to be a signal that the relay is asking for auth without waiting for a NOTICE "auth-required: "
It looks like mleku.realy.lol responds with an AUTH message when the socket opens and then doesn't send anything until the client responds with an AUTH
This probably doesn't work well with clients or libraries that are built expecting a NOTICE "auth-required: " message as a signal to authenticate
This seems to be an issue on both sides though, because I've started using rx-nostr and its implemented the same way. it considers AUTH messages to be a signal that the relay is asking for auth without waiting for a NOTICE "auth-required: "
wtf? if this is expected behavior can we get it documented as such? devs are out here trying to reverse engineer the protocol becauase of incessent cowboy coding practices and shoddy nip docs. thanks for your insight on possible solutions
nowhere in nip42 does it mention responding with a NOTICE.. i dont do this but i was thinking about it in addition to normal auth. is that what y'all expect now?
Hide replies
I think there's room for both, clients can respond or not depending on how aggressively they wan to auth. If there are implicit access controls going on, the relay may choose to respond with some subset of data without notifying the user. Or it may notify so the user knows to authenticate because they're missing out.
if i understand mleku's he sends the auth in addition to a notice. cause he says clients are more likely to stop spamming that way.
Makes sense now why @npub1fjq…mleku has been saying all this time that clients do not implement AUTH properly. I think it's a big misunderstanding. His issues would all be solved if only he answered to all queries with the "auth-required" thing.
Hide replies
Perhaps this all needs to be clarified in the NIP. I also have had trouble implementing AUTH. It still doesn't work consistently, with some relays or clients I use, even though @npub1qe3…ezefe has been legit on top of things and trying to help me.
I'm not necessarily convinced that we need an extra notice. And it's been frustrating to see how slowly a relatively simple, important NIP has been propagated, and that might be due to a lack of clarity and completeness.
@npub1wqf…cqsyn how is your AUTH implementation going?
I'm not necessarily convinced that we need an extra notice. And it's been frustrating to see how slowly a relatively simple, important NIP has been propagated, and that might be due to a lack of clarity and completeness.
@npub1wqf…cqsyn how is your AUTH implementation going?
