nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-20 06:45:49 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity
3bbbe3ad71
nips/302.md
Ricardo Arturo Cabral Mejía 3bbbe3ad71
add nip-302 relay pools
2024-02-10 09:48:52 -08:00

2.9 KiB
Raw Blame History

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, NIP-98 or both.