Simplifies NIP-65 (#700)

Co-authored-by: fiatjaf_ <fiatjaf@gmail.com>
Co-authored-by: Jon Staab <jstaab@protonmail.com>

1 files changed, 35 insertions, 50 deletions

diff --git a/65.md b/65.md
index 55f9ff0..3c06438 100644
--- a/65.md
+++ b/65.md
@@ -4,73 +4,58 @@ NIP-65
 Relay List Metadata
 -------------------
 
-`draft` `optional` `author:mikedilger`
+`draft` `optional` `author:mikedilger` `author:vitorpamplona`
 
-A special replaceable event meaning "Relay List Metadata" is defined as an event with kind `10002` having a list of `r` tags, one for each relay the author uses to either read or write to.
+Defines a replaceable event using `kind:10002` to advertise preferred relays for discovering a user's content and receiving fresh content from others.
 
-The primary purpose of this relay list is to advertise to others, not for configuring one's client.
+The event MUST include a list of `r` tags with relay URIs and a `read` or `write` marker. If the marker is omitted, the relay is used for both purposes.
 
-The `content` is not used and SHOULD be an empty string.
+The `.content` is not used.
 
-The `r` tags can have a second parameter as either `read` or `write`. If it is omitted, it means the author uses the relay for both purposes.
-
-Clients SHOULD, as with all replaceable events, use only the most recent kind-10002 event they can find.
-
-### The meaning of read and write
-
-Write relays are for events that are intended for anybody (e.g. your followers). Read relays are for events that address a particular person.
+```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
+```
 
-Clients SHOULD write feed-related events created by their user to their user's write relays.
+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.
 
-Clients SHOULD read feed-related events created by another from at least some of that other person's write relays. Explicitly, they SHOULD NOT expect them to be available at their user's read relays. It SHOULD NOT be presumed that the user's read relays coincide with the write relays of the people the user follows.
+## When to Use Read and Write
 
-Clients SHOULD read events that tag their user from their user's read relays.
+When seeking events **from** a user, Clients SHOULD use the WRITE relays of the user's `kind:10002`
 
-Clients SHOULD write events that tag a person to at least some of that person's read relays. Explicitly, they SHOULD NOT expect that person will pick them up from their user's write relays. It SHOULD NOT be presumed that the user's write relays coincide with the read relays of the person being tagged.
+When seeking events **about** a user, where the user was tagged, Clients SHOULD use the READ relays of the user's `kind:10002` 
 
-Clients SHOULD presume that if their user has a pubkey in their ContactList (kind 3) that it is because they wish to see that author's feed-related events. But clients MAY presume otherwise.
+When broadcasting an event, Clients SHOULD:
 
-### Motivation
+- Broadcast the event to the WRITE relays of the author
+- Broadcast the event all READ relays of each tagged user. 
 
-There is a common nostr use case where users wish to follow the content produced by other users. This is evidenced by the implicit meaning of the Contact List in [NIP-02](02.md)
+## Motivation
 
-Because users don't often share the same sets of relays, ad-hoc solutions have arisen to get that content, but these solutions negatively impact scalability and decentralization:
+The old model of using a fixed relay list per user centralizes in large relay operators: 
 
-  - Most people are sending their posts to the same most popular relays in order to be more widely seen
-  - Many people are pulling from a large number of relays (including many duplicate events) in order to get more data
+  - 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. 
 
-### Purposes
-
-The purpose of this NIP is to help clients find the events of the people they follow, to help tagged events get to the people tagged, and to help nostr scale better.
+## Final Considerations
 
-### Suggestions
+1. Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays). 
 
-It is suggested that people spread their kind `10002` events to many relays, but write their normal feed-related events to a much smaller number of relays (between 2 to 6 relays). It is suggested that clients offer a way for users to spread their kind `10002` events to many more relays than they normally post to.
+2. Clients SHOULD spread an author's `kind:10002` events to as many relays as viable. 
 
-Authors may post events outside of the feed that they wish their followers to follow by posting them to relays outside of those listed in their "Relay List Metadata".  For example, an author may want to reply to someone without all of their followers watching.
+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.
 
-It is suggested that relays allow any user to write their own kind `10002` event (optionally with AUTH to verify it is their own) even if they are not otherwise subscribed to the relay because
+4. DMs SHOULD only be broadcasted to the author's WRITE relays and to the receiver's READ relays to keep maximum privacy. 
 
-  - finding where someone posts is rather important
-  - these events do not have `content` that needs management
-  - relays only need to store one replaceable event per pubkey to offer this service
-
-### Why not in kind `0` Metadata
-
-Even though this is user related metadata, it is a separate event from kind `0` in order to keep it small (as it should be widely spread) and to not have `content` that may require moderation by relay operators so that it is more acceptable to relays.
-
-### Example
-
-```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
-```
+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.