remove mentions to uuids.

add follow packs to README.
add follow packs to nip51 (#1898 )
2025-12-08 16:18:50 +00:00 · 2025-05-12 20:34:07 -03:00 · 2025-05-09 20:07:23 +09:00 · 2025-05-08 22:51:09 -03:00 · 2025-05-08 22:50:12 -03:00 · 2025-05-05 21:11:52 -03:00
29 changed files with 850 additions and 232 deletions
--- a/01.md
+++ b/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>,
@@ -78,8 +78,8 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
 - The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>, <32-bytes lowercase hex of the author's pubkey, optional>]`
 - The `p` tag, used to refer to another user: `["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]`
 - The `a` tag, used to refer to an addressable or replaceable event
-    - for an addressable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
-    - for a normal replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
+    - for an addressable event: `["a", "<kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>", <recommended relay URL, optional>]`
+    - for a normal replaceable event: `["a", "<kind integer>:<32-bytes lowercase hex of a pubkey>:", <recommended relay URL, optional>]` (note: include the trailing colon)

 As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter. Only the first value in any given tag is indexed.

@@ -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>,
--- a/11.md
+++ b/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
+  }
 }
 ```
--- a/17.md
+++ b/17.md
@@ -15,23 +15,29 @@ 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>", "reply"] // 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>",
 }
 ```

 `.content` MUST be plain text. Fields `id` and `created_at` are required.

-Tags that mention, quote and assemble threading structures MUST follow [NIP-10](10.md).
+An `e` tag denotes the direct parent message this post is replying to. 
+
+`q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
+
+```json
+["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
+```

 Kind `14`s MUST never be signed. If it is signed, the message might leak to relays and become **fully public**.

@@ -51,7 +57,7 @@ Kind `14`s MUST never be signed. If it is signed, the message might leak to rela
    ["file-type", "<file-mime-type>"],
    ["encryption-algorithm", "<encryption-algorithm>"],
    ["decryption-key", "<decryption-key>"],
-    ["decryptiion-nonce", "<decryption-nonce>"],
+    ["decryption-nonce", "<decryption-nonce>"],
    ["x", "<the SHA-256 hexencoded string of the file>"],
    // rest of tags...
  ],
@@ -59,56 +65,57 @@ 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 file in pixels in the form `<width>x<height>`
- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the file is being loaded by the client
- `thumb` (optional) url of thumbnail with same aspect ratio
- `fallback` (optional) zero or more fallback file sources in case `url` fails
+- `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 (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

-The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with clean message history.
+The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with a clean message history.

 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 message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
+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>"
 }
 ```

@@ -118,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

@@ -167,7 +174,7 @@ The main limitation of this approach is having to send a separate encrypted even

 Clients implementing this NIP should by default only connect to the set of relays found in their `kind:10050` list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast.

-When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there, but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set.
+When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set.

 ## Examples

@@ -182,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"
@@ -196,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"
--- a/22.md
+++ b/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
--- a/23.md
+++ b/23.md
@@ -60,3 +60,7 @@ References to other Nostr notes, articles or profiles must be made according to
  "id": "..."
 }
 ```
+
+### Replies & Comments
+
+Replies to `kind 30023` MUST use [NIP-22](./22.md) `kind 1111` comments. 
--- a/24.md
+++ b/24.md
@@ -17,6 +17,7 @@ These are extra fields not specified in NIP-01 that may be present in the string
  - `website`: a web URL related in any way to the event author.
  - `banner`: an URL to a wide (~1024x768) picture to be optionally displayed in the background of a profile screen.
  - `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
+  - `birthday`: an object representing the author's birth date. The format is { "year": number, "month": number, "day": number }. Each field MAY be omitted.

 ### Deprecated fields

--- a/25.md
+++ b/25.md
@@ -25,26 +25,21 @@ consider it a "+".
 Tags
 ----

-The reaction event SHOULD include `e` and `p` tags from the note the user is reacting to (and optionally `a` tags if the target is a replaceable event). This allows users to be notified of reactions to posts they were mentioned in. Including the `e` tags enables clients to pull all the reactions associated with individual posts or all the posts in a thread. `a` tags enables clients to seek reactions for all versions of a replaceable event.
+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 last `e` tag MUST be the `id` of the note that is being reacted to.
+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.

-The last `p` tag MUST be the `pubkey` of the event being reacted to.
+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 `a` tag MUST contain the coordinates (`kind:pubkey:d-tag`) of the replaceable being reacted to.
+The reaction SHOULD include a `k` tag with the stringified kind number of the reacted event as its value.

-The reaction event MAY include a `k` tag with the stringified kind number of the reacted event as its value.
-
-Example code
+**Example code**

 ```swift
 func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> NostrEvent {
-    var tags: [[String]] = liked.tags.filter {
-    	tag in tag.count >= 2 && (tag[0] == "e" || tag[0] == "p")
-    }
-    tags.append(["e", liked.id])
+    tags.append(["e", liked.id, liked.source_relays.first ?? ""])
    tags.append(["p", liked.pubkey])
-    tags.append(["k", liked.kind])
+    tags.append(["k", String(liked.kind)])
    let ev = NostrEvent(content: "+", pubkey: pubkey, kind: 7, tags: tags)
    ev.calculate_id()
    ev.sign(privkey: privkey)
--- a/26.md
+++ b/26.md
@@ -1,3 +1,5 @@
+> __Warning__  `unrecommended`: adds unecessary burden for little gain
+
 NIP-26
 =======

--- a/27.md
+++ b/27.md
@@ -10,7 +10,7 @@ This document standardizes the treatment given by clients of inline references o

 When creating an event, clients should include mentions to other profiles and to other events in the middle of the `.content` using [NIP-21](21.md) codes, such as `nostr:nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg`.

-Including [NIP-10](10.md)-style tags (`["e", <hex-id>, <relay-url>, <marker>]`) for each reference is optional, clients should do it whenever they want the profile being mentioned to be notified of the mention, or when they want the referenced event to recognize their mention as a reply.
+Including [NIP-18](18.md)'s quote tags (`["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]`) for each reference is optional, clients should do it whenever they want the profile being mentioned to be notified of the mention, or when they want the referenced event to recognize their mention as a reply.

 A reader client that receives an event with such `nostr:...` mentions in its `.content` can do any desired context augmentation (for example, linking to the profile or showing a preview of the mentioned event contents) it wants in the process. If turning such mentions into links, they could become internal links, [NIP-21](21.md) links or direct links to web clients that will handle these references.

--- a/34.md
+++ b/34.md
@@ -22,9 +22,10 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a
    ["description", "brief human-readable project description>"],
    ["web", "<url for browsing>", ...], // a webpage url, if the git server being used provides such a thing
    ["clone", "<url for git-cloning>", ...], // a url to be given to `git clone` so anyone can clone it
-    ["relays", "<relay-url>", ...] // relays that this repository will monitor for patches and issues
-    ["r", "<earliest-unique-commit-id>", "euc"]
-    ["maintainers", "<other-recognized-maintainer>", ...]
+    ["relays", "<relay-url>", ...], // relays that this repository will monitor for patches and issues
+    ["r", "<earliest-unique-commit-id>", "euc"],
+    ["maintainers", "<other-recognized-maintainer>", ...],
+    ["t", "<arbitrary string>"], // hashtags labelling the repository
  ]
 }
 ```
@@ -124,24 +125,7 @@ Issues may have a `subject` tag, which clients can utilize to display a header.

 ## Replies

-Replies are also Markdown text. The difference is that they MUST be issued as replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event. The threading of replies and patches should follow NIP-10 rules.
-
-```jsonc
-{
-  "kind": 1622,
-  "content": "<markdown text>",
-  "tags": [
-    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
-    ["e", "<issue-or-patch-id-hex>", "", "root"],
-
-    // other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
-    ["p", "<patch-author-pubkey-hex>", "", "mention"],
-    ["e", "<previous-reply-id-hex>", "", "reply"],
-    // rest of tags...
-  ],
-  // other fields...
-}
-```
+Replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event should follow [NIP-22 comment](22.md).

 ## Status

--- a/51.md
+++ b/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,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

--- a/52.md
+++ b/52.md
@@ -25,7 +25,7 @@ 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`.
@@ -46,7 +46,7 @@ The following tags are deprecated:
  "kind": 31922,
  "content": "<description of calendar event>",
  "tags": [
-    ["d", "<UUID>"],
+    ["d", "<random-identifier>"],

    ["title", "<title of calendar event>"],

@@ -84,7 +84,7 @@ The format uses an _addressable event_ kind `31923`.
 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 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.
@@ -110,7 +110,7 @@ The following tags are deprecated:
  "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>"],
@@ -167,7 +167,7 @@ The format uses a custom replaceable list of kind `31924` with a list of tags as
  "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>"]
@@ -215,7 +215,7 @@ The list of tags are as follows:
  "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>"]
--- a/53.md
+++ b/53.md
@@ -63,7 +63,7 @@ This feature is important to avoid malicious event owners adding large account h

 ### Live Chat Message

-Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity with a `root` marker. Other Kind-1 tags such as `reply` and `mention` can also be used.
+Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity. An `e` tag denotes the direct parent message this post is replying to. 

 ```jsonc
 {
@@ -76,6 +76,12 @@ Event `kind:1311` is live chat's channel message. Clients MUST include the `a` t
 }
 ```

+`q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
+
+```json
+["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
+```
+
 Hosts may choose to pin one or more live chat messages by updating the `pinned` tags in the live event kind `30311`.

 ## Use Cases
--- a/55.md
+++ b/55.md
@@ -484,6 +484,8 @@ If the user chose to always reject the event, signer application will return the

 # Usage for Web Applications

+You should consider using [NIP-46: Nostr Connect](46.md) for a better experience for web applications. When using this approach, the web app can't call the signer in the background, so the user will see a popup for every event you try to sign.
+
 Since web applications can't receive a result from the intent, you should add a modal to paste the signature or the event json or create a callback url.

 If you send the callback url parameter, Signer Application will send the result to the url.
--- a/60.md
+++ b/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).
--- a/61.md
+++ b/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>" ],
--- a/62.md
+++ b/62.md
@@ -0,0 +1,61 @@
+NIP-62
+======
+
+Request to Vanish
+-----------------
+
+`draft` `optional`
+
+This NIP offers a Nostr-native way to request a complete reset of a key's fingerprint on the web. This procedure is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database. 
+
+## Request to Vanish from Relay
+
+Kind `62` requests a specific relay to delete everything, including [NIP-09](09.md) Deletion Events, from the `.pubkey` until its `.created_at`. 
+
+```jsonc
+{
+  "kind": 62,
+  "pubkey": <32-byte hex-encoded public key of the event creator>,
+  "tags": [
+    ["relay", "<relay url>"]
+  ],
+  "content": "<reason or note>",
+  //...other fields
+}
+```
+
+The tag list MUST include at least one `relay` value. 
+
+Content MAY include a reason or a legal notice to the relay operator. 
+
+Relays MUST fully delete any events from the `.pubkey` if their service URL is tagged in the event. 
+
+Relays SHOULD delete all [NIP-59](59.md) Gift Wraps that p-tagged the `.pubkey` if their service URL is tagged in the event, deleting all DMs to the pubkey.
+
+Relays MUST ensure the deleted events cannot be re-broadcasted into the relay. 
+
+Relays MAY store the signed request to vanish for bookkeeping.
+
+Paid relays or relays that restrict who can post MUST also follow the request to vanish regardless of the user's status. 
+
+Publishing a deletion request event (Kind `5`) against a request to vanish has no effect. Clients and relays are not obliged to support "unrequest vanish" functionality.
+
+Clients SHOULD send this event to the target relays only. 
+
+## Global Request to Vanish
+
+To request ALL relays to delete everything, the event MUST include a `relay` tag with the value `ALL_RELAYS` in uppercase. 
+
+```jsonc
+{
+  "kind": 62,
+  "pubkey": <32-byte hex-encoded public key of the event creator>,
+  "tags": [
+    ["relay", "ALL_RELAYS"]
+  ],
+  "content": "<reason>",
+  //...other fields
+}
+```
+
+Clients SHOULD broadcast this event to as many relays as possible. 
--- a/65.md
+++ b/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,43 +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).
-
-## 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).
--- a/66.md
+++ b/66.md
@@ -0,0 +1,254 @@
+NIP-66
+======
+
+Relay Discovery and Liveness Monitoring
+-------------------
+
+`draft` `optional`
+
+You want to find relays. You may want to discover relays based on criteria that's up to date. You may even want to ensure that you have a complete dataset. You probably want to filter relays based on their reported liveness.
+
+In its purest form:
+
+```json
+{
+  "kind": 30166,
+  "created_at": 1722173222,  
+  "content": "{}",
+  "tags": [
+    [ "d", "wss://somerelay.abc/" ]
+  ],
+  "pubkey": "<pubkey>", 
+  "sig": "<signature>",
+  "id": "<eventid>"
+}
+```
+
+This event signals that the relay at `wss://somerelay.abc/` was reported "online" by `<pubkey>` at timestamp `1722173222`. This event **MAY** be extended upon to include more information.
+
+## Kinds
+`NIP-66` defines two (2) event kinds, `30166` and `10166`
+
+| kind  | name                       | description                                                                             |
+|-------|----------------------------|-----------------------------------------------------------------------------------------|
+| [30166](#k30166) | Relay Discovery      | An addressable event that is published by a monitor when a relay is online |
+| [10166](#k10166) | Relay Monitor Announcement | An RE that stores data that signals the intent of a pubkey to monitor relays and publish `30166` events at a regular _frequency_ |
+
+## Ontology
+- `Relay Operator`: someone who operates a relay 
+- `Monitor`: A pubkey that monitors relays and publishes `30166` events at the frequency specified in their `10166` event.
+- `Ad-hoc Monitor`: A pubkey that monitors relays and publishes `30166` events at an irregular frequency.
+- `Monitor Service`: A group or individual that monitors relays using one or more `Monitors`.
+- `Check`: a specific data point that is tested or aggregated by a monitor.
+
+## `30166`: "Relay Discovery" <a id="k30166"></a>
+
+### Summary
+`30166` is a `NIP-33` addressable event, referred to as a "Relay Discovery" event. These events are optimized with a small footprint for protocol-level relay Discovery.
+
+### Purpose 
+Discovery of relays over nostr. 
+
+### Schema 
+
+#### Content 
+`30166` content fields **SHOULD** include the stringified JSON of the relay's NIP-11 informational document. This data **MAY** be provided for informational purposes only. 
+
+#### `created_at`
+The `created_at` field in a NIP-66 event should reflect the time when the relay liveness (and potentially other data points) was checked.
+
+#### `tags`
+
+##### Meta Tags (unindexed)
+- `rtt-open` The relay's open **round-trip time** in milliseconds.
+- `rtt-read` The relay's read **round-trip time** in milliseconds.
+- `rtt-write` The relay's write **round-trip time** in milliseconds.
+
+_Other `rtt` values **MAY** be present. This NIP should be updated if there is value found in more `rtt` values._
+
+##### Single Letter Tags (indexed)
+- `d` The relay URL/URI. The `#d` tag **must** be included in the `event.tags[]` array. Index position `1` **must** be the relay websocket URL/URI. If a URL it **SHOULD** be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6). For relays not accessible via conventional means but rather by an npub/pubkey, an npub/pubkey **MAY** be used in place of a URL.
+  ```json
+  [ "d", "wss://somerelay.abc/"]
+  ```
+
+- `n`: Network
+  ```json
+  [ "n", "clearnet" ]
+  ```
+
+- `T`: Relay Type. Enumerated [relay type](https://github.com/nostr-protocol/nips/issues/1282) formatted as `PascalCase`
+  ```json
+  ["T", "PrivateInbox" ]
+  ```
+
+- `N`: Supported Nips _From NIP-11 "Informational Document" `nip11.supported_nips[]`_
+  ```json
+  [ "N", "42" ]
+  ```
+
+- `R`: Requirements _NIP-11 "Informational Document" `nip11.limitations.payment_required`, `nip11.limitations.auth_required` and/or any other boolean value within `nip11.limitations[]` that is added in the future_
+  ```json
+  [ "R", "payment" ],
+  [ "R", "auth" ],
+  ```
+  Since the nostr protocol does not currently support filtering on whether an indexed tag **is** or **is not** set, to make "public" and "no auth" relays discoverable requires a `!` flag
+
+  ```json
+  [ "R", "!payment" ], //no payment required, is public
+  [ "R", "!auth" ], //no authentication required
+  ```
+
+- `t`: "Topics" _From NIP-11 "Informational Document" `nip11.tags[]`_
+  ```json
+  [ "t", "nsfw" ]
+  ```
+
+- `k`: Accepted/Blocked Kinds [`NIP-22`]
+  ```json
+  [ "k", "0" ],
+  [ "k", "3" ],
+  [ "k", "10002" ]
+  ```
+
+  or for blocked kinds
+
+  ```json
+  [ "k", "!0" ]
+  [ "k", "!3" ],
+  [ "k", "!10002" ]
+  ```
+
+- `g`: `NIP-52` `g` tags (geohash)
+  ```json
+  [ "g", "9r1652whz" ]
+  ```
+
+- `30166` **MAY** be extended with global tags defined by other NIPs that do no collide with locally defined indices, including but not limited to: `p`, `t`, `e`, `a`, `i` and `l/L`. 
+
+#### Robust Example of a `30166` Event
+_Relay was online, and you can filter on a number of different tags_
+```json
+{
+  "id": "<eventid>",
+  "pubkey": "<monitor's pubkey>",
+  "created_at": "<created_at  [some recent date ...]>",
+  "signature": "<signature>",
+  "content": "{}",
+  "kind": 30166,
+  "tags": [  
+    ["d","wss://some.relay/"],
+    ["n", "clearnet"],
+    ["N", "40"],
+    ["N", "33"],
+    ["R", "!payment"],
+    ["R", "auth"],
+    ["g", "ww8p1r4t8"],
+    ["p", "somehexkey..."],
+    ["l", "en", "ISO-639-1"],
+    ["t", "nsfw" ],
+    ["rtt-open", 234 ]
+  ]
+} 
+```
+
+## `10166`: "Relay Monitor Announcement" Events <a id="k10166"></a>
+
+### Summary 
+`10166` is a replacable event herein referred to as "Relay Monitor Announcement" events. These events contain information about a publisher's intent to monitor and publish data as `30166` events. This event is optional and is intended for monitors who intend to provide monitoring services at a regular and predictable frequency.
+
+### Purpose 
+To provide a directory of monitors, their intent to publish, their criteria and parameters of monitoring activities. Absence of this event implies the monitor is ad-hoc and does not publish events at a predictable frequency, and relies on mechanisms to infer data integrity, such as web-of-trust.
+
+### Schema
+
+#### Standard Tags
+
+- `frequency` The frequency **in seconds** at which the monitor publishes events. A string-integer at index `1` represents the expected frequency the monitor will publish `30166` events. There should only be `1` frequency per monitor. 
+
+  ```json
+  [ "frequency", "3600" ]
+  ```
+
+- `timeout` (optional) The timeout values for various checks conducted by a monitor. Index `1` is the monitor's timeout in milliseconds. Index `2` describes what test the timeout is used for. If no index `2` is provided, it is inferred that the timeout provided applies to all tests. These values can assist relay operators in understanding data signaled by the monitor in _Relay Discovery Events_. 
+  ```json
+  [ "timeout", "2000", "open" ],
+  [ "timeout", "2000", "read" ],
+  [ "timeout", "3000", "write" ],
+  [ "timeout", "2000", "nip11" ],
+  [ "timeout", "4000", "ssl" ]
+  ```
+
+#### Indexed Tags
+- `c`  "Checks" **SHOULD** be a lowercase string describing the check(s) conducted by a monitor. Due to the rapidly evolving nature of relays, enumeration is organic and not strictly defined. But examples of some checks could be websocket `open/read/write/auth`, `nip11` checks, `dns` and `geo` checks, and and any other checks the monitor may deem useful.. Other checks **MAY** be included. New types of checks **SHOULD** be added to this NIP as they are needed.
+  ```json
+  [ "c", "ws" ],
+  [ "c", "nip11" ],
+  [ "c", "dns" ],
+  [ "c", "geo" ],
+  [ "c", "ssl" ],
+  ```
+
+- `g`: `NIP-52` `g` tags (geohash)
+  ```json
+  [ "g", "9r1652whz" ]
+  ```
+
+- Any other globally defined indexable tags **MAY** be included as found necessary.
+
+### Other Requirements
+Monitors **SHOULD** have the following 
+- A published `0` (NIP-1) event
+- A published `10002` (NIP-65) event that defines the relays the monitor publishes to.
+
+### Robust Example of a `10166` Event
+```json
+{
+  "id": "<eventid>",
+  "pubkey": "<monitor's pubkey>",
+  "created_at": "<created_at  [some recent date ...]>",
+  "signature": "<signature>",
+  "content": "",
+  "tags": [  
+
+    [ "timeout", "open", "5000"  ],
+    [ "timeout", "read", "3000"  ],
+    [ "timeout", "write", "3000" ],
+    [ "timeout", "nip11", "3000" ],
+
+    [ "frequency", "3600" ],
+
+    [ "c", "ws" ],
+    [ "c", "nip11" ],
+    [ "c", "ssl" ],
+    [ "c", "dns" ],
+    [ "c", "geo" ]
+
+    [ "g", "ww8p1r4t8" ]
+  ]
+} 
+```
+
+## Methodology 
+
+### Monitors
+1. A _Relay Monitor_ checks the liveness and potentially other attributes of a relay. 
+
+2. _Relay Monitor_ publishes a kind `30166` note when a relay it is monitoring is online. If the monitor has a `10166` event, events should be published at the frequency defined in their `10166` note. 
+
+_Any pubkey that publishes `30166` events **SHOULD** at a minimum be checking that the relay is available by websocket and behaves like a relay_
+
+### Clients
+1. In most cases, a client **SHOULD** filter on `30166` events using either a statically or dynamically defined monitor's `pubkey` and a `created_at` value respective of the monitor's published `frequency`. If the monitor has no stated frequency, other mechanisms should be employed to determine data integrity.
+
+2. _Relay Liveness_ is subjectively determined by the client, starting with the `frequency` value of a monitor. 
+
+3. The liveness of a _Relay Monitor_ can be subjectively determined by detecting whether the _Relay Monitor_ has published events with respect to `frequency` value of any particular monitor.
+
+4. The reliability and trustworthiness of a _Relay Monitor_ could be established via web-of-trust, reviews or similar mechanisms. 
+
+## Risk Mitigation
+
+- When a client implements `NIP-66` events, the client should have a fallback if `NIP-66` events cannot be located.
+
+- A `Monitor` or `Ad-hoc Monitor` may publish erroneous `30166` events, intentionally or otherwise. Therefor, it's important to program defensively to limit the impact of such events. This can be achieved with web-of-trust, reviews, fallbacks and/or data-aggregation for example.
--- a/69.md
+++ b/69.md
@@ -1,6 +1,8 @@
-# NIP-69
+NIP-69
+======

-## Peer-to-peer Order events
+Peer-to-peer Order events
+-------------------------

 `draft` `optional`

--- a/73.md
+++ b/73.md
@@ -9,26 +9,40 @@ External Content IDs
 There are certain established global content identifiers such as [Book ISBNs](https://en.wikipedia.org/wiki/ISBN), [Podcast GUIDs](https://podcastnamespace.org/tag/guid), and [Movie ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number) that are useful to reference in nostr events so that clients can query all the events assosiated with these ids.


-`i` tags are used for referencing these external content ids, with `k` tags representing the external content id kind so that clients can query all the events for a specific kind. 
+`i` tags are used for referencing these external content ids, with `k` tags representing the external content id kind so that clients can query all the events for a specific kind.

 ## Supported IDs

-| Type | `i` tag | `k` tag |
-|- | - | - |
-| URLs | "`<URL, normalized, no fragment>`" | "`<scheme-host, normalized>`" |
-| Hashtags | "#`<topic, lowercase>`" | "#" |
-| Geohashes| "geo:`<geohash, lowercase>`" | "geo" |
-| Books | "isbn:`<id, without hyphens>`" | "isbn" |
-| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
-| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
-| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
-| Movies | "isan:`<id, without version part>`" | "isan" |
-| Papers | "doi:`<id, lowercase>`" | "doi" |
+| Type                   | `i` tag                                                    | `k` tag                  |
+| ---                    | ---                                                        | ---                      |
+| URLs                   | "`<URL, normalized, no fragment>`"                         | "web"                    |
+| Books                  | "isbn:`<id, without hyphens>`"                             | "isbn"                   |
+| Geohashes              | "geo:`<geohash, lowercase>`"                               | "geo"                    |
+| Movies                 | "isan:`<id, without version part>`"                        | "isan"                   |
+| Papers                 | "doi:`<id, lowercase>`"                                    | "doi"                    |
+| Hashtags               | "#`<topic, lowercase>`"                                    | "#"                      |
+| Podcast Feeds          | "podcast:guid:`<guid>`"                                    | "podcast:guid"           |
+| Podcast Episodes       | "podcast:item:guid:`<guid>`"                               | "podcast:item:guid"      |
+| Podcast Publishers     | "podcast:publisher:guid:`<guid>`"                          | "podcast:publisher:guid" |
+| Blockchain Transaction | "`<blockchain>`:[`<chainId>`:]tx:`<txid, hex, lowercase>`" | "`<blockchain>`:tx"      |
+| Blockchain Address     | "`<blockchain>`:[`<chainId>`:]address:`<address>`"         | "`<blockchain>`:address" |

 ---

 ## Examples

+
+### Webpages
+
+For the webpage "https://myblog.example.com/post/2012-03-27/hello-world" the "i" and "k" tags are:
+
+```jsonc
+[
+  ["i", "https://myblog.example.com/post/2012-03-27/hello-world"],
+  ["k", "web"]
+]
+```
+
 ### Books:

 - Book ISBN: `["i", "isbn:9780765382030"]` - https://isbnsearch.org/isbn/9780765382030
@@ -47,6 +61,62 @@ Book ISBNs MUST be referenced _**without hyphens**_ as many book search APIs ret

 Movie ISANs SHOULD be referenced  _**without the version part**_ as the versions / edits of movies are not relevant. More info on ISAN parts here -  https://support.isan.org/hc/en-us/articles/360002783131-Records-relations-and-hierarchies-in-the-ISAN-Registry

+### Blockchain
+
+`<blockchain>` can be any layer 1 chain (`bitcoin`, `ethereum`, `solana`, ...). If necessary (e.g. for ethereum), you can specify a `<chainId>`.
+
+#### Bitcoin
+
+```
+bitcoin:address:<bech32, lowercase | base58, case sensitive>
+bitcoin:tx:<txid, hex, lowercase>
+```
+
+E.g. https://blockstream.info/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d
+
+```jsonc
+[
+  ["i", "bitcoin:tx:a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d"],
+  ["k", "bitcoin:tx"]
+]
+```
+
+E.g. https://blockstream.info/address/1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx
+
+```jsonc
+[
+  ["i", "bitcoin:address:1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx"],
+  ["k", "bitcoin:address"]
+]
+```
+
+#### Ethereum (and other EVM chains)
+
+```
+ethereum:<chainId, integer>:tx:<txHash, hex, lowercase>
+ethereum:<chainId, integer>:address:<hex, lowercase>
+```
+
+E.g. https://etherscan.io/address/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
+
+```jsonc
+[
+  ["i", "ethereum:1:address:0xd8da6bf26964af9d7eed9e03e53415d37aa96045"],
+  ["k", "ethereum:address"]
+]
+```
+
+E.g. https://gnosisscan.io/tx/0x98f7812be496f97f80e2e98d66358d1fc733cf34176a8356d171ea7fbbe97ccd
+
+```jsonc
+[
+  ["i", "ethereum:100:tx:0x98f7812be496f97f80e2e98d66358d1fc733cf34176a8356d171ea7fbbe97ccd"],
+  ["k", "ethereum:tx"]
+]
+```
+
+
+
 ---

 ### Optional URL Hints
@@ -56,5 +126,3 @@ Each `i` tag MAY have a url hint as the second argument to redirect people to a
 `["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg]`

 `["i", "isan:0000-0000-401A-0000-7", https://www.imdb.com/title/tt0120737]`
-
-
--- a/7D.md
+++ b/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"]
  ]
 }
 ```
--- a/84.md
+++ b/84.md
@@ -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.
--- a/88.md
+++ b/88.md
@@ -1,6 +1,8 @@
-# NIP-88
+NIP-88
+======

-## Polls
+Polls
+-----

 `draft` `optional`

--- a/B0.md
+++ b/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).
--- a/B7.md
+++ b/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
--- a/BREAKING.md
+++ b/BREAKING.md
@@ -5,6 +5,8 @@ reverse chronological order.

 | Date        | Commit    | NIP      | Change |
 | ----------- | --------- | -------- | ------ |
+| 2025-02-14  | [81908b6e](https://github.com/nostr-protocol/nips/commit/81908b6e) | [07](07.md), [46](46.md), [55](55.md) | `getRelays` and `get_relays` were removed |
+| 2025-02-07  | [0023ca81](https://github.com/nostr-protocol/nips/commit/0023ca81) | [10](10.md) | `"mention"` marker was removed |
 | 2025-01-31  | [6a4b125a](https://github.com/nostr-protocol/nips/commit/6a4b125a) | [71](71.md) | video events were changed to regular |
 | 2024-12-05  | [6d16019e](https://github.com/nostr-protocol/nips/commit/6d16019e) | [46](46.md) | message encryption was changed to NIP-44 |
 | 2024-11-12  | [2838e3bd](https://github.com/nostr-protocol/nips/commit/2838e3bd) | [29](29.md) | `kind: 12` and `kind: 10` were removed (use `kind: 1111` instead) |
--- a/C0.md
+++ b/C0.md
@@ -0,0 +1,69 @@
+NIP-C0
+======
+
+Code Snippets
+-------------
+
+`draft` `optional`
+
+## Abstract
+
+This NIP defines a new event kind for sharing and storing code snippets. Unlike regular text notes (`kind:1`), code snippets have specialized metadata like language, extension, and other code-specific attributes that enhance discoverability, syntax highlighting, and improved user experience.
+
+## Event Kind
+
+This NIP defines `kind:1337` as a code snippet event.
+
+The `.content` field contains the actual code snippet text.
+
+## Optional Tags
+
+- `l` - Programming language name (lowercase). Examples: "javascript", "python", "rust"
+- `name` - Name of the code snippet, commonly a filename. Examples: "hello-world.js", "quick-sort.py"
+- `extension` - File extension (without the dot). Examples: "js", "py", "rs"
+- `description` - Brief description of what the code does
+- `runtime` - Runtime or environment specification (e.g., "node v18.15.0", "python 3.11")
+- `license` - License under which the code is shared (e.g., "MIT", "GPL-3.0", "Apache-2.0")
+- `dep` - Dependency required for the code to run (can be repeated)
+- `repo` - Reference to a repository where this code originates
+
+## Format
+
+```json
+{
+  "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>,
+  "kind": 1337,
+  "content": "function helloWorld() {\n  console.log('Hello, Nostr!');\n}\n\nhelloWorld();",
+  "tags": [
+    ["l", "javascript"],
+    ["extension", "js"],
+    ["name", "hello-world.js"],
+    ["description", "A basic JavaScript function that prints 'Hello, Nostr!' to the console"],
+    ["runtime", "node v18.15.0"],
+    ["license", "MIT"],
+    ["repo", "https://github.com/nostr-protocol/nostr"]
+  ],
+  "sig": "<64-bytes signature of the id>"
+}
+```
+
+## Client Behavior
+
+Clients that support this NIP SHOULD:
+
+1. Display code snippets with proper syntax highlighting based on the language.
+2. Allow copying the full code snippet with a single action.
+3. Render the code with appropriate formatting, preserving whitespace and indentation.
+4. Display the language and extension prominently.
+5. Provide "run" functionality for supported languages when possible.
+6. Display the description (if available) as part of the snippet presentation.
+
+Clients MAY provide additional functionality such as:
+
+1. Code editing capabilities
+2. Forking/modifying snippets
+3. Creating executable environments based on the runtime/dependencies
+4. Downloading the snippet as a file using the provided extension
+5. Sharing the snippet with attribution
--- a/README.md
+++ b/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)
@@ -77,8 +77,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-59: Gift Wrap](59.md)
 - [NIP-60: Cashu Wallet](60.md)
 - [NIP-61: Nutzaps](61.md)
+- [NIP-62: Request to Vanish](62.md)
 - [NIP-64: Chess (PGN)](64.md)
 - [NIP-65: Relay List Metadata](65.md)
+- [NIP-66: Relay Discovery and Liveness Monitoring](66.md)
 - [NIP-68: Picture-first feeds](68.md)
 - [NIP-69: Peer-to-peer Order events](69.md)
 - [NIP-70: Protected Events](70.md)
@@ -87,6 +89,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-73: External Content IDs](73.md)
 - [NIP-75: Zap Goals](75.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)
@@ -97,7 +100,9 @@ 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)

 ## Event Kinds
@@ -125,11 +130,16 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `20`          | Picture                         | [68](68.md)                            |
 | `21`          | Video Event                     | [71](71.md)                            |
 | `22`          | Short-form Portrait Video Event | [71](71.md)                            |
+| `30`          | internal reference              | [NKBIP-03]                             |
+| `31`          | external web reference          | [NKBIP-03]                            |
+| `32`          | hardcopy reference              | [NKBIP-03]                            |
+| `33`          | prompt reference                | [NKBIP-03]                            |
 | `40`          | Channel Creation                | [28](28.md)                            |
 | `41`          | Channel Metadata                | [28](28.md)                            |
 | `42`          | Channel Message                 | [28](28.md)                            |
 | `43`          | Channel Hide Message            | [28](28.md)                            |
 | `44`          | Channel Mute User               | [28](28.md)                            |
+| `62`          | Request to Vanish               | [62](62.md)                            |
 | `64`          | Chess (PGN)                     | [64](64.md)                            |
 | `818`         | Merge Requests                  | [54](54.md)                            |
 | `1018`        | Poll Response                   | [88](88.md)                            |
@@ -141,9 +151,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1068`        | Poll                            | [88](88.md)                            |
 | `1111`        | Comment                         | [22](22.md)                            |
 | `1311`        | Live Chat Message               | [53](53.md)                            |
+| `1337`        | Code Snippet                    | [C0](C0.md)                            |
 | `1617`        | Patches                         | [34](34.md)                            |
 | `1621`        | Issues                          | [34](34.md)                            |
-| `1622`        | Replies                         | [34](34.md)                            |
+| `1622`        | Git Replies (deprecated)        | [34](34.md)                            |
 | `1630`-`1633` | Status                          | [34](34.md)                            |
 | `1971`        | Problem Tracker                 | [nostrocket][nostrocket]               |
 | `1984`        | Reporting                       | [56](56.md)                            |
@@ -176,13 +187,16 @@ 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]                     |
 | `10096`       | File storage server list        | [96](96.md)                            |
+| `10166`       | Relay Monitor Announcement      | [66](66.md)                            |
 | `13194`       | Wallet Info                     | [47](47.md)                            |
 | `17375`       | Cashu Wallet Event              | [60](60.md)                            |
 | `21000`       | Lightning Pub RPC               | [Lightning.Pub][lnpub]                 |
@@ -209,10 +223,11 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30023`       | Long-form Content               | [23](23.md)                            |
 | `30024`       | Draft Long-form Content         | [23](23.md)                            |
 | `30030`       | Emoji sets                      | [51](51.md)                            |
-| `30040`       | Modular Article Header          | [NKBIP-01]                             |
-| `30041`       | Modular Article Content         | [NKBIP-01]                             |
+| `30040`       | Curated Publication Index       | [NKBIP-01]                             |
+| `30041`       | Curated Publication Content     | [NKBIP-01]                             |
 | `30063`       | Release artifact sets           | [51](51.md)                            |
 | `30078`       | Application-specific Data       | [78](78.md)                            |
+| `30166`       | Relay Discovery                 | [66](66.md)                            |
 | `30267`       | App curation sets               | [51](51.md)                            |
 | `30311`       | Live Event                      | [53](53.md)                            |
 | `30315`       | User Statuses                   | [38](38.md)                            |
@@ -236,6 +251,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
@@ -243,8 +261,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 [cornychat-slideset]: https://cornychat.com/datatypes#kind30388slideset
 [cornychat-linkset]: https://cornychat.com/datatypes#kind31388linkset
 [joinstr]: https://gitlab.com/1440000bytes/joinstr/-/blob/main/NIP.md
-[NKBIP-01]: https://wikistr.com/nkbip-01
-[NKBIP-02]: https://wikistr.com/nkbip-02
+[NKBIP-01]: https://wikistr.com/nkbip-01*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
+[NKBIP-02]: https://wikistr.com/nkbip-02*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
+[NKBIP-03]: https://wikistr.com/nkbip-03*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
 [blossom]: https://github.com/hzrd149/blossom
 [Tidal-nostr]: https://wikistr.com/tidal-nostr

@@ -288,7 +307,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `I`               | root external identity               | --                              | [22](22.md)                                        |
 | `k`               | kind                                 | --                              | [18](18.md), [25](25.md), [72](72.md), [73](73.md) |
 | `K`               | root scope                           | --                              | [22](22.md)                                        |
-| `l`               | label, label namespace               | --                              | [32](32.md)                                        |
+| `l`               | label, label namespace, language name| --                              | [32](32.md), [C0](C0.md)                           |
 | `L`               | label namespace                      | --                              | [32](32.md)                                        |
 | `m`               | MIME type                            | --                              | [94](94.md)                                        |
 | `p`               | pubkey (hex)                         | relay URL, petname              | [01](01.md), [02](02.md), [22](22.md)              |
@@ -299,7 +318,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `s`               | status                               | --                              | [69](69.md)                                        |
 | `t`               | hashtag                              | --                              | [24](24.md), [34](34.md), [35](35.md)              |
 | `u`               | url                                  | --                              | [61](61.md), [98](98.md)                           |
-| `x`               | infohash                             | --                              | [35](35.md)                                        |
+| `x`               | hash                                 | --                              | [35](35.md), [56](56.md)                           |
 | `y`               | platform                             | --                              | [69](69.md)                                        |
 | `z`               | order number                         | --                              | [69](69.md)                                        |
 | `-`               | --                                   | --                              | [70](70.md)                                        |
@@ -311,29 +330,34 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `clone`           | git clone URL                        | --                              | [34](34.md)                                        |
 | `content-warning` | reason                               | --                              | [36](36.md)                                        |
 | `delegation`      | pubkey, conditions, delegation token | --                              | [26](26.md)                                        |
-| `description`     | description                          | --                              | [34](34.md), [57](57.md), [58](58.md)              |
+| `dep`             | Required dependency                  | --                              | [C0](C0.md)                                        |
+| `description`     | description                          | --                              | [34](34.md), [57](57.md), [58](58.md), [C0](C0.md) |
 | `emoji`           | shortcode, image URL                 | --                              | [30](30.md)                                        |
 | `encrypted`       | --                                   | --                              | [90](90.md)                                        |
+| `extension`       | File extension                       | --                              | [C0](C0.md)                                        |
 | `expiration`      | unix timestamp (string)              | --                              | [40](40.md)                                        |
 | `file`            | full path (string)                   | --                              | [35](35.md)                                        |
 | `goal`            | event id (hex)                       | relay URL                       | [75](75.md)                                        |
 | `image`           | image URL                            | dimensions in pixels            | [23](23.md), [52](52.md), [58](58.md)              |
 | `imeta`           | inline metadata                      | --                              | [92](92.md)                                        |
+| `license`         | License of the shared content        | --                              | [C0](C0.md)                                        |
 | `lnurl`           | `bech32` encoded `lnurl`             | --                              | [57](57.md)                                        |
 | `location`        | location string                      | --                              | [52](52.md), [99](99.md)                           |
-| `name`            | name                                 | --                              | [34](34.md), [58](58.md), [72](72.md)              |
+| `name`            | name                                 | --                              | [34](34.md), [58](58.md), [72](72.md), [C0](C0.md) |
 | `nonce`           | random                               | difficulty                      | [13](13.md)                                        |
 | `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)                                        |
+| `runtime`         | Runtime or environment specification | --                              | [C0](C0.md)                                        |
 | `server`          | file storage server url              | --                              | [96](96.md)                                        |
 | `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)                                        |
Author	SHA1	Message	Date
fiatjaf	8a54595516	remove mentions to uuids.	2025-05-12 20:34:07 -03:00
AsaiToshiya	873afc5fb8	add follow packs to README.	2025-05-09 20:07:23 +09:00
fiatjaf_	564814ac7d	add follow packs to nip51 (#1898 )	2025-05-08 22:51:09 -03:00
Cody Tseng	ccd02f2612	NIP-51: favorite relays (#1848 )	2025-05-08 22:50:12 -03:00
Vitor Pamplona	ebfcd72a8d	Using yaml to fix NIP-01 JSON formatting (#1910 )	2025-05-05 21:11:52 -03:00
Vitor Pamplona	86f0da716f	NIP-17 json formatting fix, text cleanup and more precise language (#1909 )	2025-05-05 06:36:20 -07:00
Darrell	5b7d338200	fix typo nip-60 (#1901 )	2025-05-01 16:34:37 +09:00
Awiteb	2ade2e6229	NIP-65: Add note about re-publishing kind 10002 (#1889 ) Signed-off-by: Awiteb <a@4rs.nl> Co-authored-by: hodlbod <jstaab@protonmail.com>	2025-04-30 13:41:45 -07:00
Alexander Lopatin	85f3282e46	Fix JSON format (#1896 )	2025-04-29 08:28:46 -07:00
Vitor Pamplona	77fdeeb6f1	Deprecates NIP-26 (#1051 )	2025-04-29 09:31:22 -03:00
Sepehr Safari	b96b72b488	Add NIP-B0 Standardized Tags to README.md (#1895 )	2025-04-29 21:21:27 +09:00
Sebastian Hagens	507830c5c4	Add kind 39701 web bookmarks to list of kinds in readme (#1891 )	2025-04-25 12:32:49 -03:00
fiatjaf	473f651b3e	uppercase B7 and B0.	2025-04-24 13:53:56 -03:00
fiatjaf	257e8700ea	add B0 to index.	2025-04-24 13:52:59 -03:00
Sebastian Hagens	121258a611	adding more info / requirements for using kind 39701 for web bookmarks (NIP-B0) (#1849 ) Co-authored-by: fiatjaf <fiatjaf@gmail.com>	2025-04-24 13:52:29 -03:00
fiatjaf_	5a371a5b92	add B7 NIP for Blossom interaction (#1822 )	2025-04-24 13:47:04 -03:00
Awiteb	4f09333ab5	Fix nips titles and descriptions (#1888 ) Signed-off-by: Awiteb <a@4rs.nl>	2025-04-23 11:57:55 -07:00
Awiteb	8cdfe98e74	fix: Fix NIP-66 title and description format (#1886 )	2025-04-23 09:31:08 -07:00
alltheseas	4ba28112e6	Update 11.md with privacy policy and terms of service (#1882 )	2025-04-21 15:56:43 -03:00
fiatjaf_	951aaa8ba1	nip7D: `subject` -> `title` (#1874 )	2025-04-17 17:15:37 -03:00
William Casarin	c076437282	Quoted highlights (#1438 ) Signed-off-by: William Casarin <jb55@jb55.com>	2025-04-17 12:55:17 -03:00
fiatjaf_	45f6d598a1	Shrink NIP-65 so it is clearer (#1879 ) Co-authored-by: Vitor Pamplona <vitor@vitorpamplona.com>	2025-04-15 18:07:49 -03:00
k.	611b635186	nip-11: remove max filters, add max/default query limit, update example. (#1821 )	2025-04-13 14:15:24 -03:00
Vitor Pamplona	55f96bbeef	Fixes C0 links (#1870 )	2025-04-08 07:56:38 -07:00
hodlbod	d5907d094b	Add note about re-publishing kind 10002 (#1801 ) Co-authored-by: Jon Staab <shtaab@gmail.com>	2025-04-07 09:43:01 -07:00
Awiteb	3e8c33ee79	NIP-C0: Add `NIP-C0` tags to standardized tags table (#1865 ) Co-authored-by: AsaiToshiya <to.asai.60@gmail.com>	2025-04-03 20:07:46 +09:00
fiatjaf	8f676dc0a5	nip73: bring back previous ordering.	2025-04-02 10:11:54 -03:00
Xavier Damman	67145a72b2	added blockchain transactions and addresses to NIP-73 (#1846 )	2025-04-02 10:09:54 -03:00
AsaiToshiya	9821b0e999	Update README.md	2025-03-30 10:03:27 +09:00
mono	ca9904f042	Add birth field to NIP-24 for birth date representation (#1793 )	2025-03-30 09:31:03 +09:00
fiatjaf	f901014065	rename 95 to C0.	2025-03-29 16:29:58 -03:00
Christian Chiarulli	7dad42c1cf	NIP-C0: Code snippets (#1852 )	2025-03-29 16:29:33 -03:00
Vitor Pamplona	86fc82ce4a	Deprecates git replies in favor of NIP-22 (#1744 )	2025-03-26 09:38:47 -03:00
Vitor Pamplona	0619f370bc	NIP-17 Typos and grammar improvements (#1840 )	2025-03-13 10:23:35 -03:00
fiatjaf_	bf699c9bc1	nip73: change "k" tags standard for webpage comments to a hardcoded `web` (#1836 )	2025-03-10 11:05:51 -03:00
Silberengel	7a9e2ec87d	NKBIPs added and updated (#1775 )	2025-03-08 13:58:59 -08:00
Vitor Pamplona	078ffd873e	Long form with NIP-22 comments (#1830 )	2025-03-06 17:06:05 -03:00
Alex Gleason	0ed88ee0bd	NIP-01 `a` tag clarification (#1825 )	2025-03-04 17:26:54 -08:00
AsaiToshiya	d662d97c66	NIP-66: fix "PRE" to "addressable event". (#1820 )	2025-03-04 07:00:26 -03:00
AsaiToshiya	64d4e3ea3e	add NIP-66 to README.	2025-03-04 12:35:37 +09:00
Sandwich	89fac599f6	NIP-66 Relay Discovery and Liveness Monitoring (Draft 7) (#230 ) Co-authored-by: dskvr <dskvr@users.noreply.github.com>	2025-03-03 09:03:10 -08:00
greenart7c3	84c3d14afa	[NIP-55] Add a warning message when using web intents (#1457 ) Co-authored-by: dluvian <133484344+dluvian@users.noreply.github.com>	2025-02-28 15:55:35 -08:00
Vitor Pamplona	a3cd55fb33	NIP-17: Removes the need for markers and adds the use of `q` tags. (#1748 )	2025-02-26 20:14:45 -05:00
fiatjaf_	1e8b1bb16b	nip25: recommend that reactions do not include a million tags (#1811 )	2025-02-26 17:06:35 -03:00
cypherhoodlum	7cc120ecb0	Optional t tag to git repository announcements (#1798 )	2025-02-21 05:57:03 -08:00
AsaiToshiya	93d9a12f16	Update BREAKING.md	2025-02-20 21:11:22 +09:00
AsaiToshiya	0b6b69bcc7	add NIP-56 link to `x` tag. (#1724 )	2025-02-20 00:58:25 +09:00
Vitor Pamplona	58287cd641	Updates NIP-27 to use `q` tags instead of "mention" markers (#1751 )	2025-02-19 09:52:30 -06:00
Vitor Pamplona	0f12cf111f	Updates NIP-53 live chat to remove markers and add `q` tags (#1747 )	2025-02-19 10:36:45 -05:00
Vitor Pamplona	619e3bea57	Right to Vanish (#1256 ) Co-authored-by: fiatjaf_ <fiatjaf@gmail.com> Co-authored-by: K <kehiiiiya@gmail.com>	2025-02-18 19:08:36 -08:00