add nip-302 relay pools

302.md

@@ -0,0 +1,59 @@
+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.