add video and photos follows and relay lists to nip51.

Signed-off-by: Awiteb <a@4rs.nl>
Co-authored-by: hodlbod <jstaab@protonmail.com>

01.md

@@ -14,7 +14,7 @@ Each user has a keypair. Signatures, public key, and encodings are done accordin
 
 The only object type that exists is the `event`, which has the following format on the wire:
 
-```jsonc
+```yaml
 {
   "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
@@ -120,7 +120,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
 
 `<filtersX>` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes:
 
-```json
+```yaml
 {
   "ids": <a list of event ids>,
   "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,

17.md

@@ -15,17 +15,17 @@ Kind `14` is a chat message. `p` tags identify one or more receivers of the mess
 ```jsonc
 {
   "id": "<usual hash>",
-  "pubkey": "<sender-pubkey>",
+  "pubkey": "<sender-pubkey>",
   "created_at": "<current-time>",
-  "kind": 14,
+  "kind": 14,
-  "tags": [
+  "tags": [
-    ["p", "<receiver-1-pubkey>", "<relay-url>"],
+    ["p", "<receiver-1-pubkey>", "<relay-url>"],
-    ["p", "<receiver-2-pubkey>", "<relay-url>"],
+    ["p", "<receiver-2-pubkey>", "<relay-url>"],
-    ["e", "<kind-14-id>", "<relay-url>"] // if this is a reply
+    ["e", "<kind-14-id>", "<relay-url>"] // if this is a reply
     ["subject", "<conversation-title>"],
-    // rest of tags...
+    // rest of tags...
-  ],
+  ],
-  "content": "<message-in-plain-text>",
+  "content": "<message-in-plain-text>",
 }
 ```
 
@@ -65,21 +65,22 @@ Kind `14`s MUST never be signed. If it is signed, the message might leak to rela
 }
 ```
 
-Kind 15 is used for sending encrypted file event messages:
+Kind `15` is used for sending encrypted file event messages:
 
-- `file-type`: Specifies the MIME type of the attached file (e.g., `image/jpeg`, `audio/mpeg`, etc.).
+- `file-type`: Specifies the MIME type of the attached file (e.g., `image/jpeg`, `audio/mpeg`, etc.) before encryption.
-- `encryption-algorithm`: Indicates the encryption algorithm used for encrypting the file. Supported algorithms may include `aes-gcm`, `chacha20-poly1305`,`aes-cbc` etc.
+- `encryption-algorithm`: Indicates the encryption algorithm used for encrypting the file. Supported algorithms: `aes-gcm`.
 - `decryption-key`: The decryption key that will be used by the recipient to decrypt the file.
 - `decryption-nonce`: The decryption nonce that will be used by the recipient to decrypt the file.
 - `content`: The URL of the file (`<file-url>`).
-- `x` containing the SHA-256 hexencoded string of the file.
+- `x` containing the SHA-256 hexencoded string of the encrypted file.
-- `size` (optional) size of file in bytes
+- `ox` containing the SHA-256 hexencoded string of the file before encryption.
-- `dim` (optional) size of the file in pixels in the form `<width>x<height>`
+- `size` (optional) size of the encrypted file in bytes
+- `dim` (optional) size in pixels in the form `<width>x<height>`
 - `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the client is loading the file
 - `thumb` (optional) URL of thumbnail with same aspect ratio (encrypted with the same key, nonce)
-- `fallback` (optional) zero or more fallback file sources in case `url` fails
+- `fallback` (optional) zero or more fallback file sources in case `url` fails (encrypted with the same key, nonce)
 
-Just like kind 14, kind `15`s MUST never be signed.
+Just like kind `14`, kind `15`s MUST never be signed.
 
 ## Chat Rooms
 
@@ -87,34 +88,34 @@ The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or
 
 Clients SHOULD render messages of the same room in a continuous thread.
 
-An optional `subject` tag defines the current name/topic of the conversation. Any member can change the topic by simply submitting a new `subject` to an existing `pubkey` + `p`-tags room. There is no need to send `subject` in every message. The newest `subject` in the thread is the subject of the conversation.
+An optional `subject` tag defines the current name/topic of the conversation. Any member can change the topic by simply submitting a new `subject` to an existing `pubkey` + `p` tags room. There is no need to send `subject` in every message. The newest `subject` in the chat room is the subject of the conversation.
 
 ## Encrypting
 
 Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat messages must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
 
-```jsonc
+```js
 {
   "id": "<usual hash>",
-  "pubkey": randomPublicKey,
+  "pubkey": randomPublicKey,
-  "created_at": randomTimeUpTo2DaysInThePast(),
+  "created_at": randomTimeUpTo2DaysInThePast(),
   "kind": 1059, // gift wrap
-  "tags": [
+  "tags": [
-    ["p", receiverPublicKey, "<relay-url>"] // receiver
+    ["p", receiverPublicKey, "<relay-url>"] // receiver
-  ],
+  ],
-  "content": nip44Encrypt(
+  "content": nip44Encrypt(
-    {
+    {
       "id": "<usual hash>",
-      "pubkey": senderPublicKey,
+      "pubkey": senderPublicKey,
-      "created_at": randomTimeUpTo2DaysInThePast(),
+      "created_at": randomTimeUpTo2DaysInThePast(),
-      "kind": 13, // seal
+      "kind": 13, // seal
-      "tags": [], // no tags
+      "tags": [], // no tags
-      "content": nip44Encrypt(unsignedKind14, senderPrivateKey, receiverPublicKey),
+      "content": nip44Encrypt(unsignedKind14, senderPrivateKey, receiverPublicKey),
-      "sig": "<signed by senderPrivateKey>"
+      "sig": "<signed by senderPrivateKey>"
-    },
+    },
-    randomPrivateKey, receiverPublicKey
+    randomPrivateKey, receiverPublicKey
-  ),
+  ),
-  "sig": "<signed by randomPrivateKey>"
+  "sig": "<signed by randomPrivateKey>"
 }
 ```
 
@@ -124,7 +125,7 @@ Clients MUST verify if pubkey of the `kind:13` is the same pubkey on the `kind:1
 
 Clients SHOULD randomize `created_at` in up to two days in the past in both the seal and the gift wrap to make sure grouping by `created_at` doesn't reveal any metadata.
 
-The gift wrap's `p`-tag can be the receiver's main pubkey or an alias key created to receive DMs without exposing the receiver's identity.
+The gift wrap's `p` tag can be the receiver's main pubkey or an alias key created to receive DMs without exposing the receiver's identity.
 
 Clients CAN offer disappearing messages by setting an `expiration` tag in the gift wrap of each receiver or by not generating a gift wrap to the sender's public key
 

51.md

@@ -22,6 +22,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 
 | name                | kind  | description                                                 | expected tag items                                                                                  |
 | ---                 | ---   | ---                                                         | ---                                                                                                 |
+| Follow list         |     3 | microblogging basic follow list, see [NIP-02](02.md)        | `"p"` (pubkeys -- with optional relay hint and petname)                                             |
 | Mute list           | 10000 | things the user doesn't want to see in their feeds          | `"p"` (pubkeys), `"t"` (hashtags), `"word"` (lowercase string), `"e"` (threads)                     |
 | Pinned notes        | 10001 | events the user intends to showcase in their profile page   | `"e"` (kind:1 notes)                                                                                |
 | Read/write relays   | 10002 | where a user publishes to and where they expect mentions    | see [NIP-65](65.md)                                                                                 |
@@ -31,11 +32,17 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | Blocked relays      | 10006 | relays clients should never connect to                      | `"relay"` (relay URLs)                                                                              |
 | Search relays       | 10007 | relays clients should use when performing search queries    | `"relay"` (relay URLs)                                                                              |
 | Simple groups       | 10009 | [NIP-29](29.md) groups the user is in                       | `"group"` ([NIP-29](29.md) group id + relay URL + optional group name), `"r"` for each relay in use |
+| Favorite relays     | 10012 | user favorite relays and pointers to relay sets             | `"relay"` (relay URLs) and `"a"` (kind:30002 relay set)                                             |
 | Interests           | 10015 | topics a user may be interested in and pointers             | `"t"` (hashtags) and `"a"` (kind:30015 interest set)                                                |
+| Media follows       | 10020 | multimedia (photos, short video) follow list                | `"p"` (pubkeys -- with optional relay hint and petname)                                             |
 | Emojis              | 10030 | user preferred emojis and pointers to emoji sets            | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set)                                    |
 | DM relays           | 10050 | Where to receive [NIP-17](17.md) direct messages            | `"relay"` (see [NIP-17](17.md))                                                                     |
 | Good wiki authors   | 10101 | [NIP-54](54.md) user recommended wiki authors               | `"p"` (pubkeys)                                                                                     |
 | Good wiki relays    | 10102 | [NIP-54](54.md) relays deemed to only host useful articles  | `"relay"` (relay URLs)                                                                              |
