Skip to content

Clarify NIP-42 flow#846

Closed
arthurfranca wants to merge 1 commit intonostr-protocol:masterfrom
arthurfranca:42-flow
Closed

Clarify NIP-42 flow#846
arthurfranca wants to merge 1 commit intonostr-protocol:masterfrom
arthurfranca:42-flow

Conversation

@arthurfranca
Copy link
Copy Markdown
Contributor

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
Copy link
Copy Markdown
Member

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
Copy link
Copy Markdown
Member

staab commented Nov 21, 2023

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!

@staab staab mentioned this pull request Nov 21, 2023
@fiatjaf
Copy link
Copy Markdown
Member

fiatjaf commented Nov 21, 2023

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

@arthurfranca
Copy link
Copy Markdown
Contributor Author

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
Copy link
Copy Markdown
Member

fiatjaf commented Nov 21, 2023

OK, I'm convinced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants