I think this PR alone is a simple way to fix most NIP-42 problems and is ready to be merged.

While #841 is a good optional addition that we should think if is worth the trouble.

personally, I completely agree

I think this PR actually fixes nothing and the other one is better. If clients know when to auth then it can auth when the relay asks immediately with no delay.

If clients know when to auth then it can auth when the relay asks immediately with no delay.

Currently a client (REQ|EVENT|...) msg is sent before receiving a relay AUTH msg. Cause there's nothing written that tells the client should wait for a challenge before sending a possibly restricted message. There's no relay-client handshake requirement, no guaranteed relay AUTH msg holding a challenge upon connection.

We could edit #841 a bit to expect relays that support NIP-42 to always send the challenge on connection. (Of course a client would still have to check NIP-11 in look for NIP-42 support so to not wait forever for the challenge). Not pretty but there aren't many options.

It's impossible for clients to figure out when to request an AUTH because they don't know how the relay is implemented. I don't think a handshake is needed before sending a possibly restricted message. It's very easy to send and deal with whatever comes back.

We could edit #841 a bit to expect relays that support NIP-42 to always send the challenge on connection.

That's not right. We should expect relays to only send the challenge when the app requests access to the restricted part. Otherwise, things should work without it.

We should expect relays to only send the challenge when the app requests access to the restricted part. Otherwise, things should work without it.

This sounds good to me. However we need to make sure that everyone is in agreement with this pattern. Right now there is no explicit expectation of when relays should send the AUTH which is what @arthurfranca is trying to nail down. Also, if this is the pattern we want to adopt I would say that either #841 or #846 is necessary in order to define expected behaviors for the clients and relays. my preference is for #841 .

I was only in favor of this PR over #841 because I assumed we would allow relays to decide when to send the AUTH event. But I much prefer dictating that the relay should only send AUTH once its needed as @vitorpamplona suggested.

Yeah so we're back to #841 vs #846.

#841 flow is: hey send some of my DMs > relay AUTH with sub id > EOSE > client AUTH > hey send some of my DMs (notice there's no way to auth before asking for DMS so client retries with new sub) > DMs > EOSE

#846 flow is: hey send some of my DMs > relay AUTH > ... relay waits up to ~3 min (holds the sub until client auths)
|_ EOSE
or
|_ client AUTH > DMs > EOSE

While this PR's (#891) flow is:
hmm this relay supports NIP-42 (nip11) > Gimme challenge > relay AUTH > client AUTH > hey send some of my DMs > DMs > EOSE

The idea of this PR is that if the client knows what it is willing to authenticate for, it can ask for the challenge and authenticate before requesting anything, so it doesn't matter how relays implement it internally.

me too

Glad to have this discussion cleared up in a completely unexpected, clean way.