+| Video subscriptions | 10111 | [NIP-71](71.md) video-exclusive follows                     | `"p"` (pubkeys)                                                                                     |
+| Good video relays   | 10112 | relays deemed to only host good [NIP-71](71.md) videos      | `"relay"` (relay URLs)                                                                              |
+| Photo subscriptions | 10111 | [NIP-68](71.md) photo-exclusive follows                     | `"p"` (pubkeys)                                                                                     |
+| Good photo relays   | 10112 | relays deemed to only host good [NIP-68](71.md) photos      | `"relay"` (relay URLs)                                                                              |
 
 ### Sets
 
@@ -57,6 +64,8 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
 | Emoji sets            | 30030 | categorized emoji groups                                                                     | `"emoji"` (see [NIP-30](30.md))                                                     |
 | Release artifact sets | 30063 | group of artifacts of a software release                                                     | `"e"` (kind:1063 [file metadata](94.md) events), `"a"` (software application event) |
 | App curation sets     | 30267 | references to multiple software applications                                                 | `"a"` (software application event)                                                  |
+| Starter packs         | 39089 | a named set of profiles to be shared around with the goal of being followed together         | `"p"` (pubkeys)                                                                     |
+| Media starter packs   | 39092 | same as above, but specific to multimedia (photos, short video) clients                      | `"p"` (pubkeys)                                                                     |
 
 ### Deprecated standard lists
 

60.md

@@ -68,7 +68,7 @@ There can be multiple `kind:7375` events for the same mint, and multiple proofs
 
  * `.content` is a [NIP-44](44.md) encrypted payload:
    * `mint`: The mint the proofs belong to.
-   * `proofs`: unecoded proofs
+   * `proofs`: unencoded proofs
    * `del`: token-ids that were destroyed by the creation of this token. This assists with state transitions.
 
 When one or more proofs of a token are spent, the token event should be [NIP-09](09.md)-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event (the change output should include a `del` field).

65.md

@@ -32,6 +32,7 @@ When publishing an event, clients SHOULD:
 
 - Send the event to the **write** relays of the author
 - Send the event to all **read** relays of each tagged user
+- Send the author's `kind:10002` event to all relays the event was published to
 
 ### Size
 

README.md

@@ -187,6 +187,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10006`       | Blocked relays list             | [51](51.md)                            |
 | `10007`       | Search relays list              | [51](51.md)                            |
 | `10009`       | User groups                     | [51](51.md), [29](29.md)               |
+| `10012`       | Favorite relays list            | [51](51.md)                            |
 | `10013`       | Private event relay list        | [37](37.md)                            |
 | `10015`       | Interests list                  | [51](51.md)                            |
 | `10019`       | Nutzap Mint Recommendation      | [61](61.md)                            |