Kind 5951: Relay Access Request

[alexgleason]

Alternative solution to nostr-protocol/nips#1079

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

Read here.

[staab]

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.

[staab]

What's the use case for this?

[alexgleason]

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]

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]

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.