Add DM relays to nip 65

65.md

@@ -6,11 +6,9 @@ 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.
+This NIP defines a series of replaceable event kinds for advertising user relay preferences, each with a particular purpose. These events MUST include a list of `r` or `relay` tags (depending on event kind) with relay URIs. The `.content` field is not used.
 
-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.
-
-The `.content` is not used.
+For example:
 
 ```json
 {
@@ -26,39 +24,53 @@ The `.content` is not used.
 }
 ```
 
+Event kinds defined:
+
+- Kind `10002` indicates a user's default relay selections. This kind uses `r` tags, which SHOULD include a `read` or `write`
+  mark indicating whether the author reads from or writes to the given relay. If the marker is omitted, the relay is used for
+  both purposes.
+- Kind `10050` indicates a user's messaging relay selections. This kind uses `relay` tags, which SHOULD include a `inbox`
+  or `outbox` mark indicating whether the author reads from or writes to the given relay. If the marker is omitted,
+  the relay is used for both purposes.
+
 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.
 
-## When to Use Read and Write Relays
+## Relay Selection
 
-When seeking events **from** a user, Clients SHOULD use the WRITE relays of the user's `kind:10002`.
+When seeking public, non-encrypted events authored by a user, Clients SHOULD use the `write` relays defined by the
+user's `kind:10002`.
 
-When seeking events **about** a user, where the user was tagged, Clients SHOULD use the READ relays of the user's `kind:10002`.
+When seeking public, non-encrypted events where a given user was tagged, Clients SHOULD use the `read` relays defined by
+the user's `kind:10002`.
 
-When broadcasting an event, Clients SHOULD:
+When seeking private or encrypted events authored by a user, Clients SHOULD use the `outbox` relays defined by
+the author's `kind:10050` event, falling back to the `write` relayd defined by author's `kind:10002` event.
 
-- Broadcast the event to the WRITE relays of the author
-- Broadcast the event all READ relays of each tagged user
+When broadcasting a public event, Clients SHOULD:
+
+- Broadcast the event to the `write` relays of the author
+- Broadcast the event to all `read` relays of each tagged user
+-
+When broadcasting a private event, Clients SHOULD:
+
+- Broadcast the event to the `outbox` relays of the author, falling back to the author's `write` relays
+- Broadcast the event all `inbox` relays of the recipient, falling back to the author's `read` relays
 
 ## 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. 
 
-## Final Considerations
+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.
 
-1. Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays). 
-
-2. Clients SHOULD spread an author's `kind:10002` event 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. DMs SHOULD only be broadcasted to the author's WRITE relays and to the receiver's READ relays to keep maximum privacy. 
-
-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.
+## Final Considerations
 
-6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
+1. Clients SHOULD guide users to keep relay lists small (2-4 relays).
+2. Clients SHOULD spread an author's relay metadata events to as many relays as viable.
+3. 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.
+4. If a relay signals support for this NIP in their [NIP-11](11.md) document that means they're willing to accept relay list events from a broad range of users, not only their paying customers or whitelisted group.
+5. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).

README.md

@@ -126,6 +126,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10007`       | Search relays list         | [51](51.md)              |
 | `10015`       | Interests list             | [51](51.md)              |
 | `10030`       | User emoji list            | [51](51.md)              |
+| `10050`       | Inbox/Outbox relay list    | [65](65.md)              |
 | `10096`       | File storage server list   | [96](96.md)              |
 | `13194`       | Wallet Info                | [47](47.md)              |
 | `21000`       | Lightning Pub RPC          | [Lightning.Pub][lnpub]   |