Add missing pieces

102.md

@@ -22,40 +22,73 @@ has a configuration array as an extra argument:
 
 `["PRIVATE_EVENT", {<event JSON>}, [<configuration array>]]`
 
+The event author must be authenticated using NIP-43
+before sending the message.
+
 The message can be sent more than once by the event author
 to change the configuration array.
 
+If the configuration array is absent or empty, the event becomes public.
+
 ## Access Control
 
 The private event can be accessed by its `author`, by a `pubkey`
 referenced in the configuration array or by `pubkeys` inside the
 event referenced in the configuration array as `p` tags.
 
-The user fetches events as usual with NIP-01 `REQ` message. Only allowed users authenticated to the relay using NIP-43 will
+The user fetches events as usual with NIP-01 `REQ` message.
+Only allowed users authenticated to the relay using NIP-43 will
 receive private events that match the filters.
 
 ## Configuration Array
 
 The config array has atleast two items. The first is the identifier type and the second is the identifier value.
 
-The identifier type can be `p`, `e` or `a`.
+The identifier type can be `p`, `e`, `a` or `u`.
 
 When `p`, the referenced pubkey value is allowed to access the private event.
+For example, useful for DMs.
 
 Identifier value for `e` and `a` types may be any event that contains `p`
 tags. These `p` tags are the users allowed to access the private event.
-
 For example `e` and `a` can be a list or a group
 creation/metadata event that contains `p` tags (both encrypted or not).
 The event should be sent to the used relay.
 
+Identifier value for `u` types may reference any unbounded list with each
+item holding one `p` tag, allowing, for example, for the creation of private
+feeds meant to be read only by an unbounded number of paying subscribers.
+
 Optionally, there is a third configuration array value with
-a private key that can decrypt the `e` or `a` event referenced
-as the second item using [NIP-44](44.md). Note that **this is not
-the user private key**, but a disposable one. Similar to DMs,
-the disposable or the author private key can decrypt the
+a private key that can decrypt the `e` or `a` event (or `u` list events)
+referenced as the second item using [NIP-44](44.md).
+Note that **this is not the user private key**, but a disposable one.
+Similar to DMs, the disposable or the author private key can decrypt the
 referenced event content.
 
 ### Example
 
 `["a", "<nip_51_list_address>", "<disposable_privkey>"]`
+
+## Extra Event Field
+
+When requesting events, if the requesting user is **author** of some of them,
+and they were previously configured as **private**, these events should include an extra
+`config` attribute namespaced in the `nip102` key holding the "configuration array"
+(including the "disposable" privkey, if applicable).
+
+This is important to build client interfaces that enable configuration array editing features.
+
+Example of a returned event:
+
+```
+{
+  id: ...,
+  kind: 1,
+  // ...other event fields
+  sig: ...,
+  nip102: {
+    config: ["a", "<nip_51_list_address>"]
+  }
+}
+```

65.md

@@ -10,6 +10,8 @@ Defines a replaceable event using `kind:10002` to advertise preferred relays for
 
 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.
 
+A `nip102` sub-marker may be used to signal to clients what write relays to use for [NIP-102](102.md).
+
 The `.content` is not used.
 
 ```json
@@ -19,6 +21,7 @@ The `.content` is not used.
     ["r", "wss://alicerelay.example.com"],
     ["r", "wss://brando-relay.com"],
     ["r", "wss://expensive-relay.example2.com", "write"],
+    ["r", "wss://nip102-enabled-relay.example2.com", "write", "nip102"],
     ["r", "wss://nostr-relay.example.com", "read"],
   ],
   "content": "",
@@ -31,31 +34,31 @@ This NIP doesn't fully replace relay lists that are designed to configure a clie
 
 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 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 all READ relays of each tagged user. 
+- Broadcast the event all READ relays of each tagged user.
 
 ## 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. 
+
+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). 
+1. Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays).
 
-2. Clients SHOULD spread an author's `kind:10002` events to as many relays as viable. 
+2. Clients SHOULD spread an author's `kind:10002` events 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. 
+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.