Update NIP-91

The NIP has been renamed to represent the goals of the NIP more accurately.

The x/ extension namespace has been removed, and any features meant to be standardized as a NIP should create a preliminary PR and use the `nip/` namespace. Any extensions that are meant to be standardized externally should use their own namespace.

17.md

@@ -133,7 +133,7 @@ When sending a message to anyone, clients must then connect to the relays in the
 
 This example sends the message `Hola, que tal?` from `nsec1w8udu59ydjvedgs3yv5qccshcj8k05fh3l60k9x57asjrqdpa00qkmr89m` to `nsec12ywtkplvyq5t6twdqwwygavp5lm4fhuang89c943nf2z92eez43szvn4dt`.
 
-The two final GiftWraps, one to the receiver and the other to the sender, are:
+The two final GiftWraps, one to the receiver and the other to the sender, respectively, are:
 
 ```json
 {

22.md

@@ -13,6 +13,9 @@ 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`).
 
+Comments MUST point to the authors when one is available (i.e. tagging a nostr event). `P` for the root scope
+and `p` for the author of the parent item.
+
 ```jsonc
 {
   kind: 1111,
@@ -23,10 +26,16 @@ and MUST point to the parent item with lowercase ones (e.g. `k`, `e`, `a` or `i`
     // the root item kind
     ["K", "<root kind>"],
 
+    // pubkey of the author of the root scope event
+    ["P", "<root-pubkey>", "relay-url-hint"],
+
     // parent item: event addresses, event ids, or i-tags.
     ["<a, e, i>", "<address, id or i-value>", "<relay or web page hint>", "<parent event's pubkey, if an e tag>"],
     // parent item kind
-    ["k", "<parent comment kind>"]
+    ["k", "<parent comment kind>"],
+
+    // parent item pubkey
+    ["p", "<parent-pubkey>", "relay-url-hint"]
   ]
   // other fields
 }
@@ -46,11 +55,6 @@ Their uppercase versions use the same type of values but relate to the root item
 ```
 
 `p` tags SHOULD be used when mentioning pubkeys in the `.content` with [NIP-21](21.md).
-If the parent item is an event, a `p` tag set to the parent event's author SHOULD be added.
-
-```json
-["p", "<pubkey>", "<relay-url>"]
-```
 
 ## Examples
 
@@ -65,13 +69,17 @@ A comment on a blog post looks like this:
     ["A", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
     // the root kind
     ["K", "30023"],
+    // author of root event
+    ["P", "3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289", "wss://example.relay"]
 
     // the parent event address (same as root for top-level comments)
     ["a", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
     // when the parent event is replaceable or addressable, also include an `e` tag referencing its id
     ["e", "5b4fc7fed15672fefe65d2426f67197b71ccc82aa0cc8a9e94f683eb78e07651", "wss://example.relay"],
     // the parent event kind
-    ["k", "30023"]
+    ["k", "30023"],
+    // author of the parent event
+    ["p", "3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289", "wss://example.relay"]
   ]
   // other fields
 }
@@ -88,11 +96,14 @@ A comment on a [NIP-94](94.md) file looks like this:
     ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
     // the root kind
     ["K", "1063"],
+    // author of the root event
+    ["P", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
 
     // the parent event id (same as root for top-level comments)
     ["e", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
     // the parent kind
-    ["k", "1063"]
+    ["k", "1063"],
+    ["p", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"]
   ]
   // other fields
 }
@@ -109,11 +120,13 @@ A reply to a comment looks like this:
     ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
     // the root kind
     ["K", "1063"],
+    ["P", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
 
     // the parent event
     ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://example.relay", "93ef2ebaaf9554661f33e79949007900bbc535d239a4c801c33a4d67d3e7f546"],
     // the parent kind
-    ["k", "1111"]
+    ["k", "1111"],
+    ["p", "93ef2ebaaf9554661f33e79949007900bbc535d239a4c801c33a4d67d3e7f546"]
   ]
   // other fields
 }
