Rename, recognize read relays

65.md

@@ -1,22 +1,28 @@
 NIP-65
 ======
 
-Feed Advertisements
+Relay List Metadata
 -------------------
 
 `draft` `optional` `author:mikedilger`
 
-A special replaceable event meaning "Feed Advertisement" is defined as an event with kind `10002` having a list of `r` tags, one for each relay the author posts their outgoing "feed" to.
+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.
 
-The content is not used.
+The primary purpose of this relay list is to advertise to others, not for configuring one's client.
 
-A feed consists of events that the author posts and wishes for their followers to "follow".  Normally these would be kind-1 Text Note events but is not limited as such.
+The content is not used and SHOULD be blank.
+
+The `r` tags can have a second parameter as either `read` or `write`. If it is omitted, it means the author both reads from and writes to that relay.
 
 Clients SHOULD, as with all replaceable events, use only the most recent kind-10002 event they can find.
 
-Clients SHOULD presume that if their user has a pubkey in their ContactList (kind 3) that it is because they wish to see this author's "feed" events. But clients MAY presume otherwise.
+### The meaning of read and write
 
-Clients SHOULD interpret these Feed Advertisements as being the best relays to source the "feed" events from the author of the feed advertisement.
+If an author advertises a write relay in a kind `10002` event, that means that feed-related events created by the author, which the author wants their followers to see, will be posted there. Normally these would be kind-1 Text Note events, but are not limited as such.
+
+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.
+
+If an author advertises a read relay in a kind `10002` event, that means that the author may be subscribed to events that tag them on such relays. Clients SHOULD publish events that tag someone on at least the read relays of the person being tagged.
 
 ### Motivation
 
@@ -30,20 +36,24 @@ Because users don't often share the same sets of relays, ad-hoc solutions have a
 
 ### Purposes
 
-The purpose of this NIP is to help clients find the events of the people they follow, and to help nostr scale better.
+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.
 
 ### Suggestions
 
-It is suggested that people spread their kind-10002 events to many relays, but to post their normal feed notes to a much smaller number of relays.  It is suggested that clients offer a way for users to spread their Feed Advertisements to many more relays than they normally post to.
+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.
 
-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 "Feed Advertisement".  For example, an author may want to reply to someone without all of their followers watching, but in many cases they want all their replies to show up in their "feed".
+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.
 
-It is suggsted 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
+It is suggsted 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
 
   - 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
@@ -52,7 +62,8 @@ It is suggsted that relays allow any user to write their own kind-10002 event (o
   "tags": [
     ["r", "wss://alicerelay.example.com"],
     ["r", "wss://brando-relay.com"],
-    ["r", "wss://expensive-relay.example2.com"],
+    ["r", "wss://expensive-relay.example2.com", "write"],
+    ["r", "wss://nostr-relay.example.com", "read"],
   ],
   "content": "",
   ...other fields

README.md

@@ -48,7 +48,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 | 43          | Channel Hide Message        | [28](28.md)            |
 | 44          | Channel Mute User           | [28](28.md)            |
 | 45-49       | Public Chat Reserved        | [28](28.md)            |
-| 10002       | Feed Advertisement          | [65](65.md)            |
+| 10002       | Relay List Metadata         | [65](65.md)            |
 | 22242       | Client Authentication       | [42](42.md)            |
 | 10000-19999 | Replaceable Events Reserved | [16](16.md)            |
 | 20000-29999 | Ephemeral Events Reserved   | [16](16.md)            |