add nip-302 relay pool to readme

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.

97.md

@@ -1,41 +0,0 @@
-NIP-97
-======
-
-Login with Nostr
-----------------
-
-`draft` `optional`
-
-This NIP defines a flow for applications to request from a user that they control a private key for. This enables logging into applications (such as paid relay/media hosting services) without having to use other flows which may be annoying to use or not available. (DM codes, NIP-07 extensions)
-
-## Login URI
-
-A login URI is defined of the format `nostr+login:<domain>:<challenge>` where `domain` MUST be a valid DNS domain or .onion service. The `challenge` MUST only consist of `A-Z a-z 0-9 _ - .`.
-
-This login URI can be presented as a clickable link, a QR code or a copyable string.
-
-## Login process
-
-A client that wishes to log in to a service SHOULD display the domain associated with the service to the end user before allowing them to log in to prevent services showing a login string for another service.
-
-After the user approves the login, the client should send a POST request to `/.well-known/nostr/nip97` to the `domain` with the `i` query parameter set to the `challenge` and a valid NIP-98 authentication header present.
-
-The response MUST be a JSON object, with the format:
-```json
-{
-  "status": <"success" or "error">,
-  "message": <OPTIONAL string message to show user in the case of an error>,
-  "redirect_url": <OPTIONAL redirect URL>
-}
-```
-
-For `redirect_url`, this should be used to bring the user to where they were while initiating the login process (now with the login complete).
-This should be used in a way that is compatible with a different device being used to authorize the sign in than the one being logged in on.
-An example for this is checking if the sign in was attempted from this device with a cookie, if so, redirect the user to where wanted to log in,
-otherwise show a "continue on device" message.
-
-The `redirect_url` SHOULD be shown to the user and in a way that indicates it will take the user back to the app, such as `Return to website`.
-
-HTTPS should always be used except for `.onion` services, which should be contacted using HTTP.
-
-Clients MAY or MAY NOT decide to implement support for `.onion` services.

README.md

@@ -78,6 +78,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-96: HTTP File Storage Integration](96.md)
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
+- [NIP-302: Relay Pools](302.md)
 
 ## Event Kinds
 | kind          | description                | NIP                      |
@@ -91,7 +92,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `6`           | Repost                     | [18](18.md)              |
 | `7`           | Reaction                   | [25](25.md)              |
 | `8`           | Badge Award                | [58](58.md)              |
-| `13`          | Seal                       | [59](59.md)              |
 | `16`          | Generic Repost             | [18](18.md)              |
 | `40`          | Channel Creation           | [28](28.md)              |
 | `41`          | Channel Metadata           | [28](28.md)              |
@@ -101,7 +101,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1021`        | Bid                        | [15](15.md)              |
 | `1022`        | Bid confirmation           | [15](15.md)              |
 | `1040`        | OpenTimestamps             | [03](03.md)              |
-| `1059`        | Gift Wrap                  | [59](59.md)              |
 | `1063`        | File Metadata              | [94](94.md)              |
 | `1311`        | Live Chat Message          | [53](53.md)              |
 | `1971`        | Problem Tracker            | [nostrocket][nostrocket] |
@@ -111,6 +110,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `5000`-`5999` | Job Request                | [90](90.md)              |
 | `6000`-`6999` | Job Result                 | [90](90.md)              |
 | `7000`        | Job Feedback               | [90](90.md)              |
+| `8000`        | Relay Pool Join Request    | [302](302.md)            |
 | `9041`        | Zap Goal                   | [75](75.md)              |
 | `9734`        | Zap Request                | [57](57.md)              |
 | `9735`        | Zap                        | [57](57.md)              |
@@ -140,6 +140,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30004`       | Curation sets              | [51](51.md)              |
 | `30008`       | Profile Badges             | [58](58.md)              |
 | `30009`       | Badge Definition           | [58](58.md)              |
+| `30010`       | Relay Pool                 | [302](302.md)            |
 | `30015`       | Interest sets              | [51](51.md)              |
 | `30017`       | Create or update a stall   | [15](15.md)              |
 | `30018`       | Create or update a product | [15](15.md)              |
@@ -209,6 +210,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `t`               | hashtag                              | --                   |                                       |
 | `alt`             | summary                              | --                   | [31](31.md)                           |
 | `amount`          | millisatoshis, stringified           | --                   | [57](57.md)                           |
+| `auth-required`   | either nip-42 or nip-98              | --                   | [302](302.md)                         |
 | `bolt11`          | `bolt11` invoice                     | --                   | [57](57.md)                           |
 | `challenge`       | challenge string                     | --                   | [42](42.md)                           |
 | `client`          | name, address                        | relay URL            | [89](89.md)                           |