Compare commits

...

2 Commits

Author SHA1 Message Date
Leo Wandersleb
cc77619af8 replace jsonc syntax highlighting for javascript (#2100) 2025-10-30 05:30:15 -07:00
hodlbod
8054526b87 Add relay access requests (#1079)
Co-authored-by: Jonathan Staab <shtaab@gmail.com>
2025-10-30 07:44:48 -03:00
2 changed files with 153 additions and 7 deletions

146
43.md Normal file
View File

@@ -0,0 +1,146 @@
NIP-43
======
Relay Access Metadata and Requests
----------------------------------
`draft` `optional`
This NIP defines a way for relays to advertise membership lists, and for clients to request admission to relays on behalf of users.
## Membership Lists
Relays MAY publish a `kind 13534` event which indicates pubkeys that have access to a given relay. This event MUST be signed by the pubkey specified in the `self` field of the relay's [NIP 11](./11.md) document.
The following tags are required:
- A [NIP 70](./70.md) `-` tag
- A `member` tag containing a hex pubkey should be included for each member
This list should not be considered exhaustive or authoritative. To determine membership, both a `kind 13534` event by the relay, and a `kind 10010` event by the member should be consulted.
Example:
```jsonc
{
"kind": 13534,
"pubkey": "<nip11.self>",
"tags": [
["-"],
["member", "c308e1f882c1f1dff2a43d4294239ddeec04e575f2d1aad1fa21ea7684e61fb5"],
["member", "ee1d336e13779e4d4c527b988429d96de16088f958cbf6c074676ac9cfd9c958"]
],
// ...other fields
}
```
## Add User
Relays MAY publish a `kind 8000` event when a member is added to the relay. This event MUST be signed by the pubkey specified in the `self` field of the relay's [NIP 11](./11.md) document.
The following tags are required:
- A [NIP 70](./70.md) `-` tag
- A `p` tag indicating the member's hex pubkey
Example:
```jsonc
{
"kind": 8000,
"pubkey": "<nip11.self>",
"tags": [
["-"],
["p", "c308e1f882c1f1dff2a43d4294239ddeec04e575f2d1aad1fa21ea7684e61fb5"]
],
// ...other fields
}
```
## Remove User
Relays MAY publish a `kind 8001` event when a member is removed from the relay. This event MUST be signed by the pubkey specified in the `self` field of the relay's [NIP 11](./11.md) document.
The following tags are required:
- A [NIP 70](./70.md) `-` tag
- A `p` tag indicating the member's hex pubkey
Example:
```jsonc
{
"kind": 8001,
"pubkey": "<nip11.self>",
"tags": [
["-"],
["p", "c308e1f882c1f1dff2a43d4294239ddeec04e575f2d1aad1fa21ea7684e61fb5"]
],
// ...other fields
}
```
## Join Request
A user MAY send a `kind 28934` to a relay in order to request admission. It MUST have a `claim` tag containing an invite code. The event's `created_at` MUST be now, plus or minus a few minutes.
```jsonc
{
"kind": 28934,
"pubkey": "<user pubkey>",
"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.
Relays SHOULD update their `kind 13534` member list and MAY publish a `kind 8000` "add member" event.
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, "duplicate: you are already a member of this relay."]
["OK", <event-id>, true, "info: 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. This event MUST be signed by the pubkey specified in the `self` field of the relay's [NIP 11](./11.md) document.
```jsonc
{
"kind": 28935,
"pubkey": "<nip11.self>",
"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.
## Leave Request
A user MAY send a `kind 28936` to a relay in order to request that their access be revoked. The event's `created_at` MUST be now, plus or minus a few minutes. This event MUST include a [NIP 70](./70.md) `-` tag.
```jsonc
{
"kind": 28936,
"tags": [["-"]],
// ...other fields
}
```
Relays SHOULD update their `kind 13534` member list and MAY publish a `kind 8001` "remove member" event.
## Implementation
Clients MUST only request `kind 28935` events from and send `kind 28934` events to relays which include this NIP in the `supported_nips` section of its [NIP 11](./11.md) relay information document.

14
60.md
View File

@@ -22,7 +22,7 @@ This NIP doesn't deal with users' *receiving* money from someone else, it's just
3. A user has `kind:7376` events that represent the spending history of the wallet -- This history is for informational purposes only and is completely optional. 3. A user has `kind:7376` events that represent the spending history of the wallet -- This history is for informational purposes only and is completely optional.
### Wallet Event ### Wallet Event
```jsonc ```javascript
{ {
"kind": 17375, "kind": 17375,
"content": nip44_encrypt([ "content": nip44_encrypt([
@@ -45,7 +45,7 @@ Token events are used to record unspent proofs.
There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event. There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event.
```jsonc ```javascript
{ {
"kind": 7375, "kind": 7375,
"content": nip44_encrypt({ "content": nip44_encrypt({
@@ -78,7 +78,7 @@ The `kind:5` _delete event_ created in the [NIP-09](09.md) process MUST have a t
### Spending History Event ### Spending History Event
Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes. Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes.
```jsonc ```javascript
{ {
"kind": 7376, "kind": 7376,
"content": nip44_encrypt([ "content": nip44_encrypt([
@@ -115,7 +115,7 @@ From those relays, the client should fetch wallet and token events.
### Spending token ### Spending token
If Alice spends 4 sats from this token event If Alice spends 4 sats from this token event
```jsonc ```javascript
{ {
"kind": 7375, "kind": 7375,
"id": "event-id-1", "id": "event-id-1",
@@ -134,7 +134,7 @@ If Alice spends 4 sats from this token event
Her client: Her client:
* MUST roll over the unspent proofs: * MUST roll over the unspent proofs:
```jsonc ```javascript
{ {
"kind": 7375, "kind": 7375,
"id": "event-id-2", "id": "event-id-2",
@@ -153,7 +153,7 @@ Her client:
* MUST delete event `event-id-1` * MUST delete event `event-id-1`
* SHOULD add the `event-id-1` to the `del` array of deleted token-ids. * SHOULD add the `event-id-1` to the `del` array of deleted token-ids.
* SHOULD create a `kind:7376` event to record the spend * SHOULD create a `kind:7376` event to record the spend
```jsonc ```javascript
{ {
"kind": 7376, "kind": 7376,
"content": nip44_encrypt([ "content": nip44_encrypt([
@@ -171,7 +171,7 @@ When creating a quote at a mint, an event can be used to keep the state of the q
However, application developers SHOULD use local state when possible and only publish this event when it makes sense in the context of their application. However, application developers SHOULD use local state when possible and only publish this event when it makes sense in the context of their application.
```jsonc ```javascript
{ {
"kind": 7374, "kind": 7374,
"content": nip44_encrypt("quote-id"), "content": nip44_encrypt("quote-id"),