Shrink NIP-65 so it is clearer (#1879)

Co-authored-by: Vitor Pamplona <vitor@vitorpamplona.com>

1 files changed, 11 insertions, 39 deletions

diff --git a/65.md b/65.md
index a4d34a5..2e7f6ef 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.
+Defines a replaceable event using `kind:10002` to advertise relays where the user generally **writes** to and relays where the user generally **reads** mentions.
 
-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.
+The event MUST include a list of `r` tags with relay URLs as value and an optional `read` or `write` marker. If the marker is omitted, the relay is both **read** and **write**.
 
 ```jsonc
 {
@@ -26,45 +24,19 @@ The `.content` is not used.
 }
 ```
 
-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
-
-When seeking events **from** a user, Clients SHOULD use the WRITE relays of 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 broadcasting an event, Clients SHOULD:
-
-- Broadcast the event to the WRITE relays of the author
-- Broadcast the event to all READ relays of each tagged user
-
-## Motivation
-
-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
-
-1. Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays). 
+When downloading events **from** a user, clients SHOULD use the **write** relays of that user.
 
-2. Clients SHOULD spread an author's `kind:10002` event to as many relays as viable. 
+When downloading events **about** a user, where the user was tagged (mentioned), clients SHOULD use the user's **read** relays.
 
-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.
+When publishing an event, clients SHOULD:
 
-4. DMs SHOULD only be broadcasted to the author's WRITE relays and to the receiver's READ relays to keep maximum privacy. 
+- Send the event to the **write** relays of the author
+- Send the event to all **read** relays of each tagged user
 
-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.
+### Size
 
-6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
+Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays of each category).
 
-7. When publishing to a relay, clients SHOULD ensure the user's `kind 10002` is also available on that relay. Relays SHOULD accept and serve `kind 10002` notes for any pubkey whose notes they store. Relays MAY scrape the network for missing `kind 10002` events. The goal here is that for any note served from a relay the user can also request the author's relay selections as a way of bootstrapping further context discovery.
+### Discoverability
 
-## Related articles
-- [Outbox model](https://mikedilger.com/gossip-model/)
-- [What is the Outbox Model?](https://habla.news/u/hodlbod@coracle.social/8YjqXm4SKY-TauwjOfLXS)
+Clients SHOULD spread an author's `kind:10002` event to as many relays as viable, paying attention to relays that, at any moment, serve naturally as well-known public indexers for these relay lists (where most other clients and users are connecting to in order to publish and fetch those).