mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-09-20 06:45:49 -04:00
60 lines
2.9 KiB
Markdown
60 lines
2.9 KiB
Markdown
|
NIP-302
|
||
|
|
=========
|
||
|
|
|
||
|
|
Relay Pools
|
||
|
|
-----------
|
||
|
|
|
||
|
|
`draft` `optional`
|
||
|
|
|
||
|
|
# Introduction
|
||
|
|
|
||
|
|
This NIP introduces a system for the creation, management, and utilization of relay pools.
|
||
|
|
|
||
|
|
# Specification
|
||
|
|
|
||
|
|
## Creating a Relay Pool
|
||
|
|
|
||
|
|
Users initiate a relay pool by creating a Nostr event with `kind` 30010.
|
||
|
|
- The `content` field is the description of the relay pool.
|
||
|
|
- A `d` tag has the name of the relay pool (e.g. awesome-pool) as value.
|
||
|
|
- At least one `r` tag MUST be present with the third value as `"pool"`. These pool addresses are URLs clients can connect to.
|
||
|
|
- Zero or more `r` tags with third value as `"member"`, empty string, or missing signify a relay pool member.
|
||
|
|
- Zero or more `auth-required` tags with one of the following values: `nip-42` or `nip-98`. Clients wishing to connect to Relay Pools with an `auth-required` tag MUST support at least one of the NIPs before initiating a connection.
|
||
|
|
|
||
|
|
## Updating the Relay Pool
|
||
|
|
|
||
|
|
To update the relay member list of a relay pool, pool addresses, a new event of kind 30010 with the same `d` tag MUST be published.
|
||
|
|
Pool addresses and member relays are added or removed at any time.
|
||
|
|
|
||
|
|
## Joining a Relay Pool
|
||
|
|
|
||
|
|
Relay operators wishing to join a relay pool publish a Relay Pool Join Request event with `kind` 8000:
|
||
|
|
- `p` tag referencing the pubkey of the Relay Pool (event kind 30010).
|
||
|
|
- `a` tag addressing the kind 30010 event.
|
||
|
|
- a single `r` tag with the relay address (e.g., wss://cool-relay.cool-domain.com).
|
||
|
|
|
||
|
|
## Inclusion in the Relay Pool
|
||
|
|
|
||
|
|
Relay Pool Operators MAY include new member relays by updating the Relay Pool event and adding their `r` tag from the kind 8000 event.
|
||
|
|
|
||
|
|
### Leaving a Relay Pool
|
||
|
|
|
||
|
|
Member Relay Operators can request removal from a relay pool by publishing an Event Deletion (kind 5) referencing their Relay Pool Join Request event (kind 8000).
|
||
|
|
Upon receiving a kind 5 event, the Relay Pool Operator SHOULD issue a new event of kind 30010, removing the `r` tag that references the parting relay.
|
||
|
|
|
||
|
|
# Verification
|
||
|
|
|
||
|
|
Relay Pool Operators MAY require further steps as part of the application process (e.g. proof of work (mined event), payment or out-of-channel communication).
|
||
|
|
Relay Pool Operators MAY respond with kind 1 note to Relay Pool Join Requests events by referencing the event kind 8000 and/or tagging the requester's pubkey.
|
||
|
|
A Relay Pool is only successfully joined once a new Relay Pool event is published including the `r` tag from the Relay Pool Join Request.
|
||
|
|
|
||
|
|
# Client Connection
|
||
|
|
|
||
|
|
Clients can discover relay pools by subscribing to events of kind 30010.
|
||
|
|
Clients MUST connect directly to the relay pool addresses in order to be routed to member relays.
|
||
|
|
Relay Pools SHOULD distribute client connections among Relay Pool Members using a fair algorithm.
|
||
|
|
|
||
|
|
## Proxying and Authentication
|
||
|
|
Relay Pools MAY serve incoming WebSockets connections either by passthrough or by redirect.
|
||
|
|
Relay Pools that require authentication (e.g. for paid relay pools) MUST support either [NIP-42](42.md), [NIP-98](98.md) or both.
|