@@ -178,7 +191,9 @@ A reply to a podcast comment:
     ["e", "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05", "wss://example.relay", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"],
     // the parent comment kind
     ["k", "1111"]
+    ["p", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"]
   ]
   // other fields
 }
 ```
+

29.md

@@ -30,8 +30,6 @@ When encountering just the `<host>` without the `'<group-id>`, clients MAY infer
 
 Events sent by users to groups (chat messages, text notes, moderation events etc) MUST have an `h` tag with the value set to the group _id_.
 
-`h` tags MAY include the group's name as the second argument. This allows `unmanaged` groups to be assigned human-readable names without relay support.
-
 ## Timeline references
 
 In order to not be used out of context, events sent to these groups may contain references to previous events seen from the same relay in the `previous` tag. The choice of which previous events to pick belongs to the clients. The references are to be made using the first 8 characters (4 bytes) of any event in the last 50 events seen by the user in the relay, excluding events by themselves. There can be any number of references (including zero), but it's recommended that clients include at least 3 and that relays enforce this.
@@ -72,7 +70,7 @@ These are events that can be sent by users to manage their situation in a group,
 
 - *join request* (`kind:9021`)
 
-Any user can send one of these events to the relay in order to be automatically or manually added to the group. If the group is `open` the relay will automatically issue a `kind:9000` in response adding this user. Otherwise group admins may choose to query for these requests and act upon them.
+Any user can send a kind `9021` event to the relay in order to request admission to the group. Relays MUST reject the request if the user has not been added to the group. The accompanying error message SHOULD explain whether the rejection is final, if the request is pending review, or if some other special handling is relevant (e.g. if payment is required). If a user is already a member, the event MUST be rejected with `duplicate: ` as the error message prefix.
 
 ```json
 {
@@ -242,3 +240,5 @@ A definition for `kind:10009` was included in [NIP-51](51.md) that allows client
 ### Using `unmanaged` relays
 
 To prevent event leakage, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
+
+Groups MAY be named without relay support by adding a `name` to the corresponding tag in a user's `kind 10009` group list.

32.md

@@ -157,7 +157,7 @@ considered open for public use, and not proprietary. In other words, if there is
 namespace that fits your use case, use it even if it points to someone else's domain name.
 
 Vocabularies MAY choose to fully qualify all labels within a namespace (for example,
-`["l", "com.example.vocabulary:my-label"]`. This may be preferred when defining more
+`["l", "com.example.vocabulary:my-label"]`). This may be preferred when defining more
 formal vocabularies that should not be confused with another namespace when querying
 without an `L` tag. For these vocabularies, all labels SHOULD include the namespace
 (rather than mixing qualified and unqualified labels).
@@ -173,4 +173,4 @@ Appendix: Known Ontologies
 
 Below is a non-exhaustive list of ontologies currently in widespread use.
 
-- [social.ontolo.categories](https://ontolo.social/)
+- [social ontology categories](https://github.com/CLARIAH/awesome-humanities-ontologies)

37.md

@@ -0,0 +1,50 @@
+NIP-37
+======
+
+Draft Events 
+------------
+
+`draft` `optional`
+
+This NIP defines kind `31234` as a private wrap for drafts of any other event kind. 
+
+The draft event is JSON-stringified, [NIP44-encrypted](44.md) to the signer's public key and placed inside the `.content` of the event.
+
+An additional `k` tag identifies the kind of the draft event. 
+
+```js
+{
+  "kind": 31234,
+  "tags": [
+    ["d", "<identifier>"],
+    ["k", "<kind of the draft event>"],
+    ["e", "<anchor event event id>", "<relay-url>"],
+    ["a", "<anchor event address>", "<relay-url>"],
+  ],
+  "content": nip44Encrypt(JSON.stringify(draft_event)),
+  // other fields
+}
+```
+
+A blanked `.content` means this draft has been deleted by a client but relays still have the event. 
+
+Tags `e` and `a` identify one or more anchor events, such as parent events on replies.   
+
+## Relay List for Private Content
+
+Kind `10013` indicates the user's preferred relays to store private events like Drafts. The event MUST include a list of `relay` URLs in private tags. Private tags are JSON Stringified, NIP-44-encrypted to the signer's keys and placed inside the .content of the event.
+
+```js
+{
+  "kind": 10013,
+  "tags": [],
+  "content": nip44Encrypt(JSON.stringify([
+    ["relay", "wss://myrelay.mydomain.com"]
+  ]))
+  //...other fields
+}
+```
+
+Relays listed in this event SHOULD be authed and only allow downloads to events signed by the authed user.
+
+Clients SHOULD publish kind `10013` events to the author's [NIP-65](65.md) `write` relays. 

44.md

@@ -8,11 +8,11 @@ Encrypted Payloads (Versioned)
 
 The NIP introduces a new data format for keypair-based encryption. This NIP is versioned
 to allow multiple algorithm choices to exist simultaneously. This format may be used for
-many things, but MUST be used in the context of a signed event as described in NIP 01.
+many things, but MUST be used in the context of a signed event as described in NIP-01.
 
 *Note*: this format DOES NOT define any `kind`s related to a new direct messaging standard,
 only the encryption required to define one. It SHOULD NOT be used as a drop-in replacement
-for NIP 04 payloads.
+for NIP-04 payloads.
 
 ## Versions
 
@@ -41,7 +41,7 @@ On its own, messages sent using this scheme have a number of important shortcomi
 - No post-compromise security: when a key is compromised, it is possible to decrypt all future conversations
 - No post-quantum security: a powerful quantum computer would be able to decrypt the messages
 - IP address leak: user IP may be seen by relays and all intermediaries between user and relay
-- Date leak: `created_at` is public, since it is a part of NIP 01 event
+- Date leak: `created_at` is public, since it is a part of NIP-01 event
 - Limited message size leak: padding only partially obscures true message length
 - No attachments: they are not supported
 
@@ -86,7 +86,7 @@ NIP-44 version 2 has the following design characteristics:
    - Content must be encoded from UTF-8 into byte array
    - Validate plaintext length. Minimum is 1 byte, maximum is 65535 bytes
    - Padding format is: `[plaintext_length: u16][plaintext][zero_bytes]`
-   - Padding algorithm is related to powers-of-two, with min padded msg size of 32bytes
+   - Padding algorithm is related to powers-of-two, with min padded msg size of 32 bytes
    - Plaintext length is encoded in big-endian as first 2 bytes of the padded blob
 5. Encrypt padded content
    - Use ChaCha20, with key and nonce from step 3
@@ -148,8 +148,8 @@ validation rules, refer to BIP-340.
   - `x[i:j]`, where `x` is a byte array and `i, j <= 0` returns a `(j - i)`-byte array with a copy of the
     `i`-th byte (inclusive) to the `j`-th byte (exclusive) of `x`.
 - Constants `c`:
-  - `min_plaintext_size` is 1. 1bytes msg is padded to 32bytes.
-  - `max_plaintext_size` is 65535 (64kB - 1). It is padded to 65536bytes.
+  - `min_plaintext_size` is 1. 1 byte msg is padded to 32 bytes.
+  - `max_plaintext_size` is 65535 (64kB - 1). It is padded to 65536 bytes.
 - Functions
   - `base64_encode(string)` and `base64_decode(bytes)` are Base64 ([RFC 4648](https://datatracker.ietf.org/doc/html/rfc4648), with padding)
   - `concat` refers to byte array concatenation

47.md

@@ -107,7 +107,7 @@ The content of notifications is encrypted with [NIP04](https://github.com/nostr-
 ## Nostr Wallet Connect URI
 **client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI.
 
-The **wallet service** generates this connection URI with protocol `nostr+walletconnect://` and base path it's hex-encoded `pubkey` with the following query string parameters:
+The **wallet service** generates this connection URI with protocol `nostr+walletconnect://` and base path its hex-encoded `pubkey` with the following query string parameters:
 
 - `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one.
 - `secret` Required. 32-byte randomly generated hex encoded string. The **client** MUST use this to sign events and encrypt payloads when communicating with the **wallet service**.
@@ -175,7 +175,7 @@ Request:
 Response:
 
 For every invoice in the request, a separate response event is sent. To differentiate between the responses, each
-response event contains a `d` tag with the id of the invoice it is responding to, if no id was given, then the
+response event contains a `d` tag with the id of the invoice it is responding to; if no id was given, then the
 payment hash of the invoice should be used.
 
 ```jsonc
@@ -247,7 +247,7 @@ Request:
 Response:
 
 For every keysend in the request, a separate response event is sent. To differentiate between the responses, each
-response event contains an `d` tag with the id of the keysend it is responding to, if no id was given, then the
+response event contains a `d` tag with the id of the keysend it is responding to; if no id was given, then the
 pubkey should be used.
 
 ```jsonc

51.md

@@ -14,7 +14,7 @@ When new items are added to an existing list, clients SHOULD append them to the
 
 ## Types of lists
 
-## Standard lists
+### Standard lists
 
 Standard lists use normal replaceable events, meaning users may only have a single list of each kind. They have special meaning and clients may rely on them to augment a user's profile or browsing experience.
 
@@ -29,14 +29,14 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | Public chats      | 10005 | [NIP-28](28.md) chat channels the user is in                | `"e"` (kind:40 channel definitions)                                               |
 | 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), `"r"` for each relay in use     |
+| 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     |
 | Interests         | 10015 | topics a user may be interested in and pointers             | `"t"` (hashtags) and `"a"` (kind:30015 interest set)                              |
 | Emojis            | 10030 | user preferred emojis and pointers to emoji sets            | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set)                  |
 | DM relays         | 10050 | Where to receive [NIP-17](17.md) direct messages            | `"relay"` (see [NIP-17](17.md))                                                   |
 | Good wiki authors | 10101 | [NIP-54](54.md) user recommended wiki authors               | `"p"` (pubkeys)                                                                   |
 | Good wiki relays  | 10102 | [NIP-54](54.md) relays deemed to only host useful articles  | `"relay"` (relay URLs)                                                            |
 
-## Sets
+### Sets
 
 Sets are lists with well-defined meaning that can enhance the functionality and the UI of clients that rely on them. Unlike standard lists, users are expected to have more than one set of each kind, therefore each of them must be assigned a different `"d"` identifier.
 
@@ -54,9 +54,10 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
 | 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"`  |
+| 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) |
 
-## Deprecated standard lists
+### 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.
 
@@ -117,22 +118,39 @@ Some clients have used these lists in the past, but they should work on transiti
   "pubkey": "d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c",
   "created_at": 1695327657,
   "kind": 30063,
+  "content": "Release notes in markdown",
   "tags": [
-    ["d", "ak8dy3v7"],
-    ["i", "com.example.app"],
-    ["version", "0.0.1"],
-    ["title", "Example App"],
-    ["image", "http://cdn.site/p/com.example.app/icon.png"],
+    ["d", "com.example.app@0.0.1"],
     ["e", "d78ba0d5dce22bfff9db0a9e996c9ef27e2c91051de0c4e1da340e0326b4941e"], // Windows exe
     ["e", "f27e2c91051de0c4e1da0d5dce22bfff9db0a9340e0326b4941ed78bae996c9e"], // MacOS dmg
     ["e", "9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad02332"], // Linux AppImage
-    ["e", "340e0326b340e0326b4941ed78ba340e0326b4941ed78ba340e0326b49ed78ba"] // PWA
+    ["e", "340e0326b340e0326b4941ed78ba340e0326b4941ed78ba340e0326b49ed78ba"], // PWA
+    ["a", "32267:d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:com.example.app"] // Reference to parent software application
   ],
   "content": "Example App is a decentralized marketplace for apps",
   "sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
 }
 ```
 
+### An _app curation set_
+
+```jsonc
+{
+    "id": "d8037fa866eb5acd2159960b3ada7284172f7d687b5289cc72a96ca2b431b611",
+    "pubkey": "78ce6faa72264387284e647ba6938995735ec8c7d5c5a65737e55130f026307d",
+    "sig": "c1ce0a04521c020ae7485307cd86285530c1f778766a3fd594d662a73e7c28f307d7cd9a9ab642ae749fce62abbabb3a32facfe8d19a21fba551b60fae863d95",
+    "kind": 30267,
+    "created_at": 1729302793,
+    "content": "My nostr app selection",
+    "tags": [
+        ["d", "nostr"],
+        ["a", "32267:7579076d9aff0a4cfdefa7e2045f2486c7e5d8bc63bfc6b45397233e1bbfcb19:com.example.app1"],
+        ["a", "32267:045f2486c7e5d8bc63bfc6b45397233e1bbfcb197579076d9aff0a4cfdefa7e2:net.example.app2"],
+        ["a", "32267:264387284e647ba6938995735ec8c7d5c5a6f026307d78ce6faa725737e55130:pl.code.app3"]
+    ]
+}
+```
+
 ## Encryption process pseudocode
 
 ```scala

90.md

@@ -185,7 +185,7 @@ Any job feedback event MIGHT include results in the `.content` field, as describ
 * Customer publishes a job request (e.g. `kind:5000` speech-to-text).
 * Service Providers MAY submit `kind:7000` job-feedback events (e.g. `payment-required`, `processing`, `error`, etc.).
 * Upon completion, the service provider publishes the result of the job with a `kind:6000` job-result event.
-* At any point, if there is an `amount` pending to be paid as instructed by the service provider, the user can pay the included `bolt11` or zap the job result event the service provider has sent to the user
+* At any point, if there is an `amount` pending to be paid as instructed by the service provider, the user can pay the included `bolt11` or zap the job result event the service provider has sent to the user.
 
 Job feedback (`kind:7000`) and Job Results (`kind:6000-6999`) events MAY include an `amount` tag, this can be interpreted as a suggestion to pay. Service Providers MUST use the `payment-required` feedback event to signal that a payment is required and no further actions will be performed until the payment is sent.
 

91.md

@@ -0,0 +1,88 @@
+NIP-91
+======
+
+Extension Negotiation
+---------------------
+
+`draft` `optional`
+
+This NIP defines a method for clients to negotiate new features with relays.
+
+## Extension Names
+
+Each extension has a **extension name** that can uniquely identify the extension. Currently the following formats are recommended:
+- `nip/XX-<description>`: For extensions that are standardized in NIPs. Experimental extensions are recommended to have a unique description to not conflict.
+- `<namespace>/<extension>`: For extensions standardized by an independent body. The namespace should uniquely identify the standardizing body for this extension with a DNS name. (example: `example.com/example-extension`)
+
+Any extension name outside this list MUST NOT be used.
+
+## Extension Offers
+
+The relay may send a extension offer as a `EN-OFFER` message. The client SHOULD NOT send any messages relating to extension negotiation until it receives an `EN-OFFER`.
+```jsonc
+[
+  "EN-OFFER",
+  {
+    "example.com/example-extension": {...},
+    "nip-XX-example-extension": {...}
+  }
+]
+```
+
+The first entry MUST be an object, with the keys being extension names, and the values being objects. The format of the object is left to the specification of the specific extension.
+
+A extension offer can be sent multiple times in a connection, such as to update availability based off of their [NIP-42](./42.md) authentication status.
+
+Clients SHOULD be able to handle extension offers being able to be withdrawn, and should treat them as if it was a `EN-SHUTDOWN` if they were in use. 
+
+Certain extensions, such as extensions to REQs, may not need negotiation. This is up to the extension specification.
+
+## Extension Requests
+
+A client may request a extension offered by the relay be enabled with the `EN-REQUEST` message:
+```jsonc
+[
+  "EN-REQUEST",
+  "example.com/example-extension",
+  {...}
+]
+```
+
+The first entry MUST be the extension name, and the second entry MUST be a extension-dependent object for the extension enable request.
+
+The relay SHOULD respond with a `EN-OK` or `EN-ERROR` message:
+```jsonc
+[
+  "EN-OK",
+  "example.com/example-extension",
+  {...}
+]
+```
+```jsonc
+[
+  "EN-ERROR",
+  "example.com/example-extension",
+  "improper extension request data"
+]
+```
+
+In both messages, the first entry MUST be the extension name. The second entry depends on the type:
+- `EN-OK`: Response data for the extension negotiation. After this message, the extension can be used.
+- `EN-ERROR`: An error message.
+
+An error message SHOULD start with a single-word prefix, followed by a colon (:) and space character, and a human readable message. The following types are defined:
+- `error`: An internal error has occurred in the relay.
+- `not-offered`: The extension was not offered. This may happen due to a `EN-REQUEST` being sent at the same time as a new `EN-OFFER`.
+- `bad-data`: The client has sent improper extension negotiation data.
+
+## Extension Cancel
+
+The relay or client may stop the usage of the extension any time with a `EN-CANCEL` message:
+```jsonc
+[
+  "EN-CANCEL",
+  "example.com/example-extension"
+]
+```
+
+After this message, the sending party will no longer accept and send new extension messages, and the receiver should not continue attempting to use the extension functionality.

94.md

@@ -10,7 +10,7 @@ The purpose of this NIP is to allow an organization and classification of shared
 
 ## Event format
 
-This NIP specifies the use of the `1063` event type, having in `content` a description of the file content, and a list of tags described below:
+This NIP specifies the use of the `1063` event kind, having in `content` a description of the file content, and a list of tags described below:
 
 * `url` the url to download the file
 * `m` a string indicating the data type of the file. The [MIME types](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types) format must be used, and they should be lowercase.

BREAKING.md

@@ -5,6 +5,7 @@ reverse chronological order.
 
 | Date        | Commit    | NIP      | Change |
 | ----------- | --------- | -------- | ------ |
+| 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) |
 | 2024-11-12  | [926a51e7](https://github.com/nostr-protocol/nips/commit/926a51e7) | [46](46.md) | NIP-05 login was removed |
 | 2024-11-12  | [926a51e7](https://github.com/nostr-protocol/nips/commit/926a51e7) | [46](46.md) | `create_account` method was removed |
@@ -30,8 +31,7 @@ reverse chronological order.
 | 2024-02-07  | [d3dad114](https://github.com/nostr-protocol/nips/commit/d3dad114) | [46](46.md) | Connection token format was changed |
 | 2024-01-30  | [1a2b21b6](https://github.com/nostr-protocol/nips/commit/1a2b21b6) | [59](59.md) | 'p' tag became optional |
 | 2023-01-27  | [c2f34817](https://github.com/nostr-protocol/nips/commit/c2f34817) | [47](47.md) | optional expiration tag should be honored |
-| 2024-01-10  | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [02](02.md) | list entries should be chronological |
-| 2024-01-10  | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [51](51.md) | list entries should be chronological |
+| 2024-01-10  | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [02](02.md), [51](51.md) | list entries should be chronological |
 | 2023-12-30  | [29869821](https://github.com/nostr-protocol/nips/commit/29869821) | [52](52.md) | 'name' tag was removed (use 'title' tag instead) |
 | 2023-12-27  | [17c67ef5](https://github.com/nostr-protocol/nips/commit/17c67ef5) | [94](94.md) | 'aes-256-gcm' tag was removed |
 | 2023-12-03  | [0ba45895](https://github.com/nostr-protocol/nips/commit/0ba45895) | [01](01.md) | WebSocket status code `4000` was replaced by 'CLOSED' message |
@@ -46,10 +46,7 @@ reverse chronological order.
 | 2023-08-21  | [89915e02](https://github.com/nostr-protocol/nips/commit/89915e02) | [11](11.md) | 'min_prefix' was removed |
 | 2023-08-20  | [37c4375e](https://github.com/nostr-protocol/nips/commit/37c4375e) | [01](01.md) | replaceable events with same timestamp should be retained event with lowest id |
 | 2023-08-15  | [88ee873c](https://github.com/nostr-protocol/nips/commit/88ee873c) | [15](15.md) | 'countries' tag was renamed to 'regions' |
-| 2023-08-14  | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [12](12.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
-| 2023-08-14  | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [16](16.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
-| 2023-08-14  | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [20](20.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
-| 2023-08-14  | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [33](33.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
+| 2023-08-14  | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [12](12.md), [16](16.md), [20](20.md), [33](33.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
 | 2023-08-11  | [d87f8617](https://github.com/nostr-protocol/nips/commit/d87f8617) | [25](25.md) | empty `content` should be considered as "+" |
 | 2023-08-01  | [5d63b157](https://github.com/nostr-protocol/nips/commit/5d63b157) | [57](57.md) | 'zap' tag was changed |
 | 2023-07-15  | [d1814405](https://github.com/nostr-protocol/nips/commit/d1814405) | [01](01.md) | `since` and `until` filters should be `since <= created_at <= until` |

README.md

@@ -54,14 +54,15 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-34: `git` stuff](34.md)
 - [NIP-35: Torrents](35.md)
 - [NIP-36: Sensitive Content](36.md)
+- [NIP-37: Draft Events](37.md)
 - [NIP-38: User Statuses](38.md)
 - [NIP-39: External Identities in Profiles](39.md)
 - [NIP-40: Expiration Timestamp](40.md)
 - [NIP-42: Authentication of clients to relays](42.md)
-- [NIP-44: Versioned Encryption](44.md)
+- [NIP-44: Encrypted Payloads (Versioned)](44.md)
 - [NIP-45: Counting results](45.md)
-- [NIP-46: Nostr Connect](46.md)
-- [NIP-47: Wallet Connect](47.md)
+- [NIP-46: Nostr Remote Signing](46.md)
+- [NIP-47: Nostr Wallet Connect](47.md)
 - [NIP-48: Proxy Tags](48.md)
 - [NIP-49: Private Key Encryption](49.md)
 - [NIP-50: Search Capability](50.md)
@@ -169,6 +170,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10006`       | Blocked relays list             | [51](51.md)                            |
 | `10007`       | Search relays list              | [51](51.md)                            |
 | `10009`       | User groups                     | [51](51.md), [29](29.md)               |
+| `10013`       | Draft relays                    | [37](37.md)                            |
 | `10015`       | Interests list                  | [51](51.md)                            |
 | `10019`       | Nutzap Mint Recommendation      | [61](61.md)                            |
 | `10030`       | User emoji list                 | [51](51.md)                            |
@@ -213,6 +215,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30618`       | Repository state announcements  | [34](34.md)                            |
 | `30818`       | Wiki article                    | [54](54.md)                            |
 | `30819`       | Redirects                       | [54](54.md)                            |
+| `31234`       | Draft Event                     | [37](37.md)                            |
 | `31388`       | Link Set                        | [Corny Chat][cornychat-linkset]        |
 | `31890`       | Feed                            | [NUD: Custom Feeds][NUD: Custom Feeds] |
 | `31922`       | Date-Based Calendar Event       | [52](52.md)                            |
@@ -282,8 +285,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `l`               | label, label namespace               | --                              | [32](32.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)                           |
-| `P`               | pubkey (hex)                         | --                              | [57](57.md)                                        |
+| `p`               | pubkey (hex)                         | relay URL, petname              | [01](01.md), [02](02.md), [22](22.md)              |
+| `P`               | pubkey (hex)                         | --                              | [22](22.md), [57](57.md)                           |
 | `q`               | event id (hex)                       | relay URL, pubkey (hex)         | [18](18.md)                                        |
 | `r`               | a reference (URL, etc)               | --                              | [24](24.md), [25](25.md)                           |
 | `r`               | relay url                            | marker                          | [65](65.md)                                        |
@@ -341,9 +344,9 @@ Please update these lists when proposing new NIPs.
 
 ## Is this repository a centralizing factor?
 
-To promote interoperability, we standards that everybody can follow, and we need them to define a **single way of doing each thing** without ever hurting **backwards-compatibility**, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such index exists doesn't hurt the decentralization of Nostr. _At any point the central index can be challenged if it is failing to fulfill the needs of the protocol_ and it can migrate to other places and be maintained by other people.
+To promote interoperability, we need standards that everybody can follow, and we need them to define a **single way of doing each thing** without ever hurting **backwards-compatibility**, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such an index exists doesn't hurt the decentralization of Nostr. _At any point the central index can be challenged if it is failing to fulfill the needs of the protocol_ and it can migrate to other places and be maintained by other people.
 
-It can even fork into multiple and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.
+It can even fork into multiple versions, and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.
 
 There is a list of notable Nostr software developers who have commit access to this repository, but that exists mostly for practical reasons, as by the nature of the thing we're dealing with the repository owner can revoke membership and rewrite history as they want -- and if these actions are unjustified or perceived as bad or evil the community must react.