Add NIP 43 for relay access requests

This commit is contained in:
Jon Staab 2024-02-26 09:27:05 -08:00
parent cbcb49fdcf
commit 6e3da0ffbe
2 changed files with 46 additions and 11 deletions

12
42.md
View File

@ -36,17 +36,7 @@ And, when sent by clients, the following form:
### Canonical authentication event
The signed event is an ephemeral event of `kind: 22242` and it should have at least two tags, one for the relay URL,
and one containing evidence of access. This may be one of:
- `challenge` - the challenge string recieved from the relay.
- `claim` - an arbitrary token exchanged out-of-band. Relays SHOULD store this authorization so that the `challenge`
method can be used in the future.
Clients MUST NOT publish these events. Relays MUST exclude `kind: 22242` events from being broadcasted to any client.
Relays MUST validate that `created_at` is the current time, adjusting for clock skew.
Example:
The signed event is an ephemeral event not meant to be published or queried, it must be of `kind: 22242` and it should have at least two tags, one for the relay URL and one for the challenge string as received from the relay. Relays MUST exclude `kind: 22242` events from being broadcasted to any client. `created_at` should be the current time. Example:
```json
{

45
43.md Normal file
View File

@ -0,0 +1,45 @@
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.
## Access Request Event
This NIP defines kind `22243` events which are intended to allow clients to request admission to a relay.
Access requests MUST have a `claim` tag containing an invoice, invite code, or any other arbitrary string.
The event's `created_at` MUST be the current time plus or minus a few minutes to prevent replay attacks.
Clients MAY send a claim at any time, but MUST check for relay support via NIP 11 to avoid non-compliant
relays broadcasting invites to subscribers.
This event should be sent to a relay using the standard `EVENT` verb.
```json
{
"kind": 22243,
"tags": [
["claim", "<invoice id, invite code, or something else>"]
],
...other fields
}
```
## Relay response
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 invoice is expired."]
["OK", <event-id>, false, "restricted: That is an unsupported claim."]
["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!"]
```