add kind:30006 for kind-scoped curations

nip24: clarify nip purpose.
nip24: revert improperly merged joke.
2025-12-13 10:28:50 +00:00 · 2024-11-22 16:25:08 +00:00 · 2024-11-21 12:14:08 -03:00 · 2024-11-21 12:13:29 -03:00 · 2024-11-21 11:55:23 -03:00 · 2024-11-20 15:15:10 -05:00
14 changed files with 270 additions and 117 deletions
--- a/05.md
+++ b/05.md
@@ -10,7 +10,7 @@ On events of kind `0` (`user metadata`) one can specify the key `"nip05"` with a

 Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`.

-The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `user's metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
+The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `user metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.

 ### Example

--- a/10.md
+++ b/10.md
@@ -10,33 +10,6 @@ On "e" and "p" tags in Text Events (kind 1)
 ## Abstract
 This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events.  It helps clients thread the replies into a tree rooted at the original event.

-## Positional "e" tags (DEPRECATED)
->This scheme is in common use; but should be considered deprecated.
-
-`["e", <event-id>, <relay-url>]`  as per NIP-01.
-
-Where:
-
- * `<event-id>` is the id of the event being referenced.
- * `<relay-url>` is the URL of a recommended relay associated with the reference.  Many clients treat this field as optional.
-
-**The positions of the "e" tags within the event denote specific meanings as follows**:
-
- * No "e" tag: <br>
- This event is not a reply to, nor does it refer to, any other event.
-
- * One "e" tag: <br>
- `["e", <id>]`: The id of the event to which this event is a reply.
-
- * Two "e" tags:  `["e", <root-id>]`, `["e", <reply-id>]` <br>
- `<root-id>` is the id of the event at the root of the reply chain.  `<reply-id>` is the id of the article to which this event is a reply.
-
- * Many "e" tags: `["e", <root-id>]` `["e", <mention-id>]`, ..., `["e", <reply-id>]`<br>
-There may be any number of `<mention-ids>`.  These are the ids of events which may, or may not be in the reply chain.
-They are citing from this event.  `root-id` and `reply-id` are as above.
-
->This scheme is deprecated because it creates ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.
-
 ## Marked "e" tags (PREFERRED)
 `["e", <event-id>, <relay-url>, <marker>, <pubkey>]`

@@ -62,3 +35,33 @@ When replying to a text event E the reply event's "p" tags should contain all of

 Example:  Given a text event authored by `a1` with "p" tags [`p1`, `p2`, `p3`] then the "p" tags of the reply should be [`a1`, `p1`, `p2`, `p3`]
 in no particular order.
+
+## Deprecated Positional "e" tags
+
+This scheme is not in common use anymore and is here just to keep backward compatibility with older events on the network. 
+
+Positional `e` tags are deprecated because they create ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.
+
+They use simple `e` tags without any marker. 
+
+`["e", <event-id>, <relay-url>]` as per NIP-01.
+
+Where:
+
+ * `<event-id>` is the id of the event being referenced.
+ * `<relay-url>` is the URL of a recommended relay associated with the reference.  Many clients treat this field as optional.
+
+**The positions of the "e" tags within the event denote specific meanings as follows**:
+
+ * No "e" tag: <br>
+ This event is not a reply to, nor does it refer to, any other event.
+
+ * One "e" tag: <br>
+ `["e", <id>]`: The id of the event to which this event is a reply.
+
+ * Two "e" tags:  `["e", <root-id>]`, `["e", <reply-id>]` <br>
+ `<root-id>` is the id of the event at the root of the reply chain.  `<reply-id>` is the id of the article to which this event is a reply.
+
+ * Many "e" tags: `["e", <root-id>]` `["e", <mention-id>]`, ..., `["e", <reply-id>]`<br>
+There may be any number of `<mention-ids>`.  These are the ids of events which may, or may not be in the reply chain.
+They are citing from this event.  `root-id` and `reply-id` are as above.
--- a/11.md
+++ b/11.md
@@ -262,7 +262,7 @@ processed by appropriate client software.

 Relays that require payments may want to expose their fee schedules.

-```json
+```jsonc
 {
  "payments_url": "https://my-relay/payments",
  "fees": {
@@ -270,7 +270,7 @@ Relays that require payments may want to expose their fee schedules.
    "subscription": [{ "amount": 5000000, "unit": "msats", "period": 2592000 }],
    "publication": [{ "kinds": [4], "amount": 100, "unit": "msats" }],
  },
-  ...
+  // other fields...
 }
 ```

--- a/17.md
+++ b/17.md
@@ -47,7 +47,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An

 Following [NIP-59](59.md), the **unsigned** `kind:14` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.

-```js
+```jsonc
 {
  "id": "<usual hash>",
   "pubkey": randomPublicKey,
--- a/22.md
+++ b/22.md
@@ -13,7 +13,7 @@ It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other forma
 Comments MUST point to the root scope using uppercase tag names (e.g. `K`, `E`, `A` or `I`)
 and MUST point to the parent item with lowercase ones (e.g. `k`, `e`, `a` or `i`).

-```js
+```jsonc
 {
  kind: 1111,
  content: '<comment>',
@@ -56,7 +56,7 @@ If the parent item is an event, a `p` tag set to the parent event's author SHOUL

 A comment on a blog post looks like this:

-```js
+```jsonc
 {
  kind: 1111,
  content: 'Great blog post!',
@@ -79,7 +79,7 @@ A comment on a blog post looks like this:

 A comment on a [NIP-94](94.md) file looks like this:

-```js
+```jsonc
 {
  kind: 1111,
  content: 'Great file!',
@@ -100,7 +100,7 @@ A comment on a [NIP-94](94.md) file looks like this:

 A reply to a comment looks like this:

-```js
+```jsonc
 {
  kind: 1111,
  content: 'This is a reply to "Great file!"',
@@ -121,7 +121,7 @@ A reply to a comment looks like this:

 A comment on a website's url looks like this:

-```js
+```jsonc
 {
  kind: 1111,
  content: 'Nice article!',
@@ -142,7 +142,7 @@ A comment on a website's url looks like this:

 A podcast comment example:

-```js
+```jsonc
 {
  id: "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
  pubkey: "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
@@ -164,7 +164,7 @@ A podcast comment example:

 A reply to a podcast comment:

-```js
+```jsonc
 {
  kind: 1111,
  content: "I'm replying to the above comment.",
--- a/24.md
+++ b/24.md
@@ -6,7 +6,7 @@ Extra metadata fields and tags

 `draft` `optional`

-This NIP defines extra optional fields added to events.
+This NIP keeps track of extra optional fields that can added to events which are not defined anywhere else but have become _de facto_ standards and other minor implementation possibilities that do not deserve their own NIP and do not have a place in other NIPs.

 kind 0
 ======
--- a/29.md
+++ b/29.md
@@ -26,7 +26,7 @@ Group identifiers must be strings restricted to the characters `a-z0-9-_`.

 When encountering just the `<host>` without the `'<group-id>`, clients can choose to connect to the group with id `_`, which is a special top-level group dedicated to relay-local discussions.

-Group identifiers in most cases should be random or pseudo-random, as that mitigates message replay confusiong and ensures they can be migrated or forked to other relays easily without risking conflicting with other groups using the same id in these new relays. This isn't a hard rule, as, for example, in `unmanaged` and/or ephemeral relays groups might not want to migrate ever, so they might not care about this. Notably, the `_` relay-local group isn't expected to be migrated ever.
+Group identifiers in most cases should be random or pseudo-random, as that mitigates message replay confusion and ensures they can be migrated or forked to other relays easily without risking conflicting with other groups using the same id in these new relays. This isn't a hard rule, as, for example, in `unmanaged` and/or ephemeral relays groups might not want to migrate ever, so they might not care about this. Notably, the `_` relay-local group isn't expected to be migrated ever.

 ## The `h` tag

@@ -64,39 +64,7 @@ These are the events expected to be found in NIP-29 groups.

 ### Normal user-created events

-These events generally can be sent by all members of a group and they require the `h` tag to be present so they're attached to a specific group.
-
- _chat message_ (`kind:9`)
-
-This is the basic unit of a _chat message_ sent to a group.
-
-```jsonc
-  "kind": 9,
-  "content": "hello my friends lovers of pizza",
-  "tags": [
-    ["h", "<group-id>"],
-    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", /*...*/]
-  ]
-  // other fields...
-```
-
- _thread root post_ (`kind:11`)
-
-This is the basic unit of a forum-like root thread post sent to a group.
-
-```jsonc
-  "kind": 11,
-  "content": "hello my friends lovers of pizza",
-  "tags": [
-    ["h", "<group-id>"],
-    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", /*...*/]
-  ]
-  // other fields...
-```
-
- _other events_:
-
-Groups may also accept other events, like [NIP-22](22.md) comments as threaded replies to both chats messages and threads, long-form articles, calendar, livestreams, market announcements and so on. These should be as defined in their respective NIPs, with the addition of the `h` tag.
+Groups may accept any event kind, including chats, threads, long-form articles, calendar, livestreams, market announcements and so on. These should be as defined in their respective NIPs, with the addition of the `h` tag.

 ### User-related group management events

@@ -141,7 +109,7 @@ These are events expected to be sent by the relay master key or by group admins

 Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action based on its role and the relay's internal policy (see also the description of `kind:39003`).

-```json
+```jsonc
 {
  "kind": 90xx,
  "content": "optional reason",
--- a/46.md
+++ b/46.md
@@ -58,7 +58,7 @@ _user_ passes this token to _remote-signer_, which then sends `connect` *respons

 ## Request Events `kind: 24133`

-```js
+```jsonc
 {
    "kind": 24133,
    "pubkey": <local_keypair_pubkey>,
@@ -136,7 +136,7 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted

 ### Signature request

-```js
+```jsonc
 {
    "kind": 24133,
    "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
@@ -156,7 +156,7 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted

 ### Response event

-```js
+```jsonc
 {
    "kind": 24133,
    "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
@@ -196,7 +196,7 @@ _client_ should display (in a popup or new tab) the URL from the `error` field a
 ### Announcing _remote-signer_ metadata

 _remote-signer_ MAY publish it's metadata by using [NIP-05](05.md) and [NIP-89](89.md). With NIP-05, a request to `<remote-signer>/.well-known/nostr.json?name=_` MAY return this:
-```
+```jsonc
 {
    "names":{
        "_": <remote-signer-app-pubkey>,
--- a/47.md
+++ b/47.md
@@ -8,32 +8,42 @@ Nostr Wallet Connect

 ## Rationale

-This NIP describes a way for clients to access a remote Lightning wallet through a standardized protocol. Custodians may implement this, or the user may run a bridge that bridges their wallet/node and the Nostr Wallet Connect protocol.
+This NIP describes a way for clients to access a remote lightning wallet through a standardized protocol. Custodians may implement this, or the user may run a bridge that bridges their wallet/node and the Nostr Wallet Connect protocol.

 ## Terms

-* **client**: Nostr app on any platform that wants to pay Lightning invoices.
-* **user**: The person using the **client**, and want's to connect their wallet app to their **client**.
+* **client**: Nostr app on any platform that wants to interact with a lightning wallet.
+* **user**: The person using the **client**, and wants to connect their wallet to their **client**.
 * **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi).  This app has access to the APIs of the wallets it serves.

 ## Theory of Operation
- 1. **Users** who wish to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
+ 1. **Users** who wish to use this NIP to allow **client(s)** to interact with their wallet must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
 
- 2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc.  The **client(s)** should save this URI and use it later whenever the **user** makes a payment.  The **client** should then request an `info` (13194) event from the relay(s) specified in the URI.  The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.  
+ 2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc.  The **client(s)** should save this URI and use it later whenever the **user** (or the **client** on the user's behalf) wants to interact with the wallet.  The **client** should then request an `info` (13194) event from the relay(s) specified in the URI.  The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.  
 
 3. When the **user** initiates a payment their nostr **client** create a `pay_invoice` request, encrypts it using a token from the URI, and sends it (kind 23194) to the relay(s) specified in the connection URI.  The **wallet service** will be listening on those relays and will decrypt the request and then contact the **user's** wallet application to send the payment.  The **wallet service** will know how to talk to the wallet application because the connection URI specified relay(s) that have access to the wallet app API.  
 
- 4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI.  
+ 4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI.
+ 
+ 5. The **wallet service** may send encrypted notifications (kind 23196) of wallet events (such as a received payment) to the **client**.

 ## Events

-There are three event kinds:
+There are four event kinds:
 - `NIP-47 info event`: 13194
 - `NIP-47 request`: 23194
 - `NIP-47 response`: 23195
+- `NIP-47 notification event`: 23196

-The info event should be a replaceable event that is published by the **wallet service** on the relay to indicate which commands it supports. The content should be
-a plaintext string with the supported commands, space-separated, eg. `pay_invoice get_balance`. Only the `pay_invoice` command is described in this NIP, but other commands might be defined in different NIPs.
+### Info Event
+
+The info event should be a replaceable event that is published by the **wallet service** on the relay to indicate which capabilities it supports.
+
+The content should be a plaintext string with the supported capabilities space-separated, eg. `pay_invoice get_balance notifications`.
+
+If the **wallet service** supports notifications, the info event SHOULD contain a `notifications` tag with the supported notification types space-separated, eg. `payment_received payment_sent`.
+
+### Request and Response Events

 Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to.
 Optionally, a request can have an `expiration` tag that has a unix timestamp in seconds. If the request is received after this timestamp, it should be ignored.
@@ -68,6 +78,22 @@ The `result_type` field MUST contain the name of the method that this event is r
 The `error` field MUST contain a `message` field with a human readable error message and a `code` field with the error code if the command was not successful.
 If the command was successful, the `error` field must be null.

+### Notification Events
+
+The notification event SHOULD contain one `p` tag, the public key of the **user**.
+
+The content of notifications is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure:
+
+```jsonc
+{
+    "notification_type": "payment_received", //indicates the structure of the notification field
+    "notification": {
+        "payment_hash": "0123456789abcdef..." // notification-related data
+    }
+}
+```
+
+
 ### Error codes
 - `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds.
 - `NOT_IMPLEMENTED`: The command is not known or is intentionally not implemented.
@@ -120,7 +146,8 @@ Response:
 {
    "result_type": "pay_invoice",
    "result": {
-        "preimage": "0123456789abcdef..." // preimage of the payment
+        "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
    }
 }
 ```
@@ -155,7 +182,8 @@ payment hash of the invoice should be used.
 {
    "result_type": "multi_pay_invoice",
    "result": {
-        "preimage": "0123456789abcdef..." // preimage of the payment
+        "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
    }
 }
 ```
@@ -189,6 +217,7 @@ Response:
    "result_type": "pay_keysend",
    "result": {
        "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
    }
 }
 ```
@@ -225,7 +254,8 @@ pubkey should be used.
 {
    "result_type": "multi_pay_keysend",
    "result": {
-        "preimage": "0123456789abcdef..." // preimage of the payment
+        "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
    }
 }
 ```
@@ -394,6 +424,59 @@ Response:
            "block_height": 1,
            "block_hash": "hex string",
            "methods": ["pay_invoice", "get_balance", "make_invoice", "lookup_invoice", "list_transactions", "get_info"], // list of supported methods for this connection
+            "notifications": ["payment_received", "payment_sent"], // list of supported notifications for this connection, optional.
+    }
+}
+```
+
+## Notifications
+
+### `payment_received`
+
+Description: A payment was successfully received by the wallet.
+
+Notification:
+```jsonc
+{
+    "notification_type": "payment_received",
+    "notification": {
+        "type": "incoming",
+        "invoice": "string", // encoded invoice
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "preimage": "string", // payment's preimage
+        "payment_hash": "string", // Payment hash for the payment
+        "amount": 123, // value in msats
+        "fees_paid": 123, // value in msats
+        "created_at": unixtimestamp, // invoice/payment creation time
+        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+        "settled_at": unixtimestamp, // invoice/payment settlement time
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
+    }
+}
+```
+
+### `payment_sent`
+
+Description: A payment was successfully sent by the wallet.
+
+Notification:
+```jsonc
+{
+    "notification_type": "payment_sent",
+    "notification": {
+        "type": "outgoing",
+        "invoice": "string", // encoded invoice
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "preimage": "string", // payment's preimage
+        "payment_hash": "string", // Payment hash for the payment
+        "amount": 123, // value in msats
+        "fees_paid": 123, // value in msats
+        "created_at": unixtimestamp, // invoice/payment creation time
+        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+        "settled_at": unixtimestamp, // invoice/payment settlement time
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
    }
 }
 ```
@@ -407,3 +490,24 @@ Response:

 ## Using a dedicated relay
 This NIP does not specify any requirements on the type of relays used. However, if the user is using a custodial service it might make sense to use a relay that is hosted by the custodial service. The relay may then enforce authentication to prevent metadata leaks. Not depending on a 3rd party relay would also improve reliability in this case.
+
+## Appendix
+
+### Example NIP-47 info event
+
+```jsonc
+{
+  "id": "df467db0a9f9ec77ffe6f561811714ccaa2e26051c20f58f33c3d66d6c2b4d1c",
+  "pubkey": "c04ccd5c82fc1ea3499b9c6a5c0a7ab627fbe00a0116110d4c750faeaecba1e2",
+  "created_at": 1713883677,
+  "kind": 13194,
+  "tags": [
+    [
+      "notifications",
+      "payment_received payment_sent"
+    ]
+  ],
+  "content": "pay_invoice pay_keysend get_balance get_info make_invoice lookup_invoice list_transactions multi_pay_invoice multi_pay_keysend sign_message notifications",
+  "sig": "31f57b369459b5306a5353aa9e03be7fbde169bc881c3233625605dd12f53548179def16b9fe1137e6465d7e4d5bb27ce81fd6e75908c46b06269f4233c845d8"
+}
+```
--- a/51.md
+++ b/51.md
@@ -1,8 +1,6 @@
-NIP-51
-======
+# NIP-51

-Lists
-----
+## Lists

 `draft` `optional`

@@ -21,7 +19,7 @@ Standard lists use normal replaceable events, meaning users may only have a sing
 For example, _mute list_ can contain the public keys of spammers and bad actors users don't want to see in their feeds or receive annoying notifications from.

 | name              | kind  | description                                                 | expected tag items                                                                |
-| ---               | ---   | ---                                                         | ---                                                                               |
+| ----------------- | ----- | ----------------------------------------------------------- | --------------------------------------------------------------------------------- |
 | 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)                                                              |
 | Bookmarks         | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) |
@@ -44,24 +42,25 @@ For example, _relay sets_ can be displayed in a dropdown UI to give users the op

 Aside from their main identifier, the `"d"` tag, sets can optionally have a `"title"`, an `"image"` and a `"description"` tags that can be used to enhance their UI.

-| name          | kind  | description                                                                                  | expected tag items                                                                |
-| ---           | ---   | ---                                                                                          | ---                                                                               |
-| Follow sets   | 30000 | categorized groups of users a client may choose to check out in different circumstances      | `"p"` (pubkeys)                                                                   |
-| Relay sets    | 30002 | user-defined relay groups the user can easily pick and choose from during various operations | `"relay"` (relay URLs)                                                            |
-| Bookmark sets | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups    | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) |
-| Curation sets | 30004 | groups of articles picked by users as interesting and/or belonging to the same category      | `"a"` (kind:30023 articles), `"e"` (kind:1 notes)                                 |
-| Curation sets | 30005 | groups of videos picked by users as interesting and/or belonging to the same category        | `"a"` (kind:34235 videos)                                                         |
-| Kind mute sets | 30007 | mute pubkeys by kinds<br>`"d"` tag MUST be the kind string                                  | `"p"` (pubkeys)                                                                   |
-| Interest sets | 30015 | interest topics represented by a bunch of "hashtags"                                         | `"t"` (hashtags)                                                                  |
-| Emoji sets    | 30030 | categorized emoji groups                                                                     | `"emoji"` (see [NIP-30](30.md))                                                   |
-| Release artifact sets | 30063 | groups of files of a software release  | `"e"` (kind:1063 [file metadata](94.md) events), `"i"` (application identifier, typically reverse domain notation), `"version"`  |
+| name                  | kind  | description                                                                                                                            | expected tag items                                                                                                              |
+| --------------------- | ----- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
+| Follow sets           | 30000 | categorized groups of users a client may choose to check out in different circumstances                                                | `"p"` (pubkeys)                                                                                                                 |
+| Relay sets            | 30002 | user-defined relay groups the user can easily pick and choose from during various operations                                           | `"relay"` (relay URLs)                                                                                                          |
+| Bookmark sets         | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups                                              | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs)                                               |
+| Curation sets         | 30004 | groups of articles picked by users as interesting and/or belonging to the same category                                                | `"a"` (kind:30023 articles), `"e"` (kind:1 notes)                                                                               |
+| Curation sets         | 30005 | groups of videos picked by users as interesting and/or belonging to the same category                                                  | `"a"` (kind:34235 videos)                                                                                                       |
+| Kind Curation sets    | 30006 | groups of any kind of events picked by users as interesting and/or belonging to the same category<br>`"d"` tag MUST be the kind string | `"e"` or `"a"`                                                                                                                  |
+| Kind mute sets        | 30007 | mute pubkeys by kinds<br>`"d"` tag MUST be the kind string                                                                             | `"p"` (pubkeys)                                                                                                                 |
+| Interest sets         | 30015 | interest topics represented by a bunch of "hashtags"                                                                                   | `"t"` (hashtags)                                                                                                                |
+| Emoji sets            | 30030 | categorized emoji groups                                                                                                               | `"emoji"` (see [NIP-30](30.md))                                                                                                 |
+| Release artifact sets | 30063 | groups of files of a software release                                                                                                  | `"e"` (kind:1063 [file metadata](94.md) events), `"i"` (application identifier, typically reverse domain notation), `"version"` |

 ## Deprecated standard lists

 Some clients have used these lists in the past, but they should work on transitioning to the [standard formats](#standard-lists) above.

 | kind  | "d" tag         | use instead                   |
-| ---   | ---             | ---                           |
+| ----- | --------------- | ----------------------------- |
 | 30000 | `"mute"`        | kind 10000 _mute list_        |
 | 30001 | `"pin"`         | kind 10001 _pin list_         |
 | 30001 | `"bookmark"`    | kind 10003 _bookmarks list_   |
@@ -97,11 +96,26 @@ Some clients have used these lists in the past, but they should work on transiti
  "tags": [
    ["d", "jvdy9i4"],
    ["name", "Yaks"],
-    ["picture", "https://cdn.britannica.com/40/188540-050-9AC748DE/Yak-Himalayas-Nepal.jpg"],
-    ["about", "The domestic yak, also known as the Tartary ox, grunting ox, or hairy cattle, is a species of long-haired domesticated cattle found throughout the Himalayan region of the Indian subcontinent, the Tibetan Plateau, Gilgit-Baltistan, Tajikistan and as far north as Mongolia and Siberia."],
-    ["a", "30023:26dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:95ODQzw3ajNoZ8SyMDOzQ"],
-    ["a", "30023:54af95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:1-MYP8dAhramH9J5gJWKx"],
-    ["a", "30023:f8fe95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:D2Tbd38bGrFvU0bIbvSMt"],
+    [
+      "picture",
+      "https://cdn.britannica.com/40/188540-050-9AC748DE/Yak-Himalayas-Nepal.jpg"
+    ],
+    [
+      "about",
+      "The domestic yak, also known as the Tartary ox, grunting ox, or hairy cattle, is a species of long-haired domesticated cattle found throughout the Himalayan region of the Indian subcontinent, the Tibetan Plateau, Gilgit-Baltistan, Tajikistan and as far north as Mongolia and Siberia."
+    ],
+    [
+      "a",
+      "30023:26dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:95ODQzw3ajNoZ8SyMDOzQ"
+    ],
+    [
+      "a",
+      "30023:54af95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:1-MYP8dAhramH9J5gJWKx"
+    ],
+    [
+      "a",
+      "30023:f8fe95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:D2Tbd38bGrFvU0bIbvSMt"
+    ],
    ["e", "d78ba0d5dce22bfff9db0a9e996c9ef27e2c91051de0c4e1da340e0326b4941e"]
  ],
  "content": "",
--- a/7D.md
+++ b/7D.md
@@ -0,0 +1,34 @@
+NIP-7D
+======
+
+Threads
+-------
+
+`draft` `optional`
+
+A thread is a `kind 11` event.  Threads SHOULD include a `subject` with a summary
+of the thread's topic.
+
+```json
+{
+  "kind": 11,
+  "content": "Good morning",
+  "tags": [
+    ["subject", "GM"]
+  ]
+}
+```
+
+Replies to `kind 11` MUST use [NIP-22](./22.md) `kind 1111` comments. Replies should
+always be to the root `kind 11` to avoid arbitrarily nested reply hierarchies.
+
+```json
+{
+  "kind": 1111,
+  "content": "Cool beans",
+  "tags": [
+    ["K", "11"],
+    ["E", <event-id>, <relay-url>, <pubkey>]
+  ]
+}
+```
--- a/96.md
+++ b/96.md
@@ -323,8 +323,8 @@ Note: HTTP File Storage Server developers may skip this section. This is meant f
 A File Server Preference event is a kind 10096 replaceable event meant to select one or more servers the user wants
 to upload files to. Servers are listed as `server` tags:

-```json
-{.
+```jsonc
+{
  "kind": 10096,
  "content": "",
  "tags": [
--- a/C7.md
+++ b/C7.md
@@ -0,0 +1,29 @@
+NIP-C7
+======
+
+Chats
+-----
+
+`draft` `optional`
+
+A chat message is a `kind 9` event.
+
+```json
+{
+  "kind": 9,
+  "content": "GM",
+  "tags": []
+}
+```
+
+A reply to a `kind 9` is an additional `kind 9` which quotes the parent using a `q` tag.
+
+```json
+{
+  "kind": 9,
+  "content": "nostr:nevent1...\nyes",
+  "tags": [
+    ["q", <event-id>, <relay-url>, <pubkey>]
+  ]
+}
+```
--- a/README.md
+++ b/README.md
@@ -108,9 +108,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `7`           | Reaction                        | [25](25.md)                            |
 | `8`           | Badge Award                     | [58](58.md)                            |
 | `9`           | Group Chat Message              | [29](29.md)                            |
-| `10`          | Group Chat Threaded Reply       | [29](29.md)                            |
+| `10`          | Group Chat Threaded Reply       | 29 (deprecated)                        |
 | `11`          | Group Thread                    | [29](29.md)                            |
-| `12`          | Group Thread Reply              | [29](29.md)                            |
+| `12`          | Group Thread Reply              | 29 (deprecated)                        |
 | `13`          | Seal                            | [59](59.md)                            |
 | `14`          | Direct Message                  | [17](17.md)                            |
 | `16`          | Generic Repost                  | [18](18.md)                            |
@@ -127,6 +127,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1040`        | OpenTimestamps                  | [03](03.md)                            |
 | `1059`        | Gift Wrap                       | [59](59.md)                            |
 | `1063`        | File Metadata                   | [94](94.md)                            |
+| `1111`        | Comment                         | [22](22.md)                            |
 | `1311`        | Live Chat Message               | [53](53.md)                            |
 | `1617`        | Patches                         | [34](34.md)                            |
 | `1621`        | Issues                          | [34](34.md)                            |
@@ -265,7 +266,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `A`               | root address                         | relay URL                       | [22](22.md)                                        |
 | `d`               | identifier                           | --                              | [01](01.md)                                        |
 | `e`               | event id (hex)                       | relay URL, marker, pubkey (hex) | [01](01.md), [10](10.md)                           |
-| `E`               | root event i                         | relay URL                       | [22](22.md)                                        |
+| `E`               | root event id                        | relay URL                       | [22](22.md)                                        |
 | `f`               | currency code                        | --                              | [69](69.md)                                        |
 | `g`               | geohash                              | --                              | [52](52.md)                                        |
 | `h`               | group id                             | --                              | [29](29.md)                                        |
Author	SHA1	Message	Date
pablof7z	9ecc6af26e	add kind:30006 for kind-scoped curations	2024-11-22 16:25:08 +00:00
fiatjaf	ef1746dd2c	nip24: clarify nip purpose.	2024-11-21 12:14:08 -03:00
fiatjaf	03c64a6e95	nip24: revert improperly merged joke. this reverts https://github.com/nostr-protocol/nips/pull/1590	2024-11-21 12:13:29 -03:00
hodlbod	1e47fd7557	Break out chat and threads from nip 29 (#1591 )	2024-11-21 11:55:23 -03:00
Vitor Pamplona	84aeb10d39	Merge pull request #1164 from rolznz/feat/nip-47-notifications NIP-47 notifications	2024-11-20 15:15:10 -05:00
rabble	36fa8bb66f	Merge pull request #1590 from vitorpamplona/pronouns Adds pronouns	2024-11-20 17:55:40 +13:00
Vitor Pamplona	bbcea0c861	adds pronouns	2024-11-19 21:20:32 -05:00
hakkadaikon	f3244a0903	js,json -> jsonc	2024-11-17 18:34:48 -03:00
hodlbod	ac60e1d662	Merge pull request #1583 from s3-odara/patch-1 "user matadata"	2024-11-17 08:05:20 -08:00
小原晴太	108b631429	"user matadata"	2024-11-17 15:22:47 +00:00
Josh Brown	8794be6775	Fix typo in NIP-29	2024-11-15 16:49:35 -03:00
Vitor Pamplona	eca0a83d09	Moves deprecated stuff to the bottom	2024-11-15 00:19:06 -03:00
Asai Toshiya	8f112857a2	fix typo.	2024-11-15 08:34:58 +09:00
Asai Toshiya	3e540a38e2	update kinds table.	2024-11-14 13:47:23 -03:00
Roland Bewick	32b9f3f40f	feat: NIP-47 notifications	2024-06-21 17:22:32 +07:00