update NIP-65: add DM relays, clarify when to use all vs some of a relay kind

65.md

@@ -6,59 +6,137 @@ Relay List Metadata
 
 `draft` `optional`
 
-Defines a replaceable event using `kind:10002` to advertise preferred relays for discovering a user's content and receiving fresh content from others.
+Defines two replaceable events to advertise preferred relays for discovering a user's content and receiving fresh content from others.
 
-The event MUST include a list of `r` tags with relay URIs and a `read` or `write` marker. Relays marked as `read` / `write` are called READ / WRITE relays, respectively. If the marker is omitted, the relay is used for both purposes.
+Relay Usages
+------------
+
+There are three defined usages for a relay:
+
+- `INBOX` relays store public events that mention the relay list owner. Any user can publish and download such events from this relay. The relay list owner generally monitors these relays for events mentioning them.
+
+- `OUTBOX` relays store events that the relay list owner has authored. Any user can publish and download such events from this relay.
+
+- `PRIVATE INBOX` relays store private events that mention the relay list owner, such as perhaps direct messages (DMs) and giftwraps. Any user can publish such events to this relay, but may not be able to download them (depending on the relay's actual behavior).
+
+### When to use which
+
+When publishing public events:
+
+- Clients SHOULD publish events to all of the signer's OUTBOX relays.
+- Clients SHOULD publish the event to all of the INBOX relays of each tagged key.
+
+When publishing private messages:
+
+- Clients SHOULD publish events to all of the PRIVATE INBOX relays of each of the recipients.
+- Clients SHOULD publish a copy to all of their client user's own PRIVATE INBOX relays.
+
+When seeking events from a user:
+
+- Clients SHOULD seek them from at least some of that user's OUTBOX relays.
+
+When seeking events about a client's user (where the user was tagged):
+
+- Clients SHOULD seek them from at least some of their user's INBOX relays.
+
+When seeking private messages for a client's user:
+
+- Clients SHOULD seek them from at least some of their user's PRIVATE INBOX relays.
+
+In general, writers write to all relays in a set, and readers only have to read from some relays in a set.
+
+Clients should expect PRIVATE INBOX relays to require AUTH for reading private messages. See [NIP-42](42.md).
+
+Relay List Event
+----------------
+
+`kind:10102` is a relay list event.
+
+This event SHOULD include `relay-usage` tags of the following form:
+
+```json
+["relay-usage", "<relay-url>", "<usage-flags>"]
+```
+
+`usage-flags` includes a sequence of letters, which of which MUST be one of the following:
+
+- `i` - This indicates the relay is used as the user's INBOX
+- `o` - This indicates the relay is used as the user's OUTBOX
+- `p` - This indicates the relay is used for the user's PRIVATE messages
+
+`usage-flags` SHOULD not have duplicate letters. Clients should ignore and preserve any other letters found that they do not understand.
 
 The `.content` is not used.
 
+### Example:
+
 ```json
 {
-  "kind": 10002,
+  "kind": 10102,
   "tags": [
-    ["r", "wss://alicerelay.example.com"],
-    ["r", "wss://brando-relay.com"],
-    ["r", "wss://expensive-relay.example2.com", "write"],
-    ["r", "wss://nostr-relay.example.com", "read"]
+    ["relay-usage", "wss://alicerelay.example.com", "io"],
+    ["relay-usage", "wss://brando-relay.com", "io"],
+    ["relay-usage", "wss://expensive-relay.example2.com", "o"],
+    ["relay-usage", "wss://nostr-relay.example.com", "i"],
+    ["relay-usage", "wss://secure.example.com", "p"],
   ],
   "content": "",
   ...other fields
 }
 ```
 
-This NIP doesn't fully replace relay lists that are designed to configure a client's usage of relays (such as `kind:3` style relay lists). Clients MAY use other relay lists in situations where a `kind:10002` relay list cannot be found.
+Deprecated Relay List Event
+---------------------------
 
-## When to Use Read and Write Relays
+`kind:10002` is the deprecated version of the relay list event. Clients will want to create this to support existing clients that have not upgraded to the new `kind:10102`.
 
-When seeking events **from** a user, Clients SHOULD use the WRITE relays of the user's `kind:10002`.
+This event SHOULD include `r` tags of the following form:
 
-When seeking events **about** a user, where the user was tagged, Clients SHOULD use the READ relays of the user's `kind:10002`.
+```json
+["r", "<relay-url>", "<read-or-write>"]
+```
+`read-or-write` MUST be the string `"read"` (for an INBOX) or the string `"write"` (for an OUTBOX), or it should be left out (or empty). If it is left out (or empty) the relay is both an INBOX and an OUTBOX. Clients should ignore and preserve any other strings found that they do not understand.
+
+The `.content` is not used.
 
-When broadcasting an event, Clients SHOULD:
+### Example:
 
-- Broadcast the event to the WRITE relays of the author
-- Broadcast the event all READ relays of each tagged user
+```json
+{
+  "kind": 10002,
+  "tags": [
+    ["r", "wss://alicerelay.example.com"],
+    ["r", "wss://brando-relay.com"],
+    ["r", "wss://expensive-relay.example2.com", "write"],
+    ["r", "wss://nostr-relay.example.com", "read"],
+  ],
+  "content": "",
+  ...other fields
+}
+```
 
 ## Motivation
 
-The old model of using a fixed relay list per user centralizes in large relay operators: 
+The old model of using a fixed relay list per user centralizes in large relay operators:
 
   - Most users submit their posts to the same highly popular relays, aiming to achieve greater visibility among a broader audience
   - Many users are pulling events from a large number of relays in order to get more data at the expense of duplication
   - Events are being copied between relays, oftentimes to many different relays
-  
-This NIP allows Clients to connect directly with the most up-to-date relay set from each individual user, eliminating the need of broadcasting events to popular relays. 
+
+This NIP allows Clients to connect directly with the most up-to-date relay set from each individual user, eliminating the need of broadcasting events to popular relays.
 
 ## Final Considerations
 
-1. Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays). 
+1. Authors may publish to their own INBOX relays events that they intend to read back later. This doesn't make them OUTBOX relays.
+
+2. Clients SHOULD guide users to keep relay lists small (2-6 relays).
 
-2. Clients SHOULD spread an author's `kind:10002` event to as many relays as viable. 
+3. Clients SHOULD advertise an author's relay list events to as many relays as viable.
 
-3. `kind:10002` events should primarily be used to advertise the user's preferred relays to others. A user's own client may use other heuristics for selecting relays for fetching data.
+4. Relay list events should primarily be used to advertise the user's preferred relays to others. A user's own client may use other heuristics for selecting relays for fetching data or for other purposes. Clients MAY use other relay lists (such as `kind:3` contents) in situations where a `kind:10002` relay list cannot be found.
 
-4. DMs SHOULD only be broadcasted to the author's WRITE relays and to the receiver's READ relays to keep maximum privacy. 
+5. Private messages SHOULD only be broadasted to the author's PRIVATE INBOX relays and to the receiver's PRIVAT INBOX relays to keep maximum privacy. If either party doesn't have PRIVATE INBOX relays, INBOX relays should be used instead. Please refer to the private messaging NIP in question as it supercedes.
 
-5. If a relay signals support for this NIP in their [NIP-11](11.md) document that means they're willing to accept kind 10002 events from a broad range of users, not only their paying customers or whitelisted group.
+6. If a relay signals support for this NIP in their [NIP-11](11.md) document that means they're willing to accept kind 10002 events (and hopefully kind 10102 events) from a broad range of users, not only their paying customers or whitelisted group.
 
-6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
+7. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).