Add LLM stuff nip: Define prompt diffs for LLM modifications

Co-authored-by: Doug Hoyte <doug@hcsw.org>

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>,
@@ -85,7 +85,7 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key
 
 ### Kinds
 
-Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. [NIP-10](10.md), for instance, especifies the `kind:1` text note for social media applications.  
+Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. [NIP-10](10.md), for instance, specifies the `kind:1` text note for social media applications.  
 
 This NIP defines one basic kind:
 
@@ -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>,
@@ -144,7 +144,7 @@ All conditions of a filter that are specified must match for an event for it to
 
 A `REQ` message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions.
 
-The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data.
+The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. Relays SHOULD use the `limit` value to guide how many events are returned in the initial response. Returning fewer events is acceptable, but returning (much) more should be avoided to prevent overwhelming clients.
 
 ### From relay to client: sending events and notices
 

11.md

@@ -21,6 +21,10 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
   "supported_nips": <a list of NIP numbers supported by the relay>,
   "software": <string identifying relay software URL>,
   "version": <string version identifier>
+  "privacy_policy": <a link to a text file describing the relay's privacy policy>,
+  "terms_of_service": <a link to a text file describing the relay's term of service>,
+
+
 }
 ```
 
@@ -74,21 +78,30 @@ The relay server implementation MAY be provided in the `software` attribute.  If
 
 The relay MAY choose to publish its software version as a string attribute.  The string format is defined by the relay implementation.  It is recommended this be a version number or commit identifier.
 
+### Privacy Policy
+
+The relay owner/admin MAY choose to link to a privacy policy document, which describes how the relay utilizes user data. Data collection, data usage, data retention, monetization of data, and third party data sharing SHOULD be included.
+
+### Terms of Service
+
+The relay owner/admin MAY choose to link to a terms of service document.
+
+
+
 Extra Fields
 ------------
 
 ### Server Limitations
 
 These are limitations imposed by the relay on clients. Your client
-should expect that requests which exceed these *practical* limitations
+should expect that requests exceed these *practical* limitations
 are rejected or fail immediately.
 
 ```jsonc
 {
   "limitation": {
     "max_message_length": 16384,
-    "max_subscriptions": 20,
-    "max_filters": 100,
+    "max_subscriptions": 300,
     "max_limit": 5000,
     "max_subid_length": 100,
     "max_event_tags": 100,
@@ -98,33 +111,30 @@ are rejected or fail immediately.
     "payment_required": true,
     "restricted_writes": true,
     "created_at_lower_limit": 31536000,
-    "created_at_upper_limit": 3
+    "created_at_upper_limit": 3,
+    "default_limit": 500
   },
   // other fields...
 }
 ```
 
-- `max_message_length`: this is the maximum number of bytes for incoming JSON that the relay
+- `max_message_length`: the maximum number of bytes for incoming JSON that the relay
 will attempt to decode and act upon. When you send large subscriptions, you will be
 limited by this value. It also effectively limits the maximum size of any event. Value is
-calculated from `[` to `]` and is after UTF-8 serialization (so some unicode characters
+calculated from `[` to `]` after UTF-8 serialization (so some unicode characters
 will cost 2-3 bytes). It is equal to the maximum size of the WebSocket message frame.
 
 - `max_subscriptions`: total number of subscriptions that may be
-active on a single websocket connection to this relay. It's possible
-that authenticated clients with a (paid) relationship to the relay
+active on a single websocket connection to this relay. Authenticated clients with a (paid) relationship to the relay
 may have higher limits.
 
-- `max_filters`: maximum number of filter values in each subscription.
-Must be one or higher.
-
 - `max_subid_length`: maximum length of subscription id as a string.
 
 - `max_limit`: the relay server will clamp each filter's `limit` value to this number.
 This means the client won't be able to get more than this number
 of events from a single subscription filter. This clamping is typically done silently
 by the relay, but with this number, you can know that there are additional results
-if you narrowed your filter's time range or other parameters.
+if you narrow your filter's time range or other parameters.
 
 - `max_event_tags`: in any event, this is the maximum number of elements in the `tags` list.
 
@@ -142,7 +152,7 @@ Even if set to False, authentication may be required for specific actions.
 
 - `payment_required`: this relay requires payment before a new connection may perform any action.
 
-- `restricted_writes`: this relay requires some kind of condition to be fulfilled in order to
+- `restricted_writes`: this relay requires some kind of condition to be fulfilled to
 accept events (not necessarily, but including `payment_required` and `min_pow_difficulty`).
 This should only be set to `true` when users are expected to know the relay policy before trying
 to write to it -- like belonging to a special pubkey-based whitelist or writing only events of
@@ -152,6 +162,8 @@ a specific niche kind or content. Normal anti-spam heuristics, for example, do n
 
 - `created_at_upper_limit`: 'created_at' upper limit
 
+- `default_limit`: The maximum returned events if you send a filter with the limit set to 0.
+
 ### Event Retention
 
 There may be a cost associated with storing data forever, so relays
@@ -212,7 +224,7 @@ flexibility is up to the client software.
 ```
 
 - `relay_countries`: a list of two-level ISO country codes (ISO 3166-1 alpha-2)  whose
-  laws and policies may affect this relay. `EU` may be used for European Union countries.
+  laws and policies may affect this relay. `EU` may be used for European Union countries. A `*` can be used for global relays.
 
 Remember that a relay may be hosted in a country which is not the
 country of the legal entities who own the relay, so it's very
@@ -237,7 +249,7 @@ To support this goal, relays MAY specify some of the following values.
 
 - `language_tags` is an ordered list
   of [IETF language tags](https://en.wikipedia.org/wiki/IETF_language_tag) indicating
-  the major languages spoken on the relay.
+  the major languages spoken on the relay. A `*` can be used for global relays.
 
 - `tags` is a list of limitations on the topics to be discussed.
   For example `sfw-only` indicates that only "Safe For Work" content
@@ -276,49 +288,82 @@ Relays that require payments may want to expose their fee schedules.
 
 ### Examples
 
-As of 2 May 2023 the following command provided these results:
+As of 25 March 2025 the following command provided these results:
 
 ```bash
-$ curl -H "Accept: application/nostr+json" https://eden.nostr.land | jq
+curl -H "Accept: application/nostr+json" https://jellyfish.land | jq
 ```
 
 ```json
 {
-  "description": "nostr.land family of relays (us-or-01)",
-  "name": "nostr.land",
-  "pubkey": "52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd",
-  "software": "custom",
+  "name": "JellyFish",
+  "description": "Stay Immortal!",
+  "banner": "https://image.nostr.build/7fdefea2dec1f1ec25b8ce69362566c13b2b7f13f1726c2e4584f05f64f62496.jpg",
+  "pubkey": "bf2bee5281149c7c350f5d12ae32f514c7864ff10805182f4178538c2c421007",
+  "contact": "hi@dezh.tech",
+  "software": "https://github.com/dezh-tech/immortal",
   "supported_nips": [
     1,
-    2,
-    4,
     9,
     11,
-    12,
-    16,
-    20,
-    22,
-    28,
-    33,
-    40
+    13,
+    17,
+    40,
+    42,
+    59,
+    62,
+    70
   ],
-  "version": "1.0.1",
-  "limitation": {
-    "payment_required": true,
-    "max_message_length": 65535,
-    "max_event_tags": 2000,
-    "max_subscriptions": 20,
-    "auth_required": false
-  },
-  "payments_url": "https://eden.nostr.land",
+  "version": "immortal - 0.0.9",
+  "relay_countries": [
+    "*"
+  ],
+  "language_tags": [
+    "*"
+  ],
+  "tags": [],
+  "posting_policy": "https://jellyfish.land/tos.txt",
+  "payments_url": "https://jellyfish.land/relay",
+  "icon": "https://image.nostr.build/2547e9ec4b23589e09bc7071e0806c3d4293f76284c58ff331a64bce978aaee8.jpg",
+  "retention": [],
   "fees": {
     "subscription": [
       {
-        "amount": 2500000,
-        "unit": "msats",
-        "period": 2592000
+        "amount": 3000,
+        "period": 2628003,
+        "unit": "sats"
+      },
+      {
+        "amount": 8000,
+        "period": 7884009,
+        "unit": "sats"
+      },
+      {
+        "amount": 15000,
+        "period": 15768018,
+        "unit": "sats"
+      },
+      {
+        "amount": 28000,
+        "period": 31536036,
+        "unit": "sats"
       }
     ]
   },
+  "limitation": {
+    "auth_required": false,
+    "max_message_length": 70000,
+    "max_subid_length": 256,
+    "max_subscriptions": 350,
+    "min_pow_difficulty": 0,
+    "payment_required": true,
+    "restricted_writes": true,
+    "max_event_tags": 2000,
+    "max_content_length": 70000,
+    "created_at_lower_limit": 0,
+    "created_at_upper_limit": 2147483647,
+    "default_limit": 500,
+    "max_limit": 5000
+  }
 }
 ```

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,
-  "tags": [
-    ["p", "<receiver-1-pubkey>", "<relay-url>"],
-    ["p", "<receiver-2-pubkey>", "<relay-url>"],
-    ["e", "<kind-14-id>", "<relay-url>"] // if this is a reply
+  "kind": 14,
+  "tags": [
+    ["p", "<receiver-1-pubkey>", "<relay-url>"],
+    ["p", "<receiver-2-pubkey>", "<relay-url>"],
+    ["e", "<kind-14-id>", "<relay-url>"] // if this is a reply
     ["subject", "<conversation-title>"],
-    // rest of tags...
-  ],
-  "content": "<message-in-plain-text>",
+    // rest of tags...
+  ],
+  "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.).
-- `encryption-algorithm`: Indicates the encryption algorithm used for encrypting the file. Supported algorithms may include `aes-gcm`, `chacha20-poly1305`,`aes-cbc` 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: `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.
-- `size` (optional) size of file in bytes
-- `dim` (optional) size of the file in pixels in the form `<width>x<height>`
+- `x` containing the SHA-256 hexencoded string of the encrypted file.
+- `ox` containing the SHA-256 hexencoded string of the file before encryption.
+- `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,
-  "created_at": randomTimeUpTo2DaysInThePast(),
+  "pubkey": randomPublicKey,
+  "created_at": randomTimeUpTo2DaysInThePast(),
   "kind": 1059, // gift wrap
-  "tags": [
-    ["p", receiverPublicKey, "<relay-url>"] // receiver
-  ],
-  "content": nip44Encrypt(
-    {
+  "tags": [
+    ["p", receiverPublicKey, "<relay-url>"] // receiver
+  ],
+  "content": nip44Encrypt(
+    {
       "id": "<usual hash>",
-      "pubkey": senderPublicKey,
-      "created_at": randomTimeUpTo2DaysInThePast(),
-      "kind": 13, // seal
-      "tags": [], // no tags
-      "content": nip44Encrypt(unsignedKind14, senderPrivateKey, receiverPublicKey),
-      "sig": "<signed by senderPrivateKey>"
-    },
-    randomPrivateKey, receiverPublicKey
-  ),
-  "sig": "<signed by randomPrivateKey>"
+      "pubkey": senderPublicKey,
+      "created_at": randomTimeUpTo2DaysInThePast(),
+      "kind": 13, // seal
+      "tags": [], // no tags
+      "content": nip44Encrypt(unsignedKind14, senderPrivateKey, receiverPublicKey),
+      "sig": "<signed by senderPrivateKey>"
+    },
+    randomPrivateKey, receiverPublicKey
+  ),
+  "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
 
@@ -188,7 +189,7 @@ The two final GiftWraps, one to the receiver and the other to the sender, respec
    "created_at":1703128320,
    "kind":1059,
    "tags":[
-      [ "p", "918e2da906df4ccd12c8ac672d8335add131a4cf9d27ce42b3bb3625755f0788"]
+      ["p", "918e2da906df4ccd12c8ac672d8335add131a4cf9d27ce42b3bb3625755f0788"]
    ],
    "content":"AsqzdlMsG304G8h08bE67dhAR1gFTzTckUUyuvndZ8LrGCvwI4pgC3d6hyAK0Wo9gtkLqSr2rT2RyHlE5wRqbCOlQ8WvJEKwqwIJwT5PO3l2RxvGCHDbd1b1o40ZgIVwwLCfOWJ86I5upXe8K5AgpxYTOM1BD+SbgI5jOMA8tgpRoitJedVSvBZsmwAxXM7o7sbOON4MXHzOqOZpALpS2zgBDXSAaYAsTdEM4qqFeik+zTk3+L6NYuftGidqVluicwSGS2viYWr5OiJ1zrj1ERhYSGLpQnPKrqDaDi7R1KrHGFGyLgkJveY/45y0rv9aVIw9IWF11u53cf2CP7akACel2WvZdl1htEwFu/v9cFXD06fNVZjfx3OssKM/uHPE9XvZttQboAvP5UoK6lv9o3d+0GM4/3zP+yO3C0NExz1ZgFmbGFz703YJzM+zpKCOXaZyzPjADXp8qBBeVc5lmJqiCL4solZpxA1865yPigPAZcc9acSUlg23J1dptFK4n3Tl5HfSHP+oZ/QS/SHWbVFCtq7ZMQSRxLgEitfglTNz9P1CnpMwmW/Y4Gm5zdkv0JrdUVrn2UO9ARdHlPsW5ARgDmzaxnJypkfoHXNfxGGXWRk0sKLbz/ipnaQP/eFJv/ibNuSfqL6E4BnN/tHJSHYEaTQ/PdrA2i9laG3vJti3kAl5Ih87ct0w/tzYfp4SRPhEF1zzue9G/16eJEMzwmhQ5Ec7jJVcVGa4RltqnuF8unUu3iSRTQ+/MNNUkK6Mk+YuaJJs6Fjw6tRHuWi57SdKKv7GGkr0zlBUU2Dyo1MwpAqzsCcCTeQSv+8qt4wLf4uhU9Br7F/L0ZY9bFgh6iLDCdB+4iABXyZwT7Ufn762195hrSHcU4Okt0Zns9EeiBOFxnmpXEslYkYBpXw70GmymQfJlFOfoEp93QKCMS2DAEVeI51dJV1e+6t3pCSsQN69Vg6jUCsm1TMxSs2VX4BRbq562+VffchvW2BB4gMjsvHVUSRl8i5/ZSDlfzSPXcSGALLHBRzy+gn0oXXJ/447VHYZJDL3Ig8+QW5oFMgnWYhuwI5QSLEyflUrfSz+Pdwn/5eyjybXKJftePBD9Q+8NQ8zulU5sqvsMeIx/bBUx0fmOXsS3vjqCXW5IjkmSUV7q54GewZqTQBlcx+90xh/LSUxXex7UwZwRnifvyCbZ+zwNTHNb12chYeNjMV7kAIr3cGQv8vlOMM8ajyaZ5KVy7HpSXQjz4PGT2/nXbL5jKt8Lx0erGXsSsazkdoYDG3U",
    "sig":"a3c6ce632b145c0869423c1afaff4a6d764a9b64dedaf15f170b944ead67227518a72e455567ca1c2a0d187832cecbde7ed478395ec4c95dd3e71749ed66c480"
@@ -202,7 +203,7 @@ The two final GiftWraps, one to the receiver and the other to the sender, respec
    "created_at":1702711587,
    "kind":1059,
    "tags":[
-      [ "p", "44900586091b284416a0c001f677f9c49f7639a55c3f1e2ec130a8e1a7998e1b"]
+      ["p", "44900586091b284416a0c001f677f9c49f7639a55c3f1e2ec130a8e1a7998e1b"]
    ],
    "content":"AsTClTzr0gzXXji7uye5UB6LYrx3HDjWGdkNaBS6BAX9CpHa+Vvtt5oI2xJrmWLen+Fo2NBOFazvl285Gb3HSM82gVycrzx1HUAaQDUG6HI7XBEGqBhQMUNwNMiN2dnilBMFC3Yc8ehCJT/gkbiNKOpwd2rFibMFRMDKai2mq2lBtPJF18oszKOjA+XlOJV8JRbmcAanTbEK5nA/GnG3eGUiUzhiYBoHomj3vztYYxc0QYHOx0WxiHY8dsC6jPsXC7f6k4P+Hv5ZiyTfzvjkSJOckel1lZuE5SfeZ0nduqTlxREGeBJ8amOykgEIKdH2VZBZB+qtOMc7ez9dz4wffGwBDA7912NFS2dPBr6txHNxBUkDZKFbuD5wijvonZDvfWq43tZspO4NutSokZB99uEiRH8NAUdGTiNb25m9JcDhVfdmABqTg5fIwwTwlem5aXIy8b66lmqqz2LBzJtnJDu36bDwkILph3kmvaKPD8qJXmPQ4yGpxIbYSTCohgt2/I0TKJNmqNvSN+IVoUuC7ZOfUV9lOV8Ri0AMfSr2YsdZ9ofV5o82ClZWlWiSWZwy6ypa7CuT1PEGHzywB4CZ5ucpO60Z7hnBQxHLiAQIO/QhiBp1rmrdQZFN6PUEjFDloykoeHe345Yqy9Ke95HIKUCS9yJurD+nZjjgOxZjoFCsB1hQAwINTIS3FbYOibZnQwv8PXvcSOqVZxC9U0+WuagK7IwxzhGZY3vLRrX01oujiRrevB4xbW7Oxi/Agp7CQGlJXCgmRE8Rhm+Vj2s+wc/4VLNZRHDcwtfejogjrjdi8p6nfUyqoQRRPARzRGUnnCbh+LqhigT6gQf3sVilnydMRScEc0/YYNLWnaw9nbyBa7wFBAiGbJwO40k39wj+xT6HTSbSUgFZzopxroO3f/o4+ubx2+IL3fkev22mEN38+dFmYF3zE+hpE7jVxrJpC3EP9PLoFgFPKCuctMnjXmeHoiGs756N5r1Mm1ffZu4H19MSuALJlxQR7VXE/LzxRXDuaB2u9days/6muP6gbGX1ASxbJd/ou8+viHmSC/ioHzNjItVCPaJjDyc6bv+gs1NPCt0qZ69G+JmgHW/PsMMeL4n5bh74g0fJSHqiI9ewEmOG/8bedSREv2XXtKV39STxPweceIOh0k23s3N6+wvuSUAJE7u1LkDo14cobtZ/MCw/QhimYPd1u5HnEJvRhPxz0nVPz0QqL/YQeOkAYk7uzgeb2yPzJ6DBtnTnGDkglekhVzQBFRJdk740LEj6swkJ",
    "sig":"c94e74533b482aa8eeeb54ae72a5303e0b21f62909ca43c8ef06b0357412d6f8a92f96e1a205102753777fd25321a58fba3fb384eee114bd53ce6c06a1c22bab"

19.md

@@ -34,7 +34,7 @@ These are the possible bech32 prefixes with `TLV`:
 
   - `nprofile`: a nostr profile
   - `nevent`: a nostr event
-  - `naddr`: a nostr _replaceable event_ coordinate
+  - `naddr`: a nostr _addressable event_ coordinate
   - `nrelay`: a nostr relay (deprecated)
 
 These possible standardized `TLV` types are indicated here:

21.md

@@ -12,9 +12,27 @@ The scheme is `nostr:`.
 
 The identifiers that come after are expected to be the same as those defined in [NIP-19](19.md) (except `nsec`).
 
-## Examples
+#### Examples
 
 - `nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9`
 - `nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpp4mhxue69uhhytnc9e3k7mgpz4mhxue69uhkg6nzv9ejuumpv34kytnrdaksjlyr9p`
 - `nostr:note1fntxtkcy9pjwucqwa9mddn7v03wwwsu9j330jj350nvhpky2tuaspk6nqc`
 - `nostr:nevent1qqstna2yrezu5wghjvswqqculvvwxsrcvu7uc0f78gan4xqhvz49d9spr3mhxue69uhkummnw3ez6un9d3shjtn4de6x2argwghx6egpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5nxnepm`
+
+### Linking HTML pages to Nostr entities
+
+`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023' events served under itself as a relay or through some other relay). For example:
+
+```
+<head>
+  <link rel="alternate" href="nostr:naddr1qqyrzwrxvc6ngvfkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cph95ag" />
+</head>
+```
+
+Likewise, `<link>` tags with `rel="me"` or `rel="author"` can be used to assign authorship of webpages to Nostr profiles. For example:
+
+```
+<head>
+  <link rel="me" href="nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqyd8wumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6qpq80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwswpnfsn" />
+</head>
+```

22.md

@@ -18,9 +18,9 @@ and `p` for the author of the parent item.
 
 ```jsonc
 {
-  kind: 1111,
-  content: '<comment>',
-  tags: [
+  "kind": 1111,
+  "content": "<comment>",
+  "tags": [
     // root scope: event addresses, event ids, or I-tags.
     ["<A, E, I>", "<address, id or I-value>", "<relay or web page hint>", "<root event's pubkey, if an E tag>"],
     // the root item kind
@@ -64,9 +64,9 @@ A comment on a blog post looks like this:
 
 ```jsonc
 {
-  kind: 1111,
-  content: 'Great blog post!',
-  tags: [
+  "kind": 1111,
+  "content": "Great blog post!",
+  "tags": [
     // top-level comments scope to event addresses or ids
     ["A", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
     // the root kind
@@ -91,9 +91,9 @@ A comment on a [NIP-94](94.md) file looks like this:
 
 ```jsonc
 {
-  kind: 1111,
-  content: 'Great file!',
-  tags: [
+  "kind": 1111,
+  "content": "Great file!",
+  "tags": [
     // top-level comments have the same scope and reply to addresses or ids
     ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
     // the root kind
@@ -115,9 +115,9 @@ A reply to a comment looks like this:
 
 ```jsonc
 {
-  kind: 1111,
-  content: 'This is a reply to "Great file!"',
-  tags: [
+  "kind": 1111,
+  "content": "This is a reply to \"Great file!\"",
+  "tags": [
     // nip-94 file event id
     ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
     // the root kind
@@ -138,9 +138,9 @@ A comment on a website's url looks like this:
 
 ```jsonc
 {
-  kind: 1111,
-  content: 'Nice article!',
-  tags: [
+  "kind": 1111,
+  "content": "Nice article!",
+  "tags": [
     // referencing the root url
     ["I", "https://abc.com/articles/1"],
     // the root "kind": for an url, the kind is its domain
@@ -159,11 +159,11 @@ A podcast comment example:
 
 ```jsonc
 {
-  id: "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
-  pubkey: "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
-  kind: 1111,
-  content: "This was a great episode!",
-  tags: [
+  "id": "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
+  "pubkey": "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
+  "kind": 1111,
+  "content": "This was a great episode!",
+  "tags": [
     // podcast episode reference
     ["I", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
     // podcast episode type
@@ -181,9 +181,9 @@ A reply to a podcast comment:
 
 ```jsonc
 {
-  kind: 1111,
-  content: "I'm replying to the above comment.",
-  tags: [
+  "kind": 1111,
+  "content": "I'm replying to the above comment.",
+  "tags": [
     // podcast episode reference
     ["I", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
     // podcast episode type

25.md

@@ -7,38 +7,38 @@ Reactions
 
 `draft` `optional`
 
-A reaction is a `kind 7` event that is used to react to other events.
+A reaction is a `kind 7` event that is used to indicate user reactions to other events. A
+reaction's `content` field MUST include user-generated-content indicating the value of the
+reaction (conventionally `+`, `-`, or an emoji).
 
-The generic reaction, represented by the `content` set to a `+` string, SHOULD
-be interpreted as a "like" or "upvote".
+A reaction with `content` set to `+` or an empty string MUST be interpreted as a "like" or "upvote".
+A reaction with `content` set to `-` MUST be interpreted as a "dislike" or "downvote".
 
-A reaction with `content` set to `-` SHOULD be interpreted as a "dislike" or
-"downvote". It SHOULD NOT be counted as a "like", and MAY be displayed as a
-downvote or dislike on a post. A client MAY also choose to tally likes against
-dislikes in a reddit-like system of upvotes and downvotes, or display them as
-separate tallies.
-
-The `content` MAY be an emoji, or [NIP-30](30.md) custom emoji in this case it MAY be interpreted as a "like" or "dislike",
-or the client MAY display this emoji reaction on the post. If the `content` is an empty string then the client should
-consider it a "+".
+A reaction with `content` set to an emoji or [NIP-30](30.md) custom emoji SHOULD NOT be interpreted
+as a "like" or "dislike". Clients MAY instead display this emoji reaction on the post.
 
 Tags
 ----
 
 There MUST be always an `e` tag set to the `id` of the event that is being reacted to. The `e` tag SHOULD include a relay hint pointing to a relay where the event being reacted to can be found. If a client decides to include other `e`, which not recommended, the target event `id` should be last of the `e` tags.
 
-The SHOULD be a `p` tag set to the `pubkey` of the event being reacted to. If a client decides to include other `p` tags, which not recommended, the target event `pubkey` should be last the `p` tags.
+There SHOULD be a `p` tag set to the `pubkey` of the event being reacted to. If a client decides to include other `p` tags, which not recommended, the target event `pubkey` should be last the `p` tags.
 
 If the event being reacted to is an addressable event, an `a` SHOULD be included together with the `e` tag, it must be set to the coordinates (`kind:pubkey:d-tag`) of the event being reacted to.
 
 The reaction SHOULD include a `k` tag with the stringified kind number of the reacted event as its value.
 
+The `e` and `a` tags SHOULD include relay and pubkey hints. The `p` tags SHOULD include relay hints.
+
+The reaction event MAY include a `k` tag with the stringified kind number of the reacted event as its value.
+
 **Example code**
 
 ```swift
-func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> NostrEvent {
-    tags.append(["e", liked.id, liked.source_relays.first ?? ""])
-    tags.append(["p", liked.pubkey])
+func make_like_event(pubkey: String, privkey: String, liked: NostrEvent, hint: String) -> NostrEvent {
+    var tags: [[String]] = []
+    tags.append(["e", liked.id, hint, liked.pubkey])
+    tags.append(["p", liked.pubkey, hint])
     tags.append(["k", String(liked.kind)])
     let ev = NostrEvent(content: "+", pubkey: pubkey, kind: 7, tags: tags)
     ev.calculate_id()

26.md

@@ -1,3 +1,5 @@
+> __Warning__  `unrecommended`: adds unecessary burden for little gain
+
 NIP-26
 =======
 

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,7 +32,9 @@ 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)                                                                                     |
@@ -57,6 +60,9 @@ 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)                                                  |
+| Calendar              | 31924 | a set of events categorized in any way                                                       | `"a"` (calendar event 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
 
@@ -98,9 +104,9 @@ Some clients have used these lists in the past, but they should work on transiti
   "kind": 30004,
   "tags": [
     ["d", "jvdy9i4"],
-    ["name", "Yaks"],
-    ["picture", "https://cdn.britannica.com/40/188540-050-9AC748DE/Yak-Himalayas-Nepal.jpg"],
-    ["about", "The domestic yak, also known as the Tartary ox, grunting ox, or hairy cattle, is a species of long-haired domesticated cattle found throughout the Himalayan region of the Indian subcontinent, the Tibetan Plateau, Gilgit-Baltistan, Tajikistan and as far north as Mongolia and Siberia."],
+    ["title", "Yaks"],
+    ["image", "https://cdn.britannica.com/40/188540-050-9AC748DE/Yak-Himalayas-Nepal.jpg"],
+    ["description", "The domestic yak, also known as the Tartary ox, grunting ox, or hairy cattle, is a species of long-haired domesticated cattle found throughout the Himalayan region of the Indian subcontinent, the Tibetan Plateau, Gilgit-Baltistan, Tajikistan and as far north as Mongolia and Siberia."],
     ["a", "30023:26dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:95ODQzw3ajNoZ8SyMDOzQ"],
     ["a", "30023:54af95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:1-MYP8dAhramH9J5gJWKx"],
     ["a", "30023:f8fe95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:D2Tbd38bGrFvU0bIbvSMt"],

52.md

@@ -12,23 +12,14 @@ Unlike the term `calendar event` specific to this NIP, the term `event` is used
 
 ## Calendar Events
 
-There are two types of calendar events represented by different kinds: date-based and time-based calendar events. Calendar events are not required to be part of a [calendar](#calendar).
+There are two types of calendar events represented by different kinds: _date-based_ and _time-based_ calendar events.
 
-### Date-Based Calendar Event
+These tags are common to both types of calendar events:
 
-This kind of calendar event starts on a date and ends before a different date in the future. Its use is appropriate for all-day or multi-day events where time and time zone hold no significance. e.g., anniversary, public holidays, vacation days.
-
-#### Format
-
-The format uses an _addressable event_ of `kind:31922`.
-
-The `.content` of these events should be a detailed description of the calendar event. It is required but can be an empty string.
-
-The list of tags are as follows:
-* `d` (required) universally unique identifier (UUID). Generated by the client creating the calendar event.
+* `d` (required) a short unique string identifier. Generated by the client creating the calendar event.
 * `title` (required) title of the calendar event
-* `start` (required) inclusive start date in ISO 8601 format (YYYY-MM-DD). Must be less than `end`, if it exists.
-* `end` (optional) exclusive end date in ISO 8601 format (YYYY-MM-DD). If omitted, the calendar event ends on the same date as `start`.
+* `summary` (optional) brief description of the calendar event
+* `image` (optional) url of an image to use for the event
 * `location` (optional, repeated) location of the calendar event. e.g. address, GPS coordinates, meeting room name, link to video call
 * `g` (optional) [geohash](https://en.wikipedia.org/wiki/Geohash) to associate calendar event with a searchable physical location
 * `p` (optional, repeated) 32-bytes hex pubkey of a participant, optional recommended relay URL, and participant's role in the meeting
@@ -36,39 +27,49 @@ The list of tags are as follows:
 * `r` (optional, repeated) references / links to web pages, documents, video calls, recorded videos, etc.
 
 The following tags are deprecated:
+
 * `name` name of the calendar event. Use only if `title` is not available.
 
-```jsonc
+Calendar events are _not_ required to be part of a [calendar](#calendar).
+
+### Date-Based Calendar Event
+
+This kind of calendar event starts on a date and ends before a different date in the future. Its use is appropriate for all-day or multi-day events where time and time zone hold no significance. e.g., anniversary, public holidays, vacation days.
+
+It's an _addressable event_ of `kind:31922`.
+
+The `.content` of these events SHOULD be a description of the calendar event.
+
+Aside from the common tags, this also takes the following tags:
+
+* `start` (required) inclusive start date in ISO 8601 format (YYYY-MM-DD). Must be less than `end`, if it exists.
+* `end` (optional) exclusive end date in ISO 8601 format (YYYY-MM-DD). If omitted, the calendar event ends on the same date as `start`.
+
+Example:
+
+```yaml
 {
   "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
-  "created_at": <Unix timestamp in seconds>,
+  "created_at": <unix timestamp in seconds>,
   "kind": 31922,
   "content": "<description of calendar event>",
   "tags": [
-    ["d", "<UUID>"],
+    ["d", "<random-identifier>"],
 
     ["title", "<title of calendar event>"],
 
-    // Dates
+    // dates
     ["start", "<YYYY-MM-DD>"],
     ["end", "<YYYY-MM-DD>"],
 
-    // Location
+    // location
     ["location", "<location>"],
     ["g", "<geohash>"],
 
-    // Participants
+    // participants
     ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
     ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
-
-    // Hashtags
-    ["t", "<tag>"],
-    ["t", "<tag>"],
-
-    // Reference links
-    ["r", "<url>"],
-    ["r", "<url>"]
   ]
 }
 ```
@@ -77,97 +78,68 @@ The following tags are deprecated:
 
 This kind of calendar event spans between a start time and end time.
 
-#### Format
+It's an _addressable event_ of `kind:31923`.
 
-The format uses an _addressable event_ kind `31923`.
+The `.content` of these events should be a description of the calendar event. It is required but can be an empty string.
 
-The `.content` of these events should be a detailed description of the calendar event. It is required but can be an empty string.
+Aside from the common tags, this also takes the following tags:
 
-The list of tags are as follows:
-* `d` (required) universally unique identifier (UUID). Generated by the client creating the calendar event.
-* `title` (required) title of the calendar event
 * `start` (required) inclusive start Unix timestamp in seconds. Must be less than `end`, if it exists.
 * `end` (optional) exclusive end Unix timestamp in seconds. If omitted, the calendar event ends instantaneously.
 * `start_tzid` (optional) time zone of the start timestamp, as defined by the IANA Time Zone Database. e.g., `America/Costa_Rica`
 * `end_tzid` (optional) time zone of the end timestamp, as defined by the IANA Time Zone Database. e.g., `America/Costa_Rica`. If omitted and `start_tzid` is provided, the time zone of the end timestamp is the same as the start timestamp.
-* `summary` (optional) brief description of the calendar event
-* `image` (optional) url of an image to use for the event
-* `location` (optional, repeated) location of the calendar event. e.g. address, GPS coordinates, meeting room name, link to video call
-* `g` (optional) [geohash](https://en.wikipedia.org/wiki/Geohash) to associate calendar event with a searchable physical location
-* `p` (optional, repeated) 32-bytes hex pubkey of a participant, optional recommended relay URL, and participant's role in the meeting
-* `l` (optional, repeated) label to categorize calendar event. e.g. `audiospace` to denote a scheduled event from a live audio space implementation such as cornychat.com
-* `t` (optional, repeated) hashtag to categorize calendar event
-* `r` (optional, repeated) references / links to web pages, documents, video calls, recorded videos, etc.
 
-The following tags are deprecated:
-* `name` name of the calendar event. Use only if `title` is not available.
-
-```jsonc
+```yaml
 {
   "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
-  "created_at": <Unix timestamp in seconds>,
+  "created_at": <unix timestamp in seconds>,
   "kind": 31923,
   "content": "<description of calendar event>",
   "tags": [
-    ["d", "<UUID>"],
+    ["d", "<random-identifier>"],
 
     ["title", "<title of calendar event>"],
     ["summary", "<brief description of the calendar event>"],
     ["image", "<string with image URI>"],
 
-    // Timestamps
-    ["start", "<Unix timestamp in seconds>"],
-    ["end", "<Unix timestamp in seconds>"],
+    // timestamps
+    ["start", "<unix timestamp in seconds>"],
+    ["end", "<unix timestamp in seconds>"],
 
     ["start_tzid", "<IANA Time Zone Database identifier>"],
     ["end_tzid", "<IANA Time Zone Database identifier>"],
 
-    // Location
+    // location
     ["location", "<location>"],
     ["g", "<geohash>"],
 
-    // Participants
+    // participants
     ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
     ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
-
-    // Labels (example using com.cornychat namespace denoting the event as an audiospace)
-    ["L", "com.cornychat"],
-    ["l", "audiospace", "com.cornychat"],
-
-    // Hashtags
-    ["t", "<tag>"],
-    ["t", "<tag>"],
-
-    // Reference links
-    ["r", "<url>"],
-    ["r", "<url>"]
   ]
 }
 ```
 
 ## Calendar
 
-A calendar is a collection of calendar events, represented as a custom replaceable list event using kind `31924`. A user can have multiple calendars. One may create a calendar to segment calendar events for specific purposes. e.g., personal, work, travel, meetups, and conferences.
-
-### Format
+A calendar is a collection of calendar events, represented as a custom _addressable list_ event using kind `31924`. A user can have multiple calendars. One may create a calendar to segment calendar events for specific purposes. e.g., personal, work, travel, meetups, and conferences.
 
 The `.content` of these events should be a detailed description of the calendar. It is required but can be an empty string.
 
-The format uses a custom replaceable list of kind `31924` with a list of tags as described below:
 * `d` (required) universally unique identifier. Generated by the client creating the calendar.
 * `title` (required) calendar title
 * `a` (repeated) reference tag to kind `31922` or `31923` calendar event being responded to
 
-```json
+```yaml
 {
   "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
-  "created_at": <Unix timestamp in seconds>,
+  "created_at": <unix timestamp in seconds>,
   "kind": 31924,
   "content": "<description of calendar>",
   "tags": [
-    ["d", "<UUID>"],
+    ["d", "<random-identifier>"],
     ["title", "<calendar title>"],
     ["a", "<31922 or 31923>:<calendar event author pubkey>:<d-identifier of calendar event>", "<optional relay url>"],
     ["a", "<31922 or 31923>:<calendar event author pubkey>:<d-identifier of calendar event>", "<optional relay url>"]
@@ -191,13 +163,12 @@ The RSVP MUST have an `a` tag of the event coordinates to the calendar event, an
 
 The RSVP MAY tag the author of the calendar event it is in response to using a `p` tag so that clients can easily query all RSVPs that pertain to the author.
 
-### Format
-
-The format uses an _addressable event_ kind `31925`.
+The RSVP is an _addressable event_ of `kind:31925`.
 
 The `.content` of these events is optional and should be a free-form note that adds more context to this calendar event response.
 
-The list of tags are as follows:
+The list of tags is as follows:
+
 * `a` (required) coordinates to a kind `31922` or `31923` calendar event being responded to.
 * `e` (optional) event id of a kind `31922` or `31923` calendar event being responded to.
 * `d` (required) universally unique identifier. Generated by the client creating the calendar event RSVP.
@@ -205,17 +176,17 @@ The list of tags are as follows:
 * `fb` (optional) `free` or `busy`. Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`.
 * `p` (optional) pubkey of the author of the calendar event being responded to.
 
-```json
+```yaml
 {
   "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
-  "created_at": <Unix timestamp in seconds>,
+  "created_at": <unix timestamp in seconds>,
   "kind": 31925,
   "content": "<note>",
   "tags": [
     ["e", "<kind 31922 or 31923 event id", "<optional recommended relay URL>"]
     ["a", "<31922 or 31923>:<calendar event author pubkey>:<d-identifier of calendar event>", "<optional recommended relay URL>"],
-    ["d", "<UUID>"],
+    ["d", "<random-identifier>"],
     ["status", "<accepted/declined/tentative>"],
     ["fb", "<free/busy>"],
     ["p", "<hex pubkey of kind 31922 or 31923 event>", "<optional recommended relay URL>"]

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).

61.md

@@ -46,10 +46,10 @@ Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu
 
 ```jsonc
 {
-    kind: 9321,
-    content: "Thanks for this great idea.",
-    pubkey: "<sender-pubkey>",
-    tags: [
+    "kind": 9321,
+    "content": "Thanks for this great idea.",
+    "pubkey": "<sender-pubkey>",
+    "tags": [
         [ "proof", "{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}" ],
         [ "u", "https://stablenut.umint.cash" ],
         [ "e", "<nutzapped-event-id>", "<relay-hint>" ],

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,20 @@ 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 downloading events **from** a user, clients SHOULD use the **write** relays of that user.
 
-## When to Use Read and Write Relays
+When downloading events **about** a user, where the user was tagged (mentioned), clients SHOULD use the user's **read** relays.
 
-When seeking events **from** a user, Clients SHOULD use the WRITE relays of the user's `kind:10002`.
+When publishing an event, clients SHOULD:
 
-When seeking events **about** a user, where the user was tagged, Clients SHOULD use the READ relays of the user's `kind:10002`.
+- 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
 
-When broadcasting an event, Clients SHOULD:
+### Size
 
-- Broadcast the event to the WRITE relays of the author
-- Broadcast the event to all READ relays of each tagged user
+Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays of each category).
 
-## Motivation
+### Discoverability
 
-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). 
-
-2. Clients SHOULD spread an author's `kind:10002` event 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. 
-
-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.
-
-6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
-
-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.
-
-## 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).

66.md

@@ -1,4 +1,8 @@
-# NIP-66: Relay Discovery and Liveness Monitoring
+NIP-66
+======
+
+Relay Discovery and Liveness Monitoring
+-------------------
 
 `draft` `optional`
 

69.md

@@ -1,6 +1,8 @@
-# NIP-69
+NIP-69
+======
 
-## Peer-to-peer Order events
+Peer-to-peer Order events
+-------------------------
 
 `draft` `optional`
 

77.md

@@ -0,0 +1,175 @@
+NIP-77
+======
+
+Negentropy Syncing
+------------------
+
+`draft` `optional`
+
+This document describes a protocol extension for syncing events. It works for both client-relay and relay-relay scenarios. If both sides of the sync have events in common, then this protocol will use less bandwidth than transferring the full set of events (or even just their IDs).
+
+It is a Nostr-friendly wrapper around the [Negentropy](https://github.com/hoytech/negentropy) protocol, which uses a technique called [Range-Based Set Reconciliation](https://logperiodic.com/rbsr.html).
+
+Since Negentropy is a binary protocol, this wrapper hex-encodes its messages. The specification for Negentropy Protocol V1 is attached as an appendix to this NIP below.
+
+## High-Level Protocol Description
+
+We're going to call the two sides engaged in the sync the client and the relay (even though the initiator could be another relay instead of a client).
+
+* (1) Client (initiator) chooses a filter, and retrieves the set of events that it has locally that match this filter (or uses a cache), and constructs an initial message.
+* (2) Client sends a `NEG-OPEN` message to the relay, which includes the filter and the initial message.
+* (3) Relay selects the set of events that it has locally that match the filter (or uses a cache).
+* (4) Relay constructs a response and returns it to the client in a `NEG-MSG` message.
+* (5) Client parses the message to learn about IDs it has (and relay needs) and IDs it needs (and relay has).
+  * If client wishes to continue, then it constructs a new message and sends it to the relay in a `NEG-MSG` message. Goto step 4.
+  * If client wishes to stop, then it sends a `NEG-CLOSE` message or disconnects the websocket.
+
+The above protocol only results in the client learning about IDs it has/needs, and does not actually transfer events. Given these IDs, the client can upload events it has with `EVENT`, and/or download events it needs with `REQ`. This can be performed over the same websocket connection in parallel with subsequent `NEG-MSG` messages. If a client is only interested in determining the number of unique events (ie, reaction counts), it may choose to not download/upload at all.
+
+## Nostr Messages
+
+### Initial message (client to relay):
+
+```jsonc
+[
+    "NEG-OPEN",
+    <subscription ID string>,
+    <filter>,
+    <initialMessage, hex-encoded>
+]
+```
+
+* The subscription ID is used by each side to identify which query a message refers to. It only needs to be long enough to distinguish it from any other concurrent subscriptions on this websocket connection (an integer that increments once per `NEG-OPEN` is fine). Subscription IDs are in a separate namespace from `REQ` subscription IDs. If a `NEG-OPEN` is issued for a currently open subscription ID, the existing subscription is first closed.
+* The filter is as described in [NIP-01](01.md).
+* `initialMessage` is the initial Negentropy binary message, hex-encoded. See appendix.
+
+### Error message (relay to client):
+
+If a request cannot be serviced by the relay, an error is returned to the client:
+
+```jsonc
+[
+    "NEG-ERR",
+    <subscription ID string>,
+    <reason code string>
+]
+```
+
+Error reasons are the same format as in NIP-01. They should begin with a machine-readable single-word prefix, followed by a `:` and then a human-readable message with more information.
+
+The current suggested error reasons are
+
+* `blocked`
+  * Relays can optionally reject queries that would require them to process too many records, or records that are too old
+  * The maximum number of records that can be processed can optionally be returned as the 4th element in the response
+  * Example: `blocked: this query is too big`
+* `closed`
+  * Because the `NEG-OPEN` queries may be stateful, relays may choose to time-out inactive queries to recover memory resources
+  * Example: `closed: you took too long to respond!`
+
+After a `NEG-ERR` is issued, the subscription is considered to be closed.
+
+### Subsequent messages (bidirectional):
+
+Relay and client alternate sending each other `NEG-MSG`s:
+
+```jsonc
+[
+    "NEG-MSG",
+    <subscription ID string>,
+    <message, hex-encoded>
+]
+```
+
+* `message` is a Negentropy binary message, hex-encoded. Both message directions use the same format. See appendix.
+
+### Close message (client to relay):
+
+When finished, the client should tell the relay it can release its resources with a `NEG-CLOSE`:
+
+```jsonc
+[
+    "NEG-CLOSE",
+    <subscription ID string>
+]
+```
+
+
+## Appendix: Negentropy Protocol V1
+
+### Preparation
+
+There are two protocol participants: Client and server. The client creates an initial message and transmits it to the server, which replies with its own message in response. The client continues querying the server until it is satisifed, and then terminates the protocol. Messages in either direction have the same format.
+
+Each participant has a collection of records. A records consists of a 64-bit numeric timestamp and a 256-bit ID. Each participant starts by sorting their items according to timestamp, ascending. If two timestamps are equal then items are sorted lexically by ID, ascending by first differing byte. Items may not use the max uint64 value (`2**64 - 1`) as a timestamp since this is reserved as a special "infinity" value.
+
+The goal of the protocol is for the client to learn the set of IDs that it has and the server does not, and the set of items that the server has and it does not.
+
+### `Varint`
+
+Varints (variable-sized unsigned integers) are represented as base-128 digits, most significant digit first, with as few digits as possible. Bit eight (the high bit) is set on each byte except the last.
+
+    Varint := <Digit+128>* <Digit>
+
+### `Id`
+
+IDs are represented as byte-strings of length `32`:
+
+    Id := Byte{32}
+
+### `Message`
+
+A reconciliation message is a protocol version byte followed by an ordered list of ranges:
+
+    Message := <protocolVersion (Byte)> <Range>*
+
+The current protocol version is 1, represented by the byte `0x61`. Protocol version 2 will be `0x62`, and so forth. If a server receives a message with a protocol version that it cannot handle, it should reply with a single byte containing the highest protocol version it supports, allowing the client to downgrade and retry its message.
+
+Each Range corresponds to a contiguous section of the timestamp/ID space. The first Range starts at timestamp 0 and an ID of 0 bytes. Ranges are always adjacent (no gaps). If the last Range doesn't end at the special infinity value, an implicit `Skip` to infinity Range is appended. This means that the list of Ranges always covers the full timestamp/ID space.
+
+### `Range`
+
+A Range consists of an upper bound, a mode, and a payload:
+
+    Range := <upperBound (Bound)> <mode (Varint)> <payload (Skip | Fingerprint | IdList)>
+
+The contents of the payload is determined by mode:
+
+* If `mode = 0`, then payload is `Skip`, meaning the sender does not wish to process this Range further. This payload is empty:
+
+      Skip :=
+
+* If `mode = 1`, then payload is a `Fingerprint`, which is a [digest](#fingerprint-algorithm) of all the IDs the sender has within the Range:
+
+      Fingerprint := Byte{16}
+
+* If `mode = 2`, the payload is `IdList`, a variable-length list of all IDs the sender has within the Range:
+
+      IdList := <length (Varint)> <ids (Id)>*
+
+
+### `Bound`
+
+Each Range is specified by an *inclusive* lower bound and an *exclusive* upper bound. As defined above, each Range only includes an upper bound: the lower bound of a Range is the upper bound of the previous Range, or 0 timestamp/0 ID for the first Range.
+
+A Bound consists of an encoded timestamp and a variable-length disambiguating prefix of an ID (in case multiple items have the same timestamp):
+
+    Bound := <encodedTimestamp (Varint)> <length (Varint)> <idPrefix (Byte)>*
+
+* The timestamp is encoded specially. The infinity timestamp is encoded as `0`. All other values are encoded as `1 + offset`, where offset is the difference between this timestamp and the previously encoded timestamp. The initial offset starts at `0` and resets at the beginning of each message.
+
+  Offsets are always non-negative since the upper bound's timestamp is greater than or equal to the lower bound's timestamp, ranges in a message are always encoded in ascending order, and ranges never overlap.
+
+* The size of `idPrefix` is encoded in `length`, and can be between `0` and `32` bytes, inclusive. This allows implementations to use the shortest possible prefix to separate the first record of this Range from the last record of the previous Range. If these records' timestamps differ, then the length should be 0, otherwise it should be the byte-length of their common ID-prefix plus 1.
+
+  If the `idPrefix` length is less than `32` then the omitted trailing bytes are implicitly 0 bytes.
+
+
+### Fingerprint Algorithm
+
+The fingerprint of a Range is computed with the following algorithm:
+
+* Compute the addition mod 2<sup>256</sup> of the element IDs (interpreted as 32-byte little-endian unsigned integers)
+* Concatenate with the number of elements in the Range, encoded as a [Varint](#varint)
+* Hash with SHA-256
+* Take the first 16 bytes

7D.md

@@ -6,15 +6,14 @@ Threads
 
 `draft` `optional`
 
-A thread is a `kind 11` event.  Threads SHOULD include a `subject` with a summary
-of the thread's topic.
+A thread is a `kind 11` event.  Threads SHOULD include a `title`.
 
 ```json
 {
   "kind": 11,
   "content": "Good morning",
   "tags": [
-    ["subject", "GM"]
+    ["title", "GM"]
   ]
 }
 ```

84.md

@@ -23,7 +23,7 @@ or obvious non-useful information from the query string.
 ### Attribution
 Clients MAY include one or more `p` tags, tagging the original authors of the material being highlighted; this is particularly
 useful when highlighting non-nostr content for which the client might be able to get a nostr pubkey somehow
-(e.g. prompting the user or reading a `<meta name="nostr:nprofile1..." />` tag on the document). A role MAY be included as the
+(e.g. prompting the user or reading a `<link rel="me" href="nostr:nprofile1..." />` tag on the document). A role MAY be included as the
 last value of the tag.
 
 ```jsonc
@@ -40,3 +40,12 @@ last value of the tag.
 ### Context
 Clients MAY include a `context` tag, useful when the highlight is a subset of a paragraph and displaying the
 surrounding content might be beneficial to give context to the highlight.
+
+## Quote Highlights
+A `comment` tag may be added to create a quote highlight. This MUST be rendered like a quote repost with the highlight as the quoted note.
+
+This is to prevent the creation and multiple notes (highlight + kind 1) for a single highlight action, which looks bad in micro-blogging clients where these notes may appear in succession.
+
+p-tag mentions MUST have a `mention` attribute to distinguish it from authors and editors.
+
+r-tag urls from the comment MUST have a `mention` attribute to distinguish from the highlighted source url. The source url MUST have the `source` attribute.

88.md

@@ -1,6 +1,8 @@
-# NIP-88
+NIP-88
+======
 
-## Polls
+Polls
+-----
 
 `draft` `optional`
 

B0.md

@@ -0,0 +1,61 @@
+NIP-B0
+======
+
+Web Bookmarking
+---------------
+
+`draft` `optional`
+
+This NIP defines `kind:39701` (an _addressable event_) for a URI as a web bookmark which uses the HTTP (Hypertext transfer protocol) scheme.
+These web bookmark events are _addressable_ and deletable per [NIP-09](09.md).
+
+### Editability
+
+Web bookmarks are meant to be editable, so they should include a `d` tag with an identifier for the bookmark. Clients should take care to only publish and read these events from relays that implement that. If they don't do that they should also take care to hide old versions of the same bookmark they may receive.
+
+### Format
+
+The format uses an _addressable event_ of `kind:39701`.
+
+The `.content` of these events should be a detailed description of the web bookmark. It is required but can be an empty string.
+
+The `d` tag is required.
+
+In this way web bookmarks events can be queried by the `d` tag by clients, which is just their URL without the scheme, which is always and everywhere assumed to be `https://` or `http://`.
+
+The querystring and the hash must be removed entirely, unless their requirement is explicitly stated either by the user or by some hardcoded list of URLs that rely on querystrings for basic routing provided by the client.
+
+### Metadata
+
+For the date of the last update the `.created_at` field should be used. For "tags"/"hashtags" (i.e. topics about which the event might be of relevance) the `t` tag should be used.
+
+Other metadata fields can be added as tags to the event as necessary.
+
+* `"published_at"`, for the timestamp in unix seconds (stringified) of the first time the bookmark was published
+* `"title"`, title about bookmark and can be used as a attribute for the HTML link element
+
+## Example event 
+
+```jsonc
+{
+  "kind": 39701,
+  "id": "d7a92714f81d0f712e715556aee69ea6da6bfb287e6baf794a095d301d603ec7",
+  "pubkey": "2729620da105979b22acfdfe9585274a78c282869b493abfa4120d3af2061298",
+  "created_at": 1738869705,
+  "tags": [
+    // Required tags
+    ["d", "alice.blog/post"],
+    // Optional tags    
+    ["published_at", "1738863000"],
+    ["title", "Blog insights by Alice"],  
+    ["t", "post"],
+    ["t", "insight"]
+  ],
+  "content": "A marvelous insight by Alice about the nature of blogs and posts.",
+  "sig": "36d34e6448fe0223e9999361c39c492a208bc423d2fcdfc2a3404e04df7c22dc65bbbd62dbe8a4373c62e4d29aac285b5aa4bb9b4b8053bd6207a8b45fbd0c98"
+}
+```
+
+### Replies & Comments
+
+Replies to `kind 39701` MUST use `kind 1111` events as comments with [NIP-22](22.md).

B7.md

@@ -0,0 +1,41 @@
+NIP-B7
+======
+
+Blossom media
+-------------
+
+`draft` `optional`
+
+This NIP specifies how Nostr clients can use [Blossom][] for handling media.
+
+Blossom is a set of standards (called BUDs) for dealing with servers that store files addressable by their SHA-256 sums. Nostr clients may make use of all the BUDs for allowing users to upload files, manage their own files and so on, but most importantly Nostr clients SHOULD make use of [BUD-03][] to fetch `kind:10063` lists of servers for each user:
+
+```json
+{
+  "id": "e4bee088334cb5d38cff1616e964369c37b6081be997962ab289d6c671975d71",
+  "pubkey": "781208004e09102d7da3b7345e64fd193cd1bc3fce8fdae6008d77f9cabcd036",
+  "content": "",
+  "kind": 10063,
+  "created_at": 1708774162,
+  "tags": [
+    ["server", "https://blossom.self.hosted"],
+    ["server", "https://cdn.blossom.cloud"]
+  ],
+  "sig": "cc5efa74f59e80622c77cacf4dd62076bcb7581b45e9acff471e7963a1f4d8b3406adab5ee1ac9673487480e57d20e523428e60ffcc7e7a904ac882cfccfc653"
+}
+```
+
+Whenever a Nostr client finds a URL in an event published by a given user and that URL ends a 64-character hex string (with or without an ending file extension) and that URL is not available anymore, that means that string is likely a representation of a sha256 and that the user may have a `kind:10063` list of Blossom servers published.
+
+Given that, the client SHOULD look into the `kind:10063` list for other Blossom servers and lookup for the same 64-character hex string in them, by just using the hex string as a path (optionally with the file extension at the end), producing a URL like `https://blossom.self.hosted/<hex-string>.png`.
+
+When downloading such files Nostr clients SHOULD verify that the sha256-hash of its contents matches the 64-character hex string.
+
+More information can be found at [BUD-03][].
+
+### More complex interactions
+
+Clients may use other facilities exposed by Blossom servers (for example, for checking if a file exists in a Blossom server, instead of actually downloading it) which are better documented in the [BUDs][Blossom].
+
+[Blossom]: https://github.com/hzrd149/blossom
+[BUD-03]: https://github.com/hzrd149/blossom/blob/master/buds/03.md

C0.md

@@ -1,4 +1,8 @@
-# NIP-C0: Code Snippets
+NIP-C0
+======
+
+Code Snippets
+-------------
 
 `draft` `optional`
 

README.md

@@ -44,7 +44,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-23: Long-form Content](23.md)
 - [NIP-24: Extra metadata fields and tags](24.md)
 - [NIP-25: Reactions](25.md)
-- [NIP-26: Delegated Event Signing](26.md)
+- [NIP-26: Delegated Event Signing](26.md) --- **unrecommended**: adds unecessary burden for little gain
 - [NIP-27: Text Note References](27.md)
 - [NIP-28: Public Chat](28.md)
 - [NIP-29: Relay-based Groups](29.md)
@@ -88,7 +88,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-72: Moderated Communities](72.md)
 - [NIP-73: External Content IDs](73.md)
 - [NIP-75: Zap Goals](75.md)
+- [NIP-77: Negentropy Syncing](77.md)
 - [NIP-78: Application-specific data](78.md)
+- [NIP-7D: Threads](7D.md)
 - [NIP-84: Highlights](84.md)
 - [NIP-86: Relay Management API](86.md)
 - [NIP-88: Polls](88.md)
@@ -99,7 +101,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-96: HTTP File Storage Integration](96.md)
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
-- [NIP-7D: Threads](7D.md)
+- [NIP-B0: Web Bookmarks](B0.md)
+- [NIP-B7: Blossom](B7.md)
 - [NIP-C0: Code Snippets](C0.md)
 - [NIP-C7: Chats](C7.md)
 
@@ -185,9 +188,11 @@ 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)                            |
+| `10020`       | Media follows                   | [51](51.md)                            |
 | `10030`       | User emoji list                 | [51](51.md)                            |
 | `10050`       | Relay list to receive DMs       | [51](51.md), [17](17.md)               |
 | `10063`       | User server list                | [Blossom][blossom]                     |
@@ -247,6 +252,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `34550`       | Community Definition            | [72](72.md)                            |
 | `38383`       | Peer-to-peer Order events       | [69](69.md)                            |
 | `39000-9`     | Group metadata events           | [29](29.md)                            |
+| `39089`       | Starter packs                   | [51](51.md)                            |
+| `39092`       | Media starter packs             | [51](51.md)                            |
+| `39701`       | Web bookmarks                   | [B0](B0.md)                            |
 
 [NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/
 [nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
@@ -341,7 +349,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `preimage`        | hash of `bolt11` invoice             | --                              | [57](57.md)                                        |
 | `price`           | price                                | currency, frequency             | [99](99.md)                                        |
 | `proxy`           | external ID                          | protocol                        | [48](48.md)                                        |
-| `published_at`    | unix timestamp (string)              | --                              | [23](23.md)                                        |
+| `published_at`    | unix timestamp (string)              | --                              | [23](23.md), [B0](B0.md)                           |
 | `relay`           | relay url                            | --                              | [42](42.md), [17](17.md)                           |
 | `relays`          | relay list                           | --                              | [57](57.md)                                        |
 | `repo`            | Reference to the origin repository   | --                              | [C0](C0.md)                                        |
@@ -350,7 +358,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `subject`         | subject                              | --                              | [14](14.md), [17](17.md), [34](34.md)              |
 | `summary`         | summary                              | --                              | [23](23.md), [52](52.md)                           |
 | `thumb`           | badge thumbnail                      | dimensions in pixels            | [58](58.md)                                        |
-| `title`           | article title                        | --                              | [23](23.md)                                        |
+| `title`           | title                                | --                              | [23](23.md), [B0](B0.md)                           |
 | `tracker`         | torrent tracker URL                  | --                              | [35](35.md)                                        |
 | `web`             | webpage URL                          | --                              | [34](34.md)                                        |
 | `zap`             | pubkey (hex), relay URL              | weight                          | [57](57.md)                                        |

xx.md

@@ -0,0 +1,72 @@
+NIP-XX
+======
+
+LLM Stuff
+---------
+
+`draft` `optional`
+
+This NIP defines kinds related to LLM stuff.
+
+# Prompt diffs
+ a way to publish LLM prompts that describe modifications to software projects. Where code diffs usually expire in a couple of releases and require constant upkeep,tThese "prompt diffs" enable way longer-lasting, shareable software modifications.
+
+## Abstract
+
+A prompt diff is a Nostr event that contains instructions for an LLM to modify a codebase. Prompt diffs describe the intent and let LLMs handle the implementation details.
+
+## Event Structure
+
+```json
+{
+   "kind": 496,
+   "content": "<human-readable-description>",
+   "tags": [
+       ["title", "<modification-title>"],
+       ["description", "<prompt>"],
+       ["r", "<git-repository-url>"],
+       ["t", "<tag>"],
+       ["model", "<suggested-llm-model>"],
+   ]
+}
+Required Tags
+
+title - Short title describing the modification
+r - Git repository URL this applies to
+prompt - The actual prompt containing modification instructions
+
+## Optional Tags
+
+t - Hashtags for categorization (#security, #performance, #feature-removal, etc.)
+model - Suggested LLM model that successfully applies this modification
+
+Example: Remove Edit Functionality from Amethyst
+json{
+    "kind": 496,
+    "pubkey": "...",
+    "created_at": 1234567890,
+    "content": "Removes the ability to edit kind:1 text notes in Amethyst",
+    "tags": [
+        ["title", "Remove Kind:1 Edit Functionality"],
+        ["description", "Remove all edit functionality for kind:1 events from the Amethyst Android app. This includes:\n\n1. Find and remove the edit button/icon from the note options menu (three dots menu) for kind:1 events\n2. Remove any edit action handlers, click listeners, or menu item cases related to editing kind:1 notes\n3. Remove or disable any UI components like EditPostView or EditPostDialog that are used for editing existing posts\n4. Keep the edit functionality for other event kinds if they exist (like kind:30023 long-form content)\n5. Remove any edit-related permissions checks or business logic specific to kind:1 events\n6. Clean up any unused imports or resources that were only used for kind:1 editing\n7. Do not remove the ability to create new kind:1 posts, only the ability to edit existing ones\n8. Look for edit functionality in:\n   - Note composition screens\n   - Note option menus  \n   - ViewModels handling note actions\n   - Any files with names containing 'Edit' and 'Note' or 'Post'\n\nMake sure the app still compiles and runs after these changes. The diff should be clean with no leftover dead code."],
+        ["r", "https://github.com/vitorpamplona/amethyst"],
+        ["t", "noedits"],
+        ["t", "amethyst"],
+        ["model", "claude-3.5-sonnet"],
+    ],
+    "sig": "..."
+}
+
+# Implementation Guidelines
+### For Prompt Authors
+
+Write clear, specific prompts that describe intent rather than implementation
+Include context about why changes should be made in certain locations
+Specify what should NOT be changed to prevent over-modification
+Add test commands to verify the modification works
+Test prompts against the current main branch of the repository
+
+# Security Considerations
+
+* Always review LLM-generated changes before applying
+* Prompt Injection Protection: Clients MUST sanitize repository file contents before passing to LLMs to prevent malicious code comments or documentation from hijacking the modification intent