Add NIP 43 for joining relays using a claim

This commit is contained in:
Jonathan Staab 2023-05-13 15:37:34 -07:00 committed by Jon Staab
parent 1cda2dcc59
commit 4e78007e6b

66
43.md Normal file
View File

@ -0,0 +1,66 @@
NIP-43
======
Relay Access Requests
---------------------
`draft` `optional`
This NIP defines a way for clients to request admission to relays enforcing
authentication as defined in NIP 42 by signing an ephemeral event.
## Join Request
This NIP defines kind `28934` events which are intended to allow clients to
request admission to a relay. It MUST have a `claim` tag containing an invite
code.
The event's `created_at` MUST be now, plus or minus a few minutes. Clients MAY
send a claim at any time, but MUST check for relay support via NIP 11. This is
to avoid non-compliant relays broadcasting invites to subscribers.
This event should be sent to a relay using the standard `EVENT` verb.
```jsonc
{
"kind": 28934,
"tags": [
["claim", "<invite code>"]
],
// ...other fields
}
```
Upon receiving a claim, a relay MUST notify the client as to what the status
of the claim is using an `OK` message. Failed claims SHOULD use the same
standard `"restricted: "` prefix specified by NIP 42.
Some examples:
```
["OK", <event-id>, false, "restricted: That invite code is expired."]
["OK", <event-id>, false, "restricted: That is an invalid invite code."]
["OK", <event-id>, true, "claim-ignored: You are already a member of this relay."]
["OK", <event-id>, true, "claim-accepted: Welcome to wss://relay.bunk.skunk!"]
```
## Invite Request
Users may request a claim string from a relay by making a request for `kind 28935`
events. These events MUST NOT be considered valid unless signed by the same pubkey
as exists in the relay's NIP 11 document.
```jsonc
{
"kind": 28935,
"tags": [
["claim", "<invite code>"]
],
// ...other fields
}
```
Note that these events are in the `ephemeral` range, which means relays must explicitly
opt-in to this behavior by generating claims on the fly when requested. This allows relays
to improve security by issuing a different claim for each request, only issuing claims
to certain users, or expiring claims.