From c49b36fa066b1ebcbd863eb230c9abae053d7aca Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Wed, 6 Mar 2024 04:51:16 -0800 Subject: [PATCH 1/4] Add DM relays to nip 65 --- 65.md | 60 +++++++++++++++++++++++++++++++++---------------------- README.md | 1 + 2 files changed, 37 insertions(+), 24 deletions(-) diff --git a/65.md b/65.md index 1a2d7e814..086cdc5cf 100644 --- a/65.md +++ b/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` tags 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's `r` tags 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's `r` tags 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 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 lists 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). diff --git a/README.md b/README.md index 3273ab067..55086404f 100644 --- a/README.md +++ b/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] | From fc20726c485ffc2bb434e6997108a42f1616b33e Mon Sep 17 00:00:00 2001 From: hodlbod Date: Wed, 6 Mar 2024 08:19:43 -0800 Subject: [PATCH 2/4] Update 65.md Co-authored-by: dluvian <133484344+dluvian@users.noreply.github.com> --- 65.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/65.md b/65.md index 086cdc5cf..e2f56bcfc 100644 --- a/65.md +++ b/65.md @@ -70,7 +70,7 @@ This NIP allows Clients to connect directly with the most up-to-date relay set f 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 lists events should primarily be used to advertise the user's preferred relays to others. +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). From 97e79c291672c46c16e70aa730d450d1de212c60 Mon Sep 17 00:00:00 2001 From: hodlbod Date: Wed, 6 Mar 2024 08:19:53 -0800 Subject: [PATCH 3/4] Update 65.md Co-authored-by: dluvian <133484344+dluvian@users.noreply.github.com> --- 65.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/65.md b/65.md index e2f56bcfc..e2862bd94 100644 --- a/65.md +++ b/65.md @@ -49,7 +49,7 @@ the author's `kind:10050` event, falling back to the `write` relayd defined by a When broadcasting a public event, Clients SHOULD: - Broadcast the event to the `write` relays of the author -- Broadcast the event all `read` relays of each tagged user +- Broadcast the event to all `read` relays of each tagged user - When broadcasting a private event, Clients SHOULD: From 3c4c19f2c4c05669d33cef8be50a8b8c6b78c51f Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Wed, 6 Mar 2024 08:23:03 -0800 Subject: [PATCH 4/4] Use relay instead of r --- 65.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/65.md b/65.md index e2862bd94..e6717d21b 100644 --- a/65.md +++ b/65.md @@ -6,7 +6,7 @@ Relay List Metadata `draft` `optional` -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` tags with relay URIs. The `.content` field is not used. +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. For example: @@ -26,12 +26,12 @@ For example: Event kinds defined: -- Kind `10002` indicates a user's default relay selections. This kind's `r` tags 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's `r` tags SHOULD include a `inbox` or `outbox` +- 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.