Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kind 5951: Relay Access Request #26

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

alexgleason
Copy link
Member

@alexgleason alexgleason commented Feb 28, 2024

Alternative solution to nostr-protocol/nips#1079

Allows users to request access to relays using a NIP-90 flow.

Read here.

Copy link
Member

@staab staab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this in theory, but it's really annoying in practice, since you need to look up the nip11 document for the relay to find out its pubkey. Maybe I'm being a whiner but I'd like to either address the relay directly, or maybe ask it for its nip11 via the connection I already have. You also have to check that the nip11's pubkey matches the DVM's pubkey, which is a chore, and you also have no way to know if the relay has a DVM. I don't know, this just seems too byzantine for a simple use case. If there are more complex authorization schemes that this fixes I could be persuaded.

# Input

The URL (eg `wss://relay.mostr.pub/`), if any.
If no input is provided, the client is relying on DVMs to suggest relays to the user.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the use case for this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might want to join a private relay but you don't know which one. DVMs will respond and say "You can join wss://nostr.wine/, just pay us X sats"

@alexgleason
Copy link
Member Author

I think it is equally as simple as nostr-protocol/nips#1079 for the invite flow.

Send a message like this directly to the relay in question, and it automatically creates an account for you:

{
  kind: 5951,
  tags: [
    ["i", "wss://nostr.wine/", "text"],
    ["param", "invite", "abcd..."],
  ]
}

No other action is needed. When you have an invite code, it means the relay already supports this action, and it's likely not going to charge you for it (or you already paid another way). NIP-11 lookups are only useful when payment is involved (same as with #25).

Your ninvite idea would also still work.

But this would also enable a traditional signup flow. If you don't provide a token, the bot can prompt you for payment, or possibly other forms of verification before final approval.

This will also enable "by-approval" registrations, a feature I need for supporting Mastodon API in my project. In that flow a user can submit a request to register, and then an admin of the site has to manually approve their request by checking their profile in a waitlist. The asynchronous nature of NIP-90 will let me collect the request, notify the user they have to wait using a feedback event, notify the admin to review the request, and then notify the user once they've been approved. It's just one example of an alternate flow. This system can support many different flows ranging from simple to complex. So I stan it.

@alexgleason
Copy link
Member Author

Here are my best arguments against it being too complicated:

  • Having the simplest flow for many different signup use cases is actually more complicated overall
  • The feedback step is REQUIRED for this sort of flow

If we chose to not shoehorn this into NIP-90, we would still have to develop a flow with almost the exact same semantics: request-feedback-response. Without that you can't deliver on the UX.

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.

2 participants