Clarify NIP-42 flow

[arthurfranca]

Previous discussion: #841 and #571

Added a paragraph to NIP-42 explaining the expected flow when relay sends an AUTH in response to a client message that requires authentication. This is a important detail that wasn't guaranteed to be followed by relays. Because of that, clients couldn't rely on it.

It uses the relay "buffering" method @staab suggested.

[monlovesmango]

I think if auth is needed we should just allow the relay to ignore the client 'REQ'/'EVENT' message and force the client to resend it after authentication. The waiting is ambiguous and adds a lot of complexity on both the relay and client sides without much gain.

your other pr #891 (which I like) would allow clients to proactively authenticate if they want to avoid the above scenario.

also, relays are within their right to proactively send an 'AUTH' request just based on whether the filter would potentially request authenticated events without them having to run the query and get the results first. if clients are only interested in events that don't require authentication they should be specifying the kind in their filters.

[staab]

After much discussion and a break from this topic, I think there is complexity whether the relay or the client does the buffering. I still don't like eager AUTH for privacy reasons (the easiest thing to do for clients is to always authenticate), but I accept that making the relay buffer messages isn't any better than having the client re-send messages. I will revisit #841. Thanks @arthurfranca!

[fiatjaf]

Has anyone tried to implement AUTH in a real-world scenario?

[arthurfranca]

If clients are only interested in events that don't require authentication they should be specifying the kind in their filters.

Very smart, its a good idea for relays to look at the kinds filter and if empty simply consider it as a restricted query.

I think there is complexity whether the relay or the client does the buffering.

Yeah this one adds complexity specially to relays. #891 helps mitigate some of NIP-42 problems by letting client authenticate before requesting but just when it thinks the request should use auth.

Has anyone tried to implement AUTH in a real-world scenario?

When receiving AUTH, my client prototype currently just does console.log('Oh noes AUTH!') and drops connection lol. That's because there's no way to know how relays implement it. (Is this like this PR? or does the relay wants me to retry REQ after authentication or what?)

[fiatjaf]

OK, I'm convinced.