Complete removal of hashtag and url tags from bookmarks. (#2141 )

Improve generic reposts for replaceable events (#2132 )
Improve NIP-C0 (#2138 )
2025-12-08 16:18:50 +00:00 · 2025-12-01 20:12:23 -05:00 · 2025-12-01 17:07:37 -08:00 · 2025-11-26 09:05:45 -03:00 · 2025-11-21 20:04:54 -03:00 · 2025-11-21 07:11:35 -03:00
43 changed files with 1259 additions and 550 deletions
--- a/03.md
+++ b/03.md
@@ -12,8 +12,8 @@ This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](
 {
  "kind": 1040
  "tags": [
-    ["e", <event-id>, <relay-url>],
-    ["alt", "opentimestamps attestation"]
+    ["e", <target-event-id>, <relay-url>],
+    ["k", "<target-event-kind>"]
  ],
  "content": <base64-encoded OTS file data>
 }
--- a/11.md
+++ b/11.md
@@ -17,14 +17,13 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
  "banner": <a link to an image (e.g. in .jpg, or .png format)>,
  "icon": <a link to an icon (e.g. in .jpg, or .png format>,
  "pubkey": <administrative contact pubkey>,
+  "self": <relay's own pubkey>,
  "contact": <administrative alternate contact>,
  "supported_nips": <a list of NIP numbers supported by the relay>,
  "software": <string identifying relay software URL>,
-  "version": <string version identifier>
+  "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>,
-
-
 }
 ```

@@ -62,6 +61,10 @@ An administrative contact may be listed with a `pubkey`, in the same format as N

 Relay operators have no obligation to respond to direct messages.

+### Self
+
+A relay MAY maintain an identity independent from its administrator using the `self` field, which MUST be a 32-byte hex public key. This allows relays to respond to requests with events published either in advance or on demand by their own key.
+
 ### Contact

 An alternative contact may be listed under the `contact` field as well, with the same purpose as `pubkey`.  Use of a Nostr public key and direct message SHOULD be preferred over this.  Contents of this field SHOULD be a URI, using schemes such as `mailto` or `https` to provide users with a means of contact.
@@ -162,7 +165,7 @@ 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.
+- `default_limit`: The maximum returned events if you send a filter without a `limit`.

 ### Event Retention

--- a/17.md
+++ b/17.md
@@ -6,9 +6,15 @@ Private Direct Messages

 `draft` `optional`

-This NIP defines an encrypted direct messaging scheme using [NIP-44](44.md) encryption and [NIP-59](59.md) seals and gift wraps.
+This NIP defines an encrypted chat scheme which uses [NIP-44](44.md) encryption and [NIP-59](59.md) seals and gift wraps.

-## Direct Message Kind
+Any event sent to an encrypted chat MUST NOT be signed, and MUST be encrypted as described in [NIP-59](./59.md) and illustrated below. Omitting signatures makes messages deniable in case they are accidentally or maliciously leaked, while still allowing the recipient to authenticate them.
+
+By convention, `kind 14` direct messages, `kind 15` file messages, and [`kind 7` reactions](./25.md) may be sent to an encrypted chat.
+
+## Kind Definitions
+
+### Chat Message

 Kind `14` is a chat message. `p` tags identify one or more receivers of the message.

@@ -31,7 +37,7 @@ Kind `14` is a chat message. `p` tags identify one or more receivers of the mess

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

-An `e` tag denotes the direct parent message this post is replying to. 
+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).

@@ -39,9 +45,7 @@ An `e` tag denotes the direct parent message this post is replying to.
 ["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**.
-
-## File Message Kind
+## File Message

 ```jsonc
 {
@@ -80,8 +84,6 @@ Kind `15` is used for sending encrypted file event messages:
 - `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.
-
 ## 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 a clean message history.
@@ -92,7 +94,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An

 ## Encrypting

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

 ```js
 {
@@ -127,7 +129,7 @@ Clients SHOULD randomize `created_at` in up to two days in the past in both the

 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
+Clients MAY 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. This tag SHOULD be included on the `kind 13` seal as well, in case it leaks.

 ## Publishing

@@ -145,15 +147,13 @@ Kind `10050` indicates the user's preferred relays to receive DMs. The event MUS
 }
 ```

-Clients SHOULD publish kind `14` events to the `10050`-listed relays. If that is not found that indicates the user is not ready to receive messages under this NIP and clients shouldn't try.
+Clients SHOULD publish the gift-wrapped `kind 1059` events that contain the sealed rumors to the relays listed in the recipient’s kind 10050 event. If that is not found that indicates the user is not ready to receive messages under this NIP and clients shouldn't try.

 ## Relays

-It's advisable that relays do not serve `kind:1059` to clients other than the ones tagged in them.
+Relays MAY protect message metadata by only serving `kind:1059` events to users p-tagged on the event (enforced using [NIP 42 AUTH](./42.md)).

-It's advisable that users choose relays that conform to these practices.
-
-Clients SHOULD guide users to keep `kind:10050` lists small (1-3 relays) and SHOULD spread it to as many relays as viable.
+Clients SHOULD guide users to keep `kind:10050` lists small (1-3 relays) and SHOULD spread them to as many relays as viable.

 ## Benefits & Limitations

@@ -170,12 +170,6 @@ This NIP offers the following privacy and security features:

 The main limitation of this approach is having to send a separate encrypted event to each receiver. Group chats with more than 100 participants should find a more suitable messaging scheme.

-## Implementation
-
-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.
-
 ## Examples

 This example sends the message `Hola, que tal?` from `nsec1w8udu59ydjvedgs3yv5qccshcj8k05fh3l60k9x57asjrqdpa00qkmr89m` to `nsec12ywtkplvyq5t6twdqwwygavp5lm4fhuang89c943nf2z92eez43szvn4dt`.
--- a/18.md
+++ b/18.md
@@ -1,8 +1,6 @@
-NIP-18
-======
+# NIP-18

-Reposts
-------
+## Reposts

 `draft` `optional`

@@ -21,18 +19,12 @@ reposted.

 ## Quote Reposts

-Quote reposts are `kind 1` events with an embedded `q` tag of the note being
-quote reposted. The `q` tag ensures quote reposts are not pulled and included
-as replies in threads. It also allows you to easily pull and count all of the
-quotes for a post.
+Mentions to [NIP-21](21.md) entities like `nevent`, `note` and `naddr` on any
+event must be converted into `q` tags. The `q` tag ensures quote reposts are
+not pulled and included as replies in threads. It also allows you to easily
+pull and count all of the quotes for a post. The syntax follows

-`q` tags should follow the same conventions as NIP 10 `e` tags, with the exception
-of the `mark` argument.
-
-`["q", <event-id>, <relay-url>, <pubkey>]`
-
-Quote reposts MUST include the [NIP-21](21.md) `nevent`, `note`, or `naddr` of the
-event in the content.
+`["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]`

 ## Generic Reposts

@@ -40,6 +32,12 @@ Since `kind 6` reposts are reserved for `kind 1` contents, we use `kind 16`
 as a "generic repost", that can include any kind of event inside other than
 `kind 1`.

-`kind 16` reposts SHOULD contain a `k` tag with the stringified kind number
+`kind 16` reposts SHOULD contain a `"k"` tag with the stringified kind number
 of the reposted event as its value.

+When reposting a replaceable event, the repost SHOULD include an `"a"` tag with
+the event coordinate (`kind:pubkey:d-tag`) of the reposted event.
+
+If the `"a"` tag is not present, it indicates that a specific version of a replaceable
+event is being reposted, in which case the `content` field must contain the full
+JSON string of the reposted event.
--- a/21.md
+++ b/21.md
@@ -21,7 +21,7 @@ The identifiers that come after are expected to be the same as those defined in

 ### Linking HTML pages to Nostr entities

-`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023' events served under itself as a relay or through some other relay). For example:
+`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023` events served under itself as a relay or through some other relay). For example:

 ```
 <head>
--- a/22.md
+++ b/22.md
@@ -45,7 +45,7 @@ Tags `K` and `k` MUST be present to define the event kind of the root and the pa

 `I` and `i` tags create scopes for hashtags, geohashes, URLs, and other external identifiers.

-The possible values for `i` tags – and `k` tags, when related to an extenal identity – are listed on [NIP-73](73.md).
+The possible values for `i` tags – and `k` tags, when related to an external identity – are listed on [NIP-73](73.md).
 Their uppercase versions use the same type of values but relate to the root item instead of the parent one.

 `q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
@@ -143,13 +143,13 @@ A comment on a website's url looks like this:
  "tags": [
    // referencing the root url
    ["I", "https://abc.com/articles/1"],
-    // the root "kind": for an url, the kind is its domain
-    ["K", "https://abc.com"],
+    // the root "kind": for an url
+    ["K", "web"],

    // the parent reference (same as root for top-level comments)
    ["i", "https://abc.com/articles/1"],
-    // the parent "kind": for an url, the kind is its domain
-    ["k", "https://abc.com"]
+    // the parent "kind": for an url
+    ["k", "web"]
  ]
  // other fields
 }
--- a/24.md
+++ b/24.md
@@ -8,8 +8,7 @@ Extra metadata fields and tags

 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
-======
+### kind 0

 These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events:

@@ -19,24 +18,22 @@ These are extra fields not specified in NIP-01 that may be present in the string
  - `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
+#### Deprecated fields

 These are fields that should be ignored or removed when found in the wild:

  - `displayName`: use `display_name` instead.
  - `username`: use `name` instead.

-kind 3
-======
+### kind 3

 These are extra fields not specified in NIP-02 that may be present in the stringified JSON of follow events:

-### Deprecated fields
+#### Deprecated fields

  - `{<relay-url>: {"read": <true|false>, "write": <true|false>}, ...}`: an object of relays used by a user to read/write. [NIP-65](65.md) should be used instead.

-tags
-====
+### tags

 These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings:

--- a/25.md
+++ b/25.md
@@ -26,8 +26,6 @@ There SHOULD be a `p` tag set to the `pubkey` of the event being reacted to. If

 If the event being reacted to is an addressable event, an `a` SHOULD be included together with the `e` tag, it must be set to the coordinates (`kind:pubkey:d-tag`) of the event being reacted to.

-The reaction SHOULD include a `k` tag with the stringified kind number of the reacted event as its value.
-
 The `e` and `a` tags SHOULD include relay and pubkey hints. The `p` tags SHOULD include relay hints.

 The reaction event MAY include a `k` tag with the stringified kind number of the reacted event as its value.
@@ -47,25 +45,39 @@ func make_like_event(pubkey: String, privkey: String, liked: NostrEvent, hint: S
 }
 ```

-Reactions to a website
+External Content Reactions
 ---------------------

-If the target of the reaction is a website, the reaction MUST be a `kind 17` event and MUST include an `r` tag with the website's URL.
+If the target of a reaction is not a native nostr event, the reaction MUST be a `kind 17` event and MUST include [NIP-73](73.md) external content `k` + `i` tags to properly reference the content.

+_Reacting to a website:_
 ```jsonc
 {
  "kind": 17,
  "content": "⭐",
  "tags": [
-    ["r", "https://example.com/"]
+    ["k", "web"],
+    ["i", "https://example.com"]
  ],
-  // other fields...
 }
 ```

-URLs SHOULD be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6), so that reactions to the same website are not omitted from queries.
-A fragment MAY be attached to the URL, to react to a section of the page.
-It should be noted that a URL with a fragment is not considered to be the same URL as the original.
+_Reacting to a podcast episode:_
+```jsonc
+{
+  "kind": 17,
+  "content": "+",
+  "tags": [
+    ["k", "podcast:guid"],
+    ["i", "podcast:guid:917393e3-1b1e-5cef-ace4-edaa54e1f810", "https://fountain.fm/show/QRT0l2EfrKXNGDlRrmjL"],
+    ["k", "podcast:item:guid"],
+    ["i", "podcast:item:guid:PC20-229", "https://fountain.fm/episode/DQqBg5sD3qFGMCZoSuLF"]
+  ],
+}
+```
+
+
+

 Custom Emoji Reaction
 ---------------------
--- a/26.md
+++ b/26.md
@@ -1,4 +1,4 @@
-> __Warning__  `unrecommended`: adds unecessary burden for little gain
+> __Warning__  `unrecommended`: adds unnecessary burden for little gain

 NIP-26
 =======
--- a/34.md
+++ b/34.md
@@ -10,7 +10,7 @@ This NIP defines all the ways code collaboration using and adjacent to [`git`](h

 ## Repository announcements

-Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events, as well as their willingness to receive patches, bug reports and comments in general.
+Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events. By doing so the author asserts themselves as a maintainer and expresses a willingness to receive patches, bug reports and comments in general, unless `t` tag `personal-fork` is included.

 ```jsonc
 {
@@ -25,6 +25,7 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a
    ["relays", "<relay-url>", ...], // relays that this repository will monitor for patches and issues
    ["r", "<earliest-unique-commit-id>", "euc"],
    ["maintainers", "<other-recognized-maintainer>", ...],
+    ["t","personal-fork"], // optionally indicate author isn't a maintainer
    ["t", "<arbitrary string>"], // hashtags labelling the repository
  ]
 }
@@ -45,7 +46,7 @@ An optional source of truth for the state of branches and tags in a repository.
  "kind": 30618,
  "content": "",
  "tags": [
-    ["d", "<repo-id>"], // matches the identifier in the coresponding repository announcement
+    ["d", "<repo-id>"], // matches the identifier in the corresponding repository announcement
    ["refs/<heads|tags>/<branch-or-tag-name>","<commit-id>"]
    ["HEAD", "ref: refs/heads/<branch-name>"]
  ]
@@ -66,9 +67,13 @@ The `refs` tag can be optionally extended to enable clients to identify how many
 }
 ```

-## Patches
+## Patches and Pull Requests (PRs)

-Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch events SHOULD include an `a` tag pointing to that repository's announcement address.
+Patches and PRs can be sent by anyone to any repository. Patches and PRs to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch and PR events SHOULD include an `a` tag pointing to that repository's announcement address.
+
+Patches SHOULD be used if each event is under 60kb, otherwise PRs SHOULD be used.
+
+### Patches

 Patches in a patch set SHOULD include a [NIP-10](10.md) `e` `reply` tag pointing to the previous patch.

@@ -103,9 +108,66 @@ The first patch revision in a patch revision SHOULD include a [NIP-10](10.md) `e

 The first patch in a series MAY be a cover letter in the format produced by `git format-patch`.

+### Pull Requests
+
+The PR or PR update tip SHOULD be successfully pushed to `refs/nostr/<[PR|PR-Update]-event-id>` in all repositories listed in its `clone` tag before the event is signed.
+
+An attempt SHOULD be made to push this ref to all repositories listed in the repository's announcement event's `"clone"` tag, for which their is reason to believe the user might have write access. This includes each [grasp server](https://njump.me/naddr1qvzqqqrhnypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy28wumn8ghj7un9d3shjtnwva5hgtnyv4mqqpt8wfshxuqlnvh8x) which can be identified using this method: `clone` tag includes `[http|https]://<grasp-path>/<valid-npub>/<string>.git` and `relays` tag includes `[ws/wss]://<grasp-path>`.
+
+Clients MAY fallback to creating a 'personal-fork' `repository announcement` listing other grasp servers, e.g. from the `User grasp list`, for the purpose of serving the specified commit(s).
+
+```jsonc
+{
+  "kind": 1618,
+  "content": "<markdown text>",
+  "tags": [
+    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
+    ["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all PRs sent to a local git repo
+    ["p", "<repository-owner>"],
+    ["p", "<other-user>"], // optionally send the PR to another user to bring it to their attention
+
+    ["subject", "<PR-subject>"],
+    ["t", "<PR-label>"], // optional
+    ["t", "<another-PR-label>"], // optional
+
+    ["c", "<current-commit-id>"], // tip of the PR branch
+    ["clone", "<clone-url>", ...], // at least one git clone url where commit can be downloaded
+    ["branch-name", "<branch-name>"], // optional recommended branch name
+
+    ["e", "<root-patch-event-id>"], // optionally indicate PR is a revision of an existing patch, which should be closed
+    ["merge-base", "<commit-id>"], // optional: the most recent common ancestor with the target branch
+  ]
+}
+```
+
+### Pull Request Updates
+
+A PR Update changes the tip of a referenced PR event.
+
+```jsonc
+{
+  "kind": 1619,
+  "content": "",
+  "tags": [
+    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
+    ["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all PRs sent to a local git repo
+    ["p", "<repository-owner>"],
+    ["p", "<other-user>"], // optionally send the PR to another user to bring it to their attention
+
+    // NIP-22 tags
+    ["E", "<pull-request-event-id>"],
+    ["P", "<pull-request-author>"],
+
+    ["c", "<current-commit-id>"], // updated tip of PR
+    ["clone", "<clone-url>", ...], // at least one git clone url where commit can be downloaded
+    ["merge-base", "<commit-id>"], // optional: the most recent common ancestor with the target branch
+  ]
+}
+```
+
 ## Issues

-Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. 
+Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag.

 Issues may have a `subject` tag, which clients can utilize to display a header. Additionally, one or more `t` tags may be included to provide labels for the issue.

@@ -125,11 +187,11 @@ Issues may have a `subject` tag, which clients can utilize to display a header.

 ## Replies

-Replies to either a `kind:1621` (_issue_) or a `kind:1617` (_patch_) event should follow [NIP-22 comment](22.md).
+Replies to either a `kind:1621` (_issue_), `kind:1617` (_patch_) or `kind:1618` (_pull request_) event should follow [NIP-22 comment](22.md).

 ## Status

-Root Patches and Issues have a Status that defaults to 'Open' and can be set by issuing Status events.
+Root Patches, PRs and Issues have a Status that defaults to 'Open' and can be set by issuing Status events.

 ```jsonc
 {
@@ -139,7 +201,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
  "kind": 1633, // Draft
  "content": "<markdown text>",
  "tags": [
-    ["e", "<issue-or-original-root-patch-id-hex>", "", "root"],
+    ["e", "<issue-or-PR-or-original-root-patch-id-hex>", "", "root"],
    ["e", "<accepted-revision-root-id-hex>", "", "reply"], // for when revisions applied
    ["p", "<repository-owner>"],
    ["p", "<root-event-author>"],
@@ -150,7 +212,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
    ["r", "<earliest-unique-commit-id-of-repo>"]

    // optional for `1631` status
-    ["e", "<applied-or-merged-patch-event-id>", "", "mention"], // for each
+    ["q", "<applied-or-merged-patch-event-id>", "<relay-url>", "<pubkey>"], // for each
    // when merged
    ["merge-commit", "<merge-commit-id>"]
    ["r", "<merge-commit-id>"]
@@ -165,8 +227,22 @@ The most recent Status event (by `created_at` date) from either the issue/patch

 The Status of a patch-revision is to either that of the root-patch, or `1632` (_Closed_) if the root-patch's Status is `1631` (_Applied/Merged_) and the patch-revision isn't tagged in the `1631` (_Applied/Merged_) event.

+## User grasp list
+
+List of [grasp servers](https://njump.me/naddr1qvzqqqrhnypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy28wumn8ghj7un9d3shjtnwva5hgtnyv4mqqpt8wfshxuqlnvh8x) the user generally wishes to use for NIP-34 related activity. It is similar in function to the NIP-65 relay list and NIP-B7 blossom list.
+
+The event SHOULD include a list of `g` tags with grasp service websocket URLs in order of preference.
+
+```jsonc
+{
+  "kind": 10317,
+  "content": "",
+  "tags": [
+    ["g", "<grasp-service-websocket-url>"], // zero or more grasp sever urls
+  ]
+}
+```

 ## Possible things to be added later

- "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
 - inline file comments kind (we probably need one for patches and a different one for merged files)
--- a/37.md
+++ b/37.md
@@ -1,50 +1,57 @@
 NIP-37
 ======

-Draft Events 
------------
+Draft Wraps
+-----------

 `draft` `optional`

-This NIP defines kind `31234` as a private wrap for drafts of any other event kind. 
+This NIP defines kind `31234` as an encrypted storage for unsigned draft events of any other 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.
+The draft is JSON-stringified, [NIP44-encrypted](44.md) to the signer's public key and placed inside the `.content`.

-An additional `k` tag identifies the kind of the draft event. 
+`k` tags identify the kind of the draft. 

 ```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>"],
+    ["k", "<kind of the draft event>"], // required
+    ["expiration", "now + 90 days"] // recommended
  ],
  "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. 
+A blanked `.content` field signals that the draft has been deleted. 

-Tags `e` and `a` identify one or more anchor events, such as parent events on replies.   
+[NIP-40](40.md) `expiration` tags are recommended. 
+
+Clients SHOULD publish kind `31234` events to relays listed on kind `10013` below.

 ## 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.
+Kind `10013` indicates the user's preferred relays to store private events like Draft Wraps. 
+
+The event MUST include a list of `relay` URLs in private tags. Private tags are JSON Stringified, [NIP44-encrypted](44.md) 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"]
-  ]))
+  "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.
+It's recommended that Private Storage relays SHOULD be [NIP-42](42.md)-authed and only allow downloads of events signed by the authed user.

-Clients SHOULD publish kind `10013` events to the author's [NIP-65](65.md) `write` relays. 
+Clients MUST publish kind `10013` events to the author's [NIP-65](65.md) `write` relays. 
--- a/38.md
+++ b/38.md
@@ -50,11 +50,11 @@ The status MAY include an `r`, `p`, `e` or `a` tag linking to a URL, profile, no

 The `content` MAY include emoji(s), or [NIP-30](30.md) custom emoji(s). If the `content` is an empty string then the client should clear the status.

-# Client behavior
+## Client behavior

 Clients MAY display this next to the username on posts or profiles to provide live user status information.

-# Use Cases
+## Use Cases

 * Calendar nostr apps that update your general status when you're in a meeting
 * Nostr Nests that update your general status with a link to the nest when you join
--- a/42.md
+++ b/42.md
@@ -32,6 +32,8 @@ And, when sent by clients, the following form:
 ["AUTH", <signed-event-json>]
 ```

+Clients MAY provide signed events from multiple pubkeys in a sequence of `AUTH` messages. Relays MUST treat all pubkeys as authenticated accordingly.
+
 `AUTH` messages sent by clients MUST be answered with an `OK` message, like any `EVENT` message.

 ### Canonical authentication event
@@ -69,7 +71,9 @@ relay: ["AUTH", "<challenge>"]
 client: ["REQ", "sub_1", {"kinds": [4]}]
 relay: ["CLOSED", "sub_1", "auth-required: we can't serve DMs to unauthenticated users"]
 client: ["AUTH", {"id": "abcdef...", ...}]
+client: ["AUTH", {"id": "abcde2...", ...}]
 relay: ["OK", "abcdef...", true, ""]
+relay: ["OK", "abcde2...", true, ""]
 client: ["REQ", "sub_1", {"kinds": [4]}]
 relay: ["EVENT", "sub_1", {...}]
 relay: ["EVENT", "sub_1", {...}]
--- a/43.md
+++ b/43.md
@@ -0,0 +1,146 @@
+NIP-43
+======
+
+Relay Access Metadata and Requests
+----------------------------------
+
+`draft` `optional`
+
+This NIP defines a way for relays to advertise membership lists, and for clients to request admission to relays on behalf of users.
+
+## Membership Lists
+
+Relays MAY publish a `kind 13534` event which indicates pubkeys that have access to a given relay. This event MUST be signed by the pubkey specified in the `self` field of the relay's [NIP 11](./11.md) document.
+
+The following tags are required:
+
+- A [NIP 70](./70.md) `-` tag
+- A `member` tag containing a hex pubkey should be included for each member
+
+This list should not be considered exhaustive or authoritative. To determine membership, both a `kind 13534` event by the relay, and a `kind 10010` event by the member should be consulted.
+
+Example:
+
+```jsonc
+{
+  "kind": 13534,
+  "pubkey": "<nip11.self>",
+  "tags": [
+    ["-"],
+    ["member", "c308e1f882c1f1dff2a43d4294239ddeec04e575f2d1aad1fa21ea7684e61fb5"],
+    ["member", "ee1d336e13779e4d4c527b988429d96de16088f958cbf6c074676ac9cfd9c958"]
+  ],
+  // ...other fields
+}
+```
+
+## Add User
+
+Relays MAY publish a `kind 8000` event when a member is added to the relay. This event MUST be signed by the pubkey specified in the `self` field of the relay's [NIP 11](./11.md) document.
+
+The following tags are required:
+
+- A [NIP 70](./70.md) `-` tag
+- A `p` tag indicating the member's hex pubkey
+
+Example:
+
+```jsonc
+{
+  "kind": 8000,
+  "pubkey": "<nip11.self>",
+  "tags": [
+    ["-"],
+    ["p", "c308e1f882c1f1dff2a43d4294239ddeec04e575f2d1aad1fa21ea7684e61fb5"]
+  ],
+  // ...other fields
+}
+```
+
+## Remove User
+
+Relays MAY publish a `kind 8001` event when a member is removed from the relay. This event MUST be signed by the pubkey specified in the `self` field of the relay's [NIP 11](./11.md) document.
+
+The following tags are required:
+
+- A [NIP 70](./70.md) `-` tag
+- A `p` tag indicating the member's hex pubkey
+
+Example:
+
+```jsonc
+{
+  "kind": 8001,
+  "pubkey": "<nip11.self>",
+  "tags": [
+    ["-"],
+    ["p", "c308e1f882c1f1dff2a43d4294239ddeec04e575f2d1aad1fa21ea7684e61fb5"]
+  ],
+  // ...other fields
+}
+```
+
+## Join Request
+
+A user MAY send a `kind 28934` to a relay in order to request admission. It MUST have a `claim` tag containing an invite code. The event's `created_at` MUST be now, plus or minus a few minutes.
+
+```jsonc
+{
+  "kind": 28934,
+  "pubkey": "<user pubkey>",
+  "tags": [
+    ["-"],
+    ["claim", "<invite code>"]
+  ],
+  // ...other fields
+}
+```
+
+Upon receiving a claim, a relay MUST notify the client as to what the status of the claim is using an `OK` message. Failed claims SHOULD use the same standard `"restricted: "` prefix specified by NIP 42.
+
+Relays SHOULD update their `kind 13534` member list and MAY publish a `kind 8000` "add member" event.
+
+Some examples:
+
+```
+["OK", <event-id>, false, "restricted: that invite code is expired."]
+["OK", <event-id>, false, "restricted: that is an invalid invite code."]
+["OK", <event-id>, true, "duplicate: you are already a member of this relay."]
+["OK", <event-id>, true, "info: welcome to wss://relay.bunk.skunk!"]
+```
+
+## Invite Request
+
+Users may request a claim string from a relay by making a request for `kind 28935` events. This event MUST be signed by the pubkey specified in the `self` field of the relay's [NIP 11](./11.md) document.
+
+```jsonc
+{
+  "kind": 28935,
+  "pubkey": "<nip11.self>",
+  "tags": [
+    ["-"],
+    ["claim", "<invite code>"],
+  ],
+  // ...other fields
+}
+```
+
+Note that these events are in the `ephemeral` range, which means relays must explicitly opt-in to this behavior by generating claims on the fly when requested. This allows relays to improve security by issuing a different claim for each request, only issuing claims to certain users, or expiring claims.
+
+## Leave Request
+
+A user MAY send a `kind 28936` to a relay in order to request that their access be revoked. The event's `created_at` MUST be now, plus or minus a few minutes. This event MUST include a [NIP 70](./70.md) `-` tag.
+
+```jsonc
+{
+  "kind": 28936,
+  "tags": [["-"]],
+  // ...other fields
+}
+```
+
+Relays SHOULD update their `kind 13534` member list and MAY publish a `kind 8001` "remove member" event.
+
+## Implementation
+
+Clients MUST only request `kind 28935` events from and send `kind 28934` events to relays which include this NIP in the `supported_nips` section of its [NIP 11](./11.md) relay information document.
--- a/45.md
+++ b/45.md
@@ -14,17 +14,17 @@ Some queries a client may want to execute against connected relays are prohibiti

 ## Filters and return values

-This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
+This NIP defines the verb `COUNT`, which accepts a query id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.

 ```
-["COUNT", <subscription_id>, <filters JSON>...]
+["COUNT", <query_id>, <filters JSON>...]
 ```

 Counts are returned using a `COUNT` response in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
 In case a relay uses probabilistic counts, it MAY indicate it in the response with `approximate` key i.e. `{"count": <integer>, "approximate": <true|false>}`.

 ```
-["COUNT", <subscription_id>, {"count": <integer>}]
+["COUNT", <query_id>, {"count": <integer>}]
 ```

 Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST return a `CLOSED` message.
@@ -34,27 +34,27 @@ Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST ret
 ### Followers count

 ```
-["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
-["COUNT", <subscription_id>, {"count": 238}]
+["COUNT", <query_id>, {"kinds": [3], "#p": [<pubkey>]}]
+["COUNT", <query_id>, {"count": 238}]
 ```

 ### Count posts and reactions

 ```
-["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
-["COUNT", <subscription_id>, {"count": 5}]
+["COUNT", <query_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
+["COUNT", <query_id>, {"count": 5}]
 ```

 ### Count posts approximately

 ```
-["COUNT", <subscription_id>, {"kinds": [1]}]
-["COUNT", <subscription_id>, {"count": 93412452, "approximate": true}]
+["COUNT", <query_id>, {"kinds": [1]}]
+["COUNT", <query_id>, {"count": 93412452, "approximate": true}]
 ```

 ### Relay refuses to count

 ```
-["COUNT", <subscription_id>, {"kinds": [4], "authors": [<pubkey>], "#p": [<pubkey>]}]
-["CLOSED", <subscription_id>, "auth-required: cannot count other people's DMs"]
+["COUNT", <query_id>, {"kinds": [1059], "#p": [<pubkey>]}]
+["CLOSED", <query_id>, "auth-required: cannot count other people's DMs"]
 ```
--- a/47.md
+++ b/47.md
@@ -28,15 +28,16 @@ Fundamentally NWC is communication between a **client** and **wallet service** b
 
 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**.
+ 5. The **wallet service** may send encrypted notifications (kind 23197 or 23196) of wallet events (such as a received payment) to the **client**.

 ## Events

 There are four event kinds:
+
 - `NIP-47 info event`: 13194
 - `NIP-47 request`: 23194
 - `NIP-47 response`: 23195
- `NIP-47 notification event`: 23196
+- `NIP-47 notification event`: 23197 (23196 for backwards compatibility with NIP-04)

 ### Info Event

@@ -46,34 +47,71 @@ The content should be a plaintext string with the supported capabilities space-s

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

+It should also contain supported encryption modes as described in the [Encryption](#encryption) section. For example:
+
+```jsonc
+{
+    "kind": 13194,
+    "tags": [
+        ["encryption", "nip44_v2 nip04"], // List of supported encryption schemes as described in the Encryption section.
+        ["notifications", "payment_received payment_sent"]
+        // ...
+    ],
+    "content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions get_info notifications",
+    // ...
+}
+```
+
 ### 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 **client** 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.

-The content of requests and responses is encrypted with [NIP04](04.md), and is a JSON-RPCish object with a semi-fixed structure:
+The content of requests and responses is encrypted with [NIP44](44.md), and is a JSON-RPCish object with a semi-fixed structure.

-Request:
-```jsonc
+**Important note for backwards-compatibility:** The initial version of the protocol used [NIP04](04.md). If a **wallet service** or client app does not include the `encryption` tag in the
+`info` or request events, it should be assumed that the connection is using NIP04 for encryption. See the [Encryption](#encryption) section for more information.
+
+Example request:
+
+```js
 {
-    "method": "pay_invoice", // method, string
-    "params": { // params, object
-        "invoice": "lnbc50n1..." // command-related data
-    }
+    "kind" 23194,
+    "tags": [
+        ["encryption", "nip44_v2"],
+        ["p", "03..." ] // public key of the wallet service.
+        // ...
+    ],
+    "content": nip44_encrypt({ // Encryption type corresponds to the `encryption` tag.
+        "method": "pay_invoice", // method, string
+        "params": { // params, object
+            "invoice": "lnbc50n1..." // command-related data
+        }
+    }),
 }
 ```

-Response:
-```jsonc
+Example response:
+
+```js
 {
-    "result_type": "pay_invoice", //indicates the structure of the result field
-    "error": { //object, non-null in case of error
-        "code": "UNAUTHORIZED", //string error code, see below
-        "message": "human readable error message"
-    },
-    "result": { // result, object. null in case of error.
-        "preimage": "0123456789abcdef..." // command-related data
-    }
+    "kind" 23195,
+    "tags": [
+        ["p", "03..." ] // public key of the requesting client app
+        ["e", "1234"] // id of the request event this is responding to
+        // ...
+    ],
+    "content": nip44_encrypt({ // Encrypted using the scheme requested by the client.
+        "result_type": "pay_invoice", //indicates the structure of the result field
+        "error": { //object, non-null in case of error
+            "code": "UNAUTHORIZED", //string error code, see below
+            "message": "human readable error message"
+        },
+        "result": { // result, object. null in case of error.
+            "preimage": "0123456789abcdef..." // command-related data
+        }
+    })
+    // ...
 }
 ```

@@ -83,9 +121,9 @@ 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 **client**.
+The notification event is a kind 23197 event SHOULD contain one `p` tag, the public key of the **client**.

-The content of notifications is encrypted with [NIP04](04.md), and is a JSON-RPCish object with a semi-fixed structure:
+The content of notifications is encrypted with [NIP44](44.md) (or NIP-04 for legacy client apps), and is a JSON-RPCish object with a semi-fixed structure:

 ```jsonc
 {
@@ -96,6 +134,7 @@ The content of notifications is encrypted with [NIP04](04.md), and is a JSON-RPC
 }
 ```

+_Note on backwards-compatibility:_ If a **wallet service** supports both nip44 and nip04 for legacy client apps, it should publish both notification events for each notification - kind 23196 encrypted with NIP-04, and kind 23197 encrypted with NIP-44. It is up to the **client** to decide which event to listen to based on its supported encryption and declared supported encryption schemes of the **wallet service** in the `info` event.

 ### Error codes
 - `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds.
@@ -105,6 +144,7 @@ The content of notifications is encrypted with [NIP04](04.md), and is a JSON-RPC
 - `RESTRICTED`: This public key is not allowed to do this operation.
 - `UNAUTHORIZED`: This public key has no wallet connected.
 - `INTERNAL`: An internal error.
+- `UNSUPPORTED_ENCRYPTION`: The encryption type of the request is not supported by the wallet service.
 - `OTHER`: Other error.

 ## Nostr Wallet Connect URI
@@ -148,6 +188,7 @@ Request:
    "params": {
        "invoice": "lnbc50n1...", // bolt11 invoice
        "amount": 123, // invoice amount in msats, optional
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc, optional
    }
 }
 ```
@@ -177,7 +218,7 @@ Request:
    "params": {
        "invoices": [
          {"id":"4da52c32a1", "invoice": "lnbc1...", "amount": 123}, // bolt11 invoice and amount in msats, amount is optional
-          {"id":"3da52c32a1", "invoice": "lnbc50n1..."},
+          {"id":"3da52c32a1", "invoice": "lnbc50n1...", "metadata": {} }, // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc, optional
        ],
    }
 }
@@ -284,7 +325,8 @@ Request:
        "amount": 123, // value in msats
        "description": "string", // invoice's description, optional
        "description_hash": "string", // invoice's description hash, optional
-        "expiry": 213 // expiry in seconds from time invoice is created, optional
+        "expiry": 213, // expiry in seconds from time invoice is created, optional
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc, optional
    }
 }
 ```
@@ -295,6 +337,7 @@ Response:
    "result_type": "make_invoice",
    "result": {
        "type": "incoming", // "incoming" for invoices, "outgoing" for payments
+        "state": "pending", // optional
        "invoice": "string", // encoded invoice, optional
        "description": "string", // invoice's description, optional
        "description_hash": "string", // invoice's description hash, optional
@@ -328,6 +371,7 @@ Response:
    "result_type": "lookup_invoice",
    "result": {
        "type": "incoming", // "incoming" for invoices, "outgoing" for payments
+        "state": "pending", // can be "pending", "settled", "expired" (for invoices) or "failed" (for payments), optional
        "invoice": "string", // encoded invoice, optional
        "description": "string", // invoice's description, optional
        "description_hash": "string", // invoice's description hash, optional
@@ -376,6 +420,7 @@ Response:
        "transactions": [
            {
               "type": "incoming", // "incoming" for invoices, "outgoing" for payments
+               "state": "pending", // can be "pending", "settled", "expired" (for invoices) or "failed" (for payments), optional
               "invoice": "string", // encoded invoice, optional
               "description": "string", // invoice's description, optional
               "description_hash": "string", // invoice's description hash, optional
@@ -452,6 +497,7 @@ Notification:
    "notification_type": "payment_received",
    "notification": {
        "type": "incoming",
+        "state": "settled", // optional
        "invoice": "string", // encoded invoice
        "description": "string", // invoice's description, optional
        "description_hash": "string", // invoice's description hash, optional
@@ -477,6 +523,7 @@ Notification:
    "notification_type": "payment_sent",
    "notification": {
        "type": "outgoing",
+        "state": "settled", // optional
        "invoice": "string", // encoded invoice
        "description": "string", // invoice's description, optional
        "description_hash": "string", // invoice's description hash, optional
@@ -499,9 +546,106 @@ Notification:
 2. **wallet service** verifies that the author's key is authorized to perform the payment, decrypts the payload and sends the payment.
 3. **wallet service** responds to the event by sending an event with kind `23195` and content being a response either containing an error message or a preimage.

+## Encryption
+
+The initial version of NWC used [NIP-04](04.md) for encryption which has been deprecated and replaced by [NIP-44](44.md). NIP-44 should always be preferred for encryption, but there may be legacy cases
+where the **wallet service** or **client** has not yet migrated to NIP-44. The **wallet service** and **client** should negotiate the encryption method to use based on the `encryption` tag in the `info` event.
+
+The encryption tag can contain either `nip44_v2` or `nip04`. The absence of this tag implies that the wallet only supports `nip04`.
+
+| Encryption code | Use                  | Notes                                                   |
+|-----------------|----------------------|---------------------------------------------------------|
+| `nip44_v2`      | NIP-44               | Required                                                |
+| `nip04`         | NIP-04               | Deprecated and only here for backward compatibility     |
+| `<not present>` | NIP-04               | Deprecated and only here for backward compatibility     |
+
+The negotiation works as follows.
+
+1. The **wallet service** includes an `encryption` tag in the `info` event. This tag contains a space-separated list of encryption schemes that the **wallet service** supports (eg. `nip44_v2 nip04`)
+2. The **client application** includes an `encryption` tag in each request event. This tag contains the encryption scheme which should be used for the request. The **client application** should always prefer nip44 if supported by the **wallet service**.
+
+### Info event
+
+First, the **wallet service** adds an `encryption` tag to its `info` event containing a space-separated list of encryption schemes it supports. For example,
+if a wallet service supports nip44, but also allows backwards-compatibility to nip04 client applications, its `encryption` tag in the `info` event might look something like:
+
+```jsonc
+{
+    "kind": 13194,
+    "tags": [
+        ["encryption", "nip44_v2 nip04"],
+        // ...
+    ],
+    "content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions get_info",
+    // ...
+}
+```
+
+When a **client application** establishes a connection, it should read the info event and look for the `encryption` tag.
+
+**Absence of this tag implies that the wallet only supports nip04.**
+
+If the `encryption` tag is present, the **client application** will choose optimal encryption supported by both itself, and the **wallet service**, which should always be nip44 if possible.
+
+### Request events
+
+When a **client application** sends a request event, it should include a `encryption` tag with the encryption scheme it is using. The scheme MUST be supported by the **wallet service** as indicated by the info event.
+For example, if the client application supports nip44, the request event might look like:
+
+```jsonc
+{
+    "kind": 23194,
+    "tags": [
+        ["encryption", "nip44_v2"],
+        // ...
+    ],
+    // ...
+}
+```
+
+If the **wallet service** does not support the specified encryption scheme, it will return an `UNSUPPORTED_ENCRYPTION` error. Absence of the `encryption` tag indicates use of nip04 for encryption.
+
+### Notification events
+
+As described above in the [Notifications](#notifications) section, if a **wallet service** supports both nip04 and nip44, it should publish two notification events for each notification - kind 23196 encrypted with NIP-04, and kind 23197 encrypted with NIP-44. If the **wallet service** only supports nip44, it should only publish kind 23197 events.
+
+The **client** should check the `encryption` tag in the `info` event to determine which encryption schemes the **wallet service** supports, and listen to the appropriate notification event.
+
 ## 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.

+## Metadata
+Metadata MAY be stored by the **wallet service** alongside invoices and payments. The metadata MUST be no more than 4096 characters, otherwise MUST be dropped. This is to ensure transactions do not get too large to be relayed.
+
+NWC relays SHOULD allow at least a payload size of 64KB and **clients** SHOULD fetch small page sizes (maximum of 20 transactions per page) otherwise there is risk of `list_transactions` responses being rejected.
+
+Here are some properties that are recognized by some NWC clients:
+
+```jsonc
+{
+  "comment": "string", // LUD-12 comment
+  "payer_data": {
+    "email": "string",
+    "name": "string",
+    "pubkey": "string",
+  }, // LUD-18 payer data
+  "recipient_data": {
+    "identifier": "string"
+  }, // similar to LUD-18 payer data, but to record recipient data e.g. the lightning address of the recipient
+  "nostr": {
+    "pubkey": "string",
+    "tags": [],
+    // ... rest of zap request event
+  }, // NIP-57 Zap Request event (kind 9734)
+  "tlv_records": [
+    {
+      "type": 5482373484, // tlv type
+      "value": "0123456789abcdef" // hex encoded tlv value
+    }
+  ] // keysend TLV records (e.g. for podcasting 2.0 boostagrams)
+} & Record<string, unknown>;
+```
+
 ## Appendix

 ### Example NIP-47 info event
@@ -513,6 +657,7 @@ This NIP does not specify any requirements on the type of relays used. However,
  "created_at": 1713883677,
  "kind": 13194,
  "tags": [
+    [ "encryption", "nip44_v2 nip04" ],
    [
      "notifications",
      "payment_received payment_sent"
@@ -522,3 +667,21 @@ This NIP does not specify any requirements on the type of relays used. However,
  "sig": "31f57b369459b5306a5353aa9e03be7fbde169bc881c3233625605dd12f53548179def16b9fe1137e6465d7e4d5bb27ce81fd6e75908c46b06269f4233c845d8"
 }
 ```
+
+### Deep-links
+
+Wallet applications can register deeplinks in mobile systems to make it possible to create a linking UX that doesn't require the user scanning a QR code or pasting some code.
+
+`nostrnwc://connect` and `nostrnwc+{app_name}://connect` can be registered by wallet apps and queried by apps that want to receive an NWC pairing code.
+
+All URI parameters, MUST be URI-encoded.
+
+URI parameters:
+ * `appicon` -- URL to an icon of the client that wants to create a connection.
+ * `appname` -- Name of the client that wants to create a connection.
+ * `callback` -- URI schema the wallet should open with the connection string
+
+Once a connection has been created by the wallet, it should be returned to the client by opening the callback with the following parameters
+ * `value` -- NWC pairing code (e.g. `nostr+walletconnect://...`)
+
+
--- a/51.md
+++ b/51.md
@@ -8,7 +8,7 @@ Lists

 This NIP defines lists of things that users can create. Lists can contain references to anything, and these references can be **public** or **private**.

-Public items in a list are specified in the event `tags` array, while private items are specified in a JSON array that mimics the structure of the event `tags` array, but stringified and encrypted using the same scheme from [NIP-04](04.md) (the shared key is computed using the author's public and private key) and stored in the `.content`.
+Public items in a list are specified in the event `tags` array, while private items are specified in a JSON array that mimics the structure of the event `tags` array, but stringified and encrypted using the same scheme from [NIP-44](44.md) (the shared key is computed using the author's public and private key) and stored in the `.content`. An earlier version of this specification used [NIP-04](04.md) for encryptions. Those are now deprecated. For backward compatibility, Clients can automatically discover if the encryption is NIP-04 or NIP-44 by searching for "iv" in the ciphertext and decrypting accordingly.

 When new items are added to an existing list, clients SHOULD append them to the end of the list, so they are stored in chronological order.

@@ -26,7 +26,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | 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)                                                                                 |
-| Bookmarks         | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs)                   |
+| Bookmarks         | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles)                   |
 | Communities       | 10004 | [NIP-72](72.md) communities the user belongs to             | `"a"` (kind:34550 community definitions)                                                            |
 | 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)                                                                              |
@@ -52,9 +52,9 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
 | ---                   | ---   | ---                                                                                          | ---                                                                                 |
 | 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)   |
+| Bookmark sets         | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups    | `"e"` (kind:1 notes), `"a"` (kind:30023 articles)                                   |
 | 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:21 videos)                                                              |
+| Curation sets         | 30005 | groups of videos picked by users as interesting and/or belonging to the same category        | `"e"` (kind:21 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))                                                     |
@@ -165,6 +165,6 @@ val private_items = [
  ["p", "07caba282f76441955b695551c3c5c742e5b9202a3784780f8086fdcdc1da3a9"],
  ["a", "a55c15f5e41d5aebd236eca5e0142789c5385703f1a7485aa4b38d94fd18dcc4"],
 ]
-val base64blob = nip04.encrypt(json.encode_to_string(private_items))
+val base64blob = nip44.encrypt(json.encode_to_string(private_items))
 event.content = base64blob
 ```
--- a/52.md
+++ b/52.md
@@ -25,6 +25,7 @@ These tags are common to both types of calendar events:
 * `p` (optional, repeated) 32-bytes hex pubkey of a participant, optional recommended relay URL, and participant's role in the meeting
 * `t` (optional, repeated) hashtag to categorize calendar event
 * `r` (optional, repeated) references / links to web pages, documents, video calls, recorded videos, etc.
+* `a` (repeated) reference tag to kind `31924` calendar event requesting to be included in Calendar

 The following tags are deprecated:

@@ -32,6 +33,12 @@ The following tags are deprecated:

 Calendar events are _not_ required to be part of a [calendar](#calendar).

+## Collaborative Calendar Event Requests
+
+Calendar events can include an `a` tag referencing a calendar (kind 31924) to request addition to that calendar. When a calendar event includes such a reference, clients should interpret this as a request to add the event to the referenced calendar by referencing it with an `a` tag.
+
+This enables collaborative calendar management where multiple users can contribute events to calendars they do not own, subject to the calendar owner's approval.
+
 ### Date-Based Calendar Event

 This kind of calendar event starts on a date and ends before a different date in the future. Its use is appropriate for all-day or multi-day events where time and time zone hold no significance. e.g., anniversary, public holidays, vacation days.
@@ -125,6 +132,8 @@ Aside from the common tags, this also takes the following tags:

 A calendar is a collection of calendar events, represented as a custom _addressable list_ event using kind `31924`. A user can have multiple calendars. One may create a calendar to segment calendar events for specific purposes. e.g., personal, work, travel, meetups, and conferences.

+Calendars can accept event requests from other users. When calendar events reference a calendar via an `a` tag, this represents a request for inclusion.
+
 The `.content` of these events should be a detailed description of the calendar. It is required but can be an empty string.

 * `d` (required) universally unique identifier. Generated by the client creating the calendar.
--- a/53.md
+++ b/53.md
@@ -6,13 +6,13 @@ Live Activities

 `draft` `optional`

-Service providers want to offer live activities to the Nostr network in such a way that participants can easily log and query by clients. This NIP describes a general framework to advertise the involvement of pubkeys in such live activities.
+This NIP introduces event kinds to advertise live spaces and the participation of pubkeys in them.

-## Concepts
+## Live Streaming

-### Live Event
+A special event with `kind:30311` "Live Streaming Event" is defined as an _addressable event_ whose tags advertise the content and participants of a live stream.

-A special event with `kind:30311` "Live Event" is defined as an _addressable event_ of public `p` tags. Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity.
+Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity.

 For example:

@@ -63,13 +63,13 @@ 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. An `e` tag denotes the direct parent message this post is replying to. 
+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
 {
  "kind": 1311,
  "tags": [
-    ["a", "30311:<Community event author pubkey>:<d-identifier of the community>", "<Optional relay url>", "root"],
+    ["a", "30311:<Community event author pubkey>:<d-identifier of the community>", "<Optional relay url>"],
  ],
  "content": "Zaps to live streams is beautiful.",
  // other fields...
@@ -84,13 +84,9 @@ Event `kind:1311` is live chat's channel message. Clients MUST include the `a` t

 Hosts may choose to pin one or more live chat messages by updating the `pinned` tags in the live event kind `30311`.

-## Use Cases
+### Examples

-Common use cases include meeting rooms/workshops, watch-together activities, or event spaces, such as [zap.stream](https://zap.stream).
-
-## Example
-
-### Live Streaming
+#### Live Streaming

 ```json
 {
@@ -114,7 +110,7 @@ Common use cases include meeting rooms/workshops, watch-together activities, or
 }
 ```

-### Live Streaming chat message
+#### Live Streaming chat message

 ```json
 {
@@ -130,18 +126,13 @@ Common use cases include meeting rooms/workshops, watch-together activities, or
 }
 ```

-## Interactive Rooms and Meetings
-----
+## Meeting Spaces

-`draft` `optional`
+Meeting spaces contain one or more video/audio rooms where users can join and participate in the streaming.

-Service providers want to offer Interactive Rooms to the Nostr network in such a way that participants can easily log and query by clients. This NIP describes a general framework to advertise rooms and their associated events.
+### Meeting Space Event (kind:30312)

-## Concepts
-
-### Interactive Room (kind:30312)
-
-A special event with `kind:30312` "Interactive Room" defines the configuration and properties of a virtual interactive space. Each room has a unique identifier and can host multiple events/meetings.
+A special event with `kind:30312` "Space Host" defines the configuration and properties of a virtual interactive space. Each space has a unique identifier and can host multiple events/meetings.

 ```jsonc
 {
@@ -162,19 +153,20 @@ A special event with `kind:30312` "Interactive Room" defines the configuration a
 }
 ```

-Room properties:
+Space properties:
 * MUST be either open, private or closed. Closed means the room is not in operation.
 * MAY specify access control policy for private rooms (e.g. invite-only, payment required)
 * MAY persist when not in use
 * MUST have at least one provider with "Host" role
 * MAY have multiple providers with different roles
+
 Provider roles (p tags):
 * Host: Full room management capabilities
 * Moderator: Room moderation capabilities
 * Speaker: Allowed to present/speak
 * Optional proof field for role verification

-### Room Meeting (kind:30313)
+### Meeting Room Events (kind:30313)

 A special event with kind:30313 represents a scheduled or ongoing meeting within a room. It MUST reference its parent room using the d tag.

@@ -183,7 +175,7 @@ A special event with kind:30313 represents a scheduled or ongoing meeting within
  "kind": 30313,
  "tags": [
    ["d", "<event-unique-identifier>"],        // Required: Event identifier
-    ["a", "30312:<pubkey>:<room-id>", "wss://nostr.example.com"], // Required: Reference to parent room, 'd' from 30312
+    ["a", "30312:<pubkey>:<room-id>", "wss://nostr.example.com"], // Required: Reference to parent space, 'd' from 30312
    ["title", "<meeting-title>"],              // Required: Meeting title
    ["summary", "<description>"],              // Optional: Meeting description
    ["image", "<preview image url>"],          // Optional: Meeting image
@@ -204,14 +196,15 @@ Event properties:
 * MUST have a start time
 * MAY track participant counts
 * MAY include participant roles specific to the event
+
 Event management:
 * Clients SHOULD update event status regularly when live
 * Events without updates for 1 hour MAY be considered ended
 * starts and ends timestamps SHOULD be updated when status changes

-Examples
+### Examples

-Interactive Room (kind:30312)
+#### Meeting Space (kind:30312)

 ```jsonc
 {
@@ -233,7 +226,7 @@ Interactive Room (kind:30312)
 }
 ```

-Conference Event (kind:30313)
+#### Meeting room (kind:30313)

 ```jsonc
 {
@@ -254,11 +247,11 @@ Conference Event (kind:30313)
  "content": ""
 }
 ```
-## Room Presence
+### Room Presence

-New `kind: 10312` provides an event which signals presence of a listener. 
+New `kind: 10312` provides an event which signals presence of a listener.

-The presence event SHOULD be updated at regular intervals and clients SHOULD filter presence events older than 
+The presence event SHOULD be updated at regular intervals and clients SHOULD filter presence events older than
 a given time window.

 **This kind `10312` is a regular replaceable event, as such presence can only be indicated in one room at a time.**
--- a/54.md
+++ b/54.md
@@ -10,7 +10,7 @@ This NIP defines `kind:30818` (an _addressable event_) for descriptions (or ency

 Articles are identified by lowercase, normalized ascii `d` tags.

-### Articles
+## Articles
 ```json
 {
  "content": "A wiki is a hypertext publication collaboratively edited and managed by its own audience.",
@@ -21,12 +21,12 @@ Articles are identified by lowercase, normalized ascii `d` tags.
 }
 ```

-### `d` tag normalization rules
+## `d` tag normalization rules

 - Any non-letter character MUST be converted to a `-`.
 - All letters MUST be converted to lowercase.

-### Content
+## Content

 The `content` should be Asciidoc with two extra functionalities: **wikilinks** and **nostr:...** links.

@@ -39,26 +39,25 @@ Wikilinks can take these two forms:

 `nostr:...` links, as per [NIP-21](21.md), should link to profiles or arbitrary Nostr events. Although it is not recommended to link to specific versions of articles -- instead the _wikilink_ syntax should be preferred, since it should be left to the reader and their client to decide what version of any given article they want to read.

-### Optional extra tags
+## Optional extra tags

  - `title`: for when the display title should be different from the `d` tag.
  - `summary`: for display in lists.
  - `a` and `e`: for referencing the original event a wiki article was forked from.

-### Merge Requests
+## Merge Requests

 Event `kind:818` represents a request to merge from a forked article into the source. It is directed to a pubkey and references the original article and the modified event.

 [INSERT EVENT EXAMPLE]

-### Redirects
+## Redirects

 Event `kind:30819` is also defined to stand for "wiki redirects", i.e. if one thinks `Shell structure` should redirect to `Thin-shell structure` they can issue one of these events instead of replicating the content. These events can be used for automatically redirecting between articles on a client, but also for generating crowdsourced "disambiguation" pages ([common in Wikipedia](https://en.wikipedia.org/wiki/Help:Disambiguation)).

 [INSERT EVENT EXAMPLE]

-How to decide what article to display
-------------------------------------
+## How to decide what article to display

 As there could be many articles for each given name, some kind of prioritization must be done by clients. Criteria for this should vary between users and clients, but some means that can be used are described below:

@@ -78,26 +77,23 @@ As there could be many articles for each given name, some kind of prioritization

 [NIP-51](51.md) lists can also be used to create a list of users that are trusted only in the context of wiki authorship or wiki curationship.

-Forks
---------
+## Forks
 Wiki-events can tag other wiki-events with a `fork` marker to specify that this event came from a different version. Both `a` and `e` tags SHOULD be used and have the `fork` marker applied, to identify the exact version it was forked from.

-Deference
---------
+## Deference
 Wiki-events can tag other wiki-events with a `defer` marker to indicate that it considers someone else's entry as a "better" version of itself. If using a `defer` marker both `a` and `e` tags SHOULD be used.

 This is a stronger signal of trust than a `+` reaction.

 This marker is useful when a user edits someone else's entry; if the original author includes the editor's changes and the editor doesn't want to keep/maintain an independent version, the `link` tag could effectively be a considered a "deletion" of the editor's version and putting that pubkey's WoT weight behind the original author's version.

-Why Asciidoc?
-------------
+## Why Asciidoc?

 Wikitext is [garbage](nostr:nevent1qqsqt0gcggry60n72uglhuhypdlmr2dm6swjj69jex5v530gcpazlzsprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5ueneex) and Markdown is not powerful enough (besides being too freeform and unspecified and prone to generate incompatibilities in the future).

 Asciidoc has a strict spec, multiple implementations in many languages, and support for features that are very much necessary in a wiki article, like _sidebars_, _tables_ (with rich markup inside cells), many levels of _headings_, _footnotes_, _superscript_ and _subscript_ markup and _description lists_. It is also arguably easier to read in its plaintext format than Markdown (and certainly much better than Wikitext).

-# Appendix 1: Merge requests
+## Appendix 1: Merge requests
 Users can request other users to get their entries merged into someone else's entry by creating a `kind:818` event.

 ```json
--- a/55.md
+++ b/55.md
@@ -8,7 +8,7 @@ Android Signer Application

 This NIP describes a method for 2-way communication between an Android signer and any Nostr client on Android. The Android signer is an Android Application and the client can be a web client or an Android application.

-# Usage for Android applications
+## Usage for Android applications

 The Android signer uses Intents (to accept/reject permissions manually) and Content Resolvers (to accept/reject permissions automatically in background if the user allowed it) to communicate between applications.

@@ -38,7 +38,7 @@ fun isExternalSignerInstalled(context: Context): Boolean {
 }
 ```

-## Using Intents
+### Using Intents

 To get the result back from the Signer Application you should use `registerForActivityResult` or `rememberLauncherForActivityResult` in Kotlin. If you are using another framework check the documentation of your framework or a third party library to get the result.

@@ -91,7 +91,7 @@ Signer MUST answer multiple permissions with an array of results
 val results = listOf(
  Result(
    package = signerPackageName,
-    result = eventSignture,
+    result = eventSignature,
    id = intentId
  )
 )
@@ -107,7 +107,7 @@ Send the Intent:
 launcher.launch(intent)
 ```

-### Methods
+#### Methods

 - **get_public_key**
  - params:
@@ -283,7 +283,7 @@ launcher.launch(intent)
      val id = intent.data?.getStringExtra("id")
      ```

-## Using Content Resolver
+### Using Content Resolver

 To get the result back from Signer Application you should use contentResolver.query in Kotlin. If you are using another framework check the documentation of your framework or a third party library to get the result.

@@ -295,7 +295,9 @@ For the other types Signer Application returns the column "result"

 If the user chose to always reject the event, signer application will return the column "rejected" and you should not open signer application

-### Methods
+Clients SHOULD save the user pubkey locally and avoid calling the `get_public_key` after the user is logged in to the Client
+
+#### Methods

 - **get_public_key**
  - params:
@@ -303,7 +305,7 @@ If the user chose to always reject the event, signer application will return the
    ```kotlin
    val result = context.contentResolver.query(
        Uri.parse("content://com.example.signer.GET_PUBLIC_KEY"),
-        listOf("login"),
+        listOf(hex_pub_key),
        null,
        null,
        null
@@ -482,7 +484,7 @@ If the user chose to always reject the event, signer application will return the
        }
      ```

-# Usage for Web Applications
+## 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.

@@ -496,7 +498,7 @@ You can configure the `returnType` to be **signature** or **event**.

 Android intents and browser urls have limitations, so if you are using the `returnType` of **event** consider using the parameter **compressionType=gzip** that will return "Signer1" + Base64 gzip encoded event json

-## Methods
+### Methods

 - **get_public_key**
  - params:
@@ -547,7 +549,7 @@ Android intents and browser urls have limitations, so if you are using the `retu
    window.href = `nostrsigner:${eventJson}?compressionType=none&returnType=signature&type=decrypt_zap_event&callbackUrl=https://example.com/?event=`;
    ```

-## Example
+### Example

 ```js
 <!DOCTYPE html>
--- a/57.md
+++ b/57.md
@@ -12,7 +12,7 @@ Having lightning receipts on nostr allows clients to display lightning payments

 ## Protocol flow

-1. Client calculates a recipient's lnurl pay request url from the `zap` tag on the event being zapped (see Appendix G), or by decoding their lud06 or lud16 field on their profile according to the [lnurl specifications](https://github.com/lnurl/luds). The client MUST send a GET request to this url and parse the response. If `allowsNostr` exists and it is `true`, and if `nostrPubkey` exists and is a valid BIP 340 public key in hex, the client should associate this information with the user, along with the response's `callback`, `minSendable`, and `maxSendable` values.
+1. Client calculates a recipient's lnurl pay request url from the `zap` tag on the event being zapped (see Appendix G), or by decoding their lud16 field on their profile according to the [lnurl specifications](https://github.com/lnurl/luds). The client MUST send a GET request to this url and parse the response. If `allowsNostr` exists and it is `true`, and if `nostrPubkey` exists and is a valid BIP 340 public key in hex, the client should associate this information with the user, along with the response's `callback`, `minSendable`, and `maxSendable` values.
 2. Clients may choose to display a lightning zap button on each post or on a user's profile. If the user's lnurl pay request endpoint supports nostr, the client SHOULD use this NIP to request a `zap receipt` rather than a normal lnurl invoice.
 3. When a user (the "sender") indicates they want to send a zap to another user (the "recipient"), the client should create a `zap request` event as described in Appendix A of this NIP and sign it.
 4. Instead of publishing the `zap request`, the `9734` event should instead be sent to the `callback` url received from the lnurl pay endpoint for the recipient using a GET request. See Appendix B for details and an example.
@@ -37,6 +37,7 @@ In addition, the event MAY include the following tags:

 - `e` is an optional hex-encoded event id. Clients MUST include this if zapping an event rather than a person.
 - `a` is an optional event coordinate that allows tipping addressable events such as NIP-23 long-form notes.
+- `k` is the stringified kind of the target event.

 Example:

@@ -49,7 +50,8 @@ Example:
    ["amount", "21000"],
    ["lnurl", "lnurl1dp68gurn8ghj7um5v93kketj9ehx2amn9uh8wetvdskkkmn0wahz7mrww4excup0dajx2mrv92x9xp"],
    ["p", "04c915daefee38317fa734444acee390a8269fe5810b2241e5e6dd343dfbecc9"],
-    ["e", "9ae37aa68f48645127299e9453eb5d908a0cbb6058ff340d528ed4d37c8994fb"]
+    ["e", "9ae37aa68f48645127299e9453eb5d908a0cbb6058ff340d528ed4d37c8994fb"],
+    ["k", "1"]
  ],
  "pubkey": "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322",
  "created_at": 1679673265,
@@ -151,6 +153,7 @@ Example `zap receipt`:
      ["p", "32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245"],
      ["P", "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"],
      ["e", "3624762a1274dd9636e0c552b53086d70bc88c165bc4dc0f9e836a1eaf86c3b8"],
+      ["k", "1"],
      ["bolt11", "lnbc10u1p3unwfusp5t9r3yymhpfqculx78u027lxspgxcr2n2987mx2j55nnfs95nxnzqpp5jmrh92pfld78spqs78v9euf2385t83uvpwk9ldrlvf6ch7tpascqhp5zvkrmemgth3tufcvflmzjzfvjt023nazlhljz2n9hattj4f8jq8qxqyjw5qcqpjrzjqtc4fc44feggv7065fqe5m4ytjarg3repr5j9el35xhmtfexc42yczarjuqqfzqqqqqqqqlgqqqqqqgq9q9qxpqysgq079nkq507a5tw7xgttmj4u990j7wfggtrasah5gd4ywfr2pjcn29383tphp4t48gquelz9z78p4cq7ml3nrrphw5w6eckhjwmhezhnqpy6gyf0"],
      ["description", "{\"pubkey\":\"97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322\",\"content\":\"\",\"id\":\"d9cc14d50fcb8c27539aacf776882942c1a11ea4472f8cdec1dea82fab66279d\",\"created_at\":1674164539,\"sig\":\"77127f636577e9029276be060332ea565deaf89ff215a494ccff16ae3f757065e2bc59b2e8c113dd407917a010b3abd36c8d7ad84c0e3ab7dab3a0b0caa9835d\",\"kind\":9734,\"tags\":[[\"e\",\"3624762a1274dd9636e0c552b53086d70bc88c165bc4dc0f9e836a1eaf86c3b8\"],[\"p\",\"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245\"],[\"relays\",\"wss://relay.damus.io\",\"wss://nostr-relay.wlvs.space\",\"wss://nostr.fmt.wiz.biz\",\"wss://relay.nostr.bg\",\"wss://nostr.oxtr.dev\",\"wss://nostr.v0l.io\",\"wss://brb.io\",\"wss://nostr.bitcoiner.social\",\"ws://monad.jb55.com:8080\",\"wss://relay.snort.social\"]]}"],
      ["preimage", "5d006d2cf1e73c7148e7519a4c68adc81642ce0e25a432b2434c99f97344c15f"]
--- a/59.md
+++ b/59.md
@@ -13,7 +13,7 @@ This NIP *does not* define any messaging protocol. Applications of this NIP shou

 This NIP relies on [NIP-44](./44.md)'s versioned encryption algorithms.

-# Overview
+## Overview

 This protocol uses three main concepts to protect the transmission of a target event: `rumor`s, `seal`s, and `gift wrap`s.

@@ -29,13 +29,13 @@ This allows the isolation of concerns across layers:
 - A seal identifies the author without revealing the content or the recipient.
 - A gift wrap can add metadata (recipient, tags, a different author) without revealing the true author.

-# Protocol Description
+## Protocol Description

-## 1. The Rumor Event Kind
+### 1. The Rumor Event Kind

 A `rumor` is the same thing as an unsigned event. Any event kind can be made a `rumor` by removing the signature.

-## 2. The Seal Event Kind
+### 2. The Seal Event Kind

 A `seal` is a `kind:13` event that wraps a `rumor` with the sender's regular key. The `seal` is **always** encrypted
 to a receiver's pubkey but there is no `p` tag pointing to the receiver. There is no way to know who the rumor is for
@@ -55,7 +55,7 @@ without the receiver's or the sender's private key. The only public information

 Tags MUST always be empty in a `kind:13`. The inner event MUST always be unsigned.

-## 3. Gift Wrap Event Kind
+### 3. Gift Wrap Event Kind

 A `gift wrap` event is a `kind:1059` event that wraps any other event. `tags` SHOULD include any information
 needed to route the event to its intended recipient, including the recipient's `p` tag or [NIP-13](13.md) proof of work.
@@ -72,12 +72,12 @@ needed to route the event to its intended recipient, including the recipient's `
 }
 ```

-# Encrypting Payloads
+## Encrypting Payloads

 Encryption is done following [NIP-44](44.md) on the JSON-encoded event. Place the encryption payload in the `.content`
 of the wrapper event (either a `seal` or a `gift wrap`).

-# Other Considerations
+## Other Considerations

 If a `rumor` is intended for more than one party, or if the author wants to retain an encrypted copy, a single
 `rumor` may be wrapped and addressed for each recipient individually.
@@ -97,7 +97,12 @@ To protect recipient metadata, relays SHOULD only serve `kind 1059` events inten
 When possible, clients should only send wrapped events to `read` relays for the recipient that implement
 AUTH, and refuse to serve wrapped events to non-recipients.

-# An Example
+When adding expiration tags to both `seal` and `gift wrap` layers, implementations SHOULD use independent random timestamps for each layer. Using different `created_at` values increases timing variance and helps protect against metadata correlation attacks.
+
+Since signing keys are random, relays SHOULD delete `kind 1059` events whose p-tag matches the signer of
+[NIP-09](09.md) deletions or [NIP-62](62.md) vanish requests.
+
+## An Example

 Let's send a wrapped `kind 1` message between two parties asking "Are you going to the party tonight?"

@@ -108,7 +113,7 @@ Let's send a wrapped `kind 1` message between two parties asking "Are you going
 Note that this messaging protocol should not be used in practice, this is just an example. Refer to other
 NIPs for concrete messaging protocols that depend on gift wraps.

-## 1. Create an event
+### 1. Create an event

 Create a `kind 1` event with the message, the receivers, and any other tags you want, signed by the author.
 Do not sign the event.
@@ -124,7 +129,7 @@ Do not sign the event.
 }
 ```

-## 2. Seal the rumor
+### 2. Seal the rumor

 Encrypt the JSON-encoded `rumor` with a conversation key derived using the author's private key and
 the recipient's public key. Place the result in the `content` field of a `kind 13` `seal` event. Sign
@@ -142,7 +147,7 @@ it with the author's key.
 }
 ```

-## 3. Wrap the seal
+### 3. Wrap the seal

 Encrypt the JSON-encoded `kind 13` event with your ephemeral, single-use random key. Place the result
 in the `content` field of a `kind 1059`. Add a single `p` tag containing the recipient's public key.
@@ -160,13 +165,13 @@ Sign the `gift wrap` using the random key generated in the previous step.
 }
 ```

-## 4. Broadcast Selectively
+### 4. Broadcast Selectively

 Broadcast the `kind 1059` event to the recipient's relays only. Delete all the other events.

-# Code Samples
+## Code Samples

-## JavaScript
+### JavaScript

 ```javascript
 import {bytesToHex} from "@noble/hashes/utils"
--- a/60.md
+++ b/60.md
@@ -16,13 +16,13 @@ The purpose of this NIP is:

 This NIP doesn't deal with users' *receiving* money from someone else, it's just to keep state of the user's wallet.

-# High-level flow
+## High-level flow
 1. A user has a `kind:17375` event that represents a wallet.
 2. A user has `kind:7375` events that represent the unspent proofs of the wallet. -- The proofs are encrypted with the user's private key.
 3. A user has `kind:7376` events that represent the spending history of the wallet -- This history is for informational purposes only and is completely optional.

-## Wallet Event
-```jsonc
+### Wallet Event
+```javascript
 {
    "kind": 17375,
    "content": nip44_encrypt([
@@ -40,16 +40,17 @@ Tags:
 * `mint` - Mint(s) this wallet uses -- there MUST be one or more mint tags.
 * `privkey` - Private key used to unlock P2PK ecash. MUST be stored encrypted in the `.content` field. **This is a different private key exclusively used for the wallet, not associated in any way to the user's Nostr private key** -- This is only used for receiving [NIP-61](61.md) nutzaps.

-## Token Event
+### Token Event
 Token events are used to record unspent proofs.

 There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event.

-```jsonc
+```javascript
 {
    "kind": 7375,
    "content": nip44_encrypt({
        "mint": "https://stablenut.umint.cash",
+        "unit": "sat",
        "proofs": [
            // one or more proofs in the default cashu format
            {
@@ -69,21 +70,23 @@ 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`: unencoded proofs
+   * `unit` the base unit the proofs are denominated in (eg: `sat`, `usd`, `eur`). Default: `sat` if omitted.
   * `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).

 The `kind:5` _delete event_ created in the [NIP-09](09.md) process MUST have a tag `["k", "7375"]` to allow easy filtering by clients interested in state transitions.

-## Spending History Event
+### Spending History Event
 Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes.

-```jsonc
+```javascript
 {
    "kind": 7376,
    "content": nip44_encrypt([
        [ "direction", "in" ], // in = received, out = sent
        [ "amount", "1" ],
+        [ "unit", "sat" ],
        [ "e", "<event-id-of-created-token>", "", "created" ]
    ]),
    "tags": [
@@ -93,6 +96,7 @@ Clients SHOULD publish `kind:7376` events to create a transaction history when t
 ```

 * `direction` - The direction of the transaction; `in` for received funds, `out` for sent funds.
+* `unit` the base unit of the amount (eg: `sat`, `usd`, `eur`). Default: `sat` if omitted.

 Clients MUST add `e` tags to create references of destroyed and created token events along with the marker of the meaning of the tag:
 * `created` - A new token event was created.
@@ -103,24 +107,25 @@ All tags can be [NIP-44](44.md) encrypted. Clients SHOULD leave `e` tags with a

 Multiple `e` tags can be added, and should be encrypted, except for tags with the `redeemed` marker.

-# Flow
+## Flow
 A client that wants to check for user's wallets information starts by fetching `kind:10019` events from the user's relays, if no event is found, it should fall back to using the user's [NIP-65](65.md) relays.

-## Fetch wallet and token list
+### Fetch wallet and token list
 From those relays, the client should fetch wallet and token events.

 `"kinds": [17375, 7375], "authors": ["<my-pubkey>"]`

-## Fetch proofs
+### Fetch proofs

-## Spending token
+### Spending token
 If Alice spends 4 sats from this token event
-```jsonc
+```javascript
 {
    "kind": 7375,
    "id": "event-id-1",
    "content": nip44_encrypt({
        "mint": "https://stablenut.umint.cash",
+        "unit": "sat",
        "proofs": [
            { "id": "1", "amount": 1 },
            { "id": "2", "amount": 2 },
@@ -134,12 +139,13 @@ If Alice spends 4 sats from this token event

 Her client:
 * MUST roll over the unspent proofs:
-```jsonc
+```javascript
 {
    "kind": 7375,
    "id": "event-id-2",
    "content": nip44_encrypt({
        "mint": "https://stablenut.umint.cash",
+        "unit": "sat",
        "proofs": [
            { "id": "1", "amount": 1 },
            { "id": "2", "amount": 2 },
@@ -153,12 +159,13 @@ Her client:
 * MUST delete event `event-id-1`
 * SHOULD add the `event-id-1` to the `del` array of deleted token-ids.
 * SHOULD create a `kind:7376` event to record the spend
-```jsonc
+```javascript
 {
    "kind": 7376,
    "content": nip44_encrypt([
        [ "direction", "out" ],
        [ "amount", "4" ],
+        [ "unit", "sat" ],
        [ "e", "<event-id-1>", "", "destroyed" ],
        [ "e", "<event-id-2>", "", "created" ],
    ]),
@@ -166,12 +173,12 @@ Her client:
 }
 ```

-## Redeeming a quote (optional)
+### Redeeming a quote (optional)
 When creating a quote at a mint, an event can be used to keep the state of the quote ID, which will be used to check when the quote has been paid. These events should be created with an expiration tag [NIP-40](40.md) of 2 weeks (which is around the maximum amount of time a Lightning payment may be in-flight).

 However, application developers SHOULD use local state when possible and only publish this event when it makes sense in the context of their application.

-```jsonc
+```javascript
 {
    "kind": 7374,
    "content": nip44_encrypt("quote-id"),
--- a/61.md
+++ b/61.md
@@ -8,19 +8,19 @@ Nutzaps

 A Nutzap is a P2PK Cashu token in which the payment itself is the receipt.

-# High-level flow
+## High-level flow
 Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.

-## Alice nutzaps Bob
+### Alice nutzaps Bob
 1. Alice fetches event `kind:10019` from Bob to see the mints Bob trusts.
 2. She mints a token at that mint (or swaps some tokens she already had in that mint) P2PK-locked to the pubkey Bob has listed in his `kind:10019`.
 3. She publishes a `kind:9321` event to the relays Bob indicated with the proofs she minted.

-## Bob receives the nutzap
+### Bob receives the nutzap
 1. At some point, Bob's client fetches `kind:9321` events p-tagging him from his relays.
 2. Bob's client swaps the token into his wallet.

-# Nutzap informational event
+## Nutzap informational event
 ```jsonc
 {
    "kind": 10019,
@@ -39,7 +39,7 @@ Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
 * `mint`: mints the user is explicitly agreeing to use to receive funds on. Clients SHOULD not send money on mints not listed here or risk burning their money. Additional markers can be used to list the supported base units of the mint.
 * `pubkey`: Public key that MUST be used to P2PK-lock receiving nutzaps -- implementations MUST NOT use the target user's main Nostr public key. This public key corresponds to the `privkey` field encrypted in a user's [nip-60](60.md) _wallet event_.

-## Nutzap event
+### Nutzap event
 Event `kind:9321` is a nutzap event published by the sender, p-tagging the recipient. The outputs are P2PK-locked to the public key the recipient indicated in their `kind:10019` event.

 Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu compatibility).
@@ -51,8 +51,10 @@ Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu
    "pubkey": "<sender-pubkey>",
    "tags": [
        [ "proof", "{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}" ],
+        [ "unit", "sat" ],
        [ "u", "https://stablenut.umint.cash" ],
        [ "e", "<nutzapped-event-id>", "<relay-hint>" ],
+        [ "k", "<nutzapped-kind>"],
        [ "p", "e9fbced3a42dcf551486650cc752ab354347dd413b307484e4fd1818ab53f991" ], // recipient of nutzap
    ]
 }
@@ -61,29 +63,30 @@ Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu
 * `.content` is an optional comment for the nutzap
 * `.tags`:
  * `proof` is one or more proofs P2PK-locked to the public key the recipient specified in their `kind:10019` event and including a DLEQ proof.
+  * `unit` the base unit the proofs are denominated in (eg: `sat`, `usd`, `eur`). Default: `sat` if omitted.
  * `u` is the mint the URL of the mint EXACTLY as specified by the recipient's `kind:10019`.
  * `p` is the Nostr identity public key of nutzap recipient.
  * `e` is the event that is being nutzapped, if any.

-# Sending a nutzap
+## Sending a nutzap

 * The sender fetches the recipient's `kind:10019`.
 * The sender mints/swaps ecash on one of the recipient's listed mints.
 * The sender P2PK-locks to the recipient's specified public key in their `kind:10019`

-# Receiving nutzaps
+## Receiving nutzaps

 Clients should REQ for nutzaps:
 * Filtering with `#u` for mints they expect to receive ecash from.
  * this is to prevent even interacting with mints the user hasn't explicitly signaled.
 * Filtering with `since` of the most recent `kind:7376` event the same user has created.
-  * this can be used as a marker of the nutzaps that have already been swaped by the user -- clients might choose to use other kinds of markers, including internal state -- this is just a guidance of one possible approach.
+  * this can be used as a marker of the nutzaps that have already been swapped by the user -- clients might choose to use other kinds of markers, including internal state -- this is just a guidance of one possible approach.

 `{ "kinds": [9321], "#p": ["my-pubkey"], "#u": ["<mint-1>", "<mint-2>"], "since": <latest-created_at-of-kind-7376> }`.

 Upon receiving a new nutzap, the client should swap the tokens into a wallet the user controls, either a [NIP-60](60.md) wallet, their own LN wallet or anything else.

-## Updating nutzap-redemption history
+### Updating nutzap-redemption history
 When claiming a token the client SHOULD create a `kind:7376` event and `e` tag the original nutzap event. This is to record that this token has already been claimed (and shouldn't be attempted again) and as signaling to the recipient that the ecash has been redeemed.

 Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
@@ -94,6 +97,7 @@ Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
    "content": nip44_encrypt([
        [ "direction", "in" ], // in = received, out = sent
        [ "amount", "1" ],
+        [ "unit", "sat" ],
        [ "e", "<7375-event-id>", "<relay-hint>", "created" ] // new token event that was created
    ]),
    "tags": [
@@ -105,7 +109,7 @@ Multiple `kind:9321` events can be tagged in the same `kind:7376` event.

 Events that redeem a nutzap SHOULD be published to the sender's [NIP-65](65.md) "read" relays.

-## Verifying a Cashu Zap
+### Verifying a Cashu Zap
 When listing or counting zaps received by any given event, observer clients SHOULD:

 * check that the receiving user has issued a `kind:10019` tagging the mint where the cashu has been minted.
@@ -115,7 +119,7 @@ When listing or counting zaps received by any given event, observer clients SHOU

 All these checks can be done offline (as long as the observer has the receiver mints' keyset and their `kind:10019` event), so the process should be reasonably fast.

-## Final Considerations
+### Final Considerations
 1. Clients SHOULD guide their users to use NUT-11 (P2PK) and NUT-12 (DLEQ proofs) compatible-mints in their `kind:10019` event to avoid receiving nutzaps anyone can spend.
 2. Clients SHOULD normalize and deduplicate mint URLs as described in NIP-65.
 3. A nutzap event MUST include proofs in one of the mints the recipient has listed in their `kind:10019` and published to the NIP-65 relays of the recipient, failure to do so may result in the recipient donating the tokens to the mint since the recipient might never see the event.
--- a/66.md
+++ b/66.md
@@ -6,137 +6,44 @@ 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.
+This NIP defines events for relay discovery and the announcement of relay monitors.

-In its purest form:
+## Relay Discovery Events

-```json
-{
-  "kind": 30166,
-  "created_at": 1722173222,  
-  "content": "{}",
-  "tags": [
-    [ "d", "wss://somerelay.abc/" ]
-  ],
-  "pubkey": "<pubkey>", 
-  "sig": "<signature>",
-  "id": "<eventid>"
-}
-```
+`30166` relay discovery events document relay characteristics inferred either from a relay's [NIP 11](https://github.com/nostr-protocol/nips/blob/master/11.md) document, or via probing.

-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.
+Information corresponding to field in a relay's NIP 11 document MAY contradict actual values if monitors find that a different policy is implemented than is advertised.

-## Kinds
-`NIP-66` defines two (2) event kinds, `30166` and `10166`
+`content` MAY include the stringified JSON of the relay's NIP-11 informational document.

-| 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_ |
+The only required tag is the `d` tag, which MUST be set to the relay's [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6) URL. For relays not accessible via URL, a hex-encoded pubkey MAY be used instead.

-## 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.
+Other tags include:

-## `30166`: "Relay Discovery" <a id="k30166"></a>
+- `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.
+- `n` - The relay's network type. SHOULD be one of `clearnet`, `tor`, `i2p`, `loki`
+- `T` - The relay type. Enumerated [relay type](https://github.com/nostr-protocol/nips/issues/1282) formatted as `PascalCase`, e.g. `PrivateInbox`
+- `N` - NIPs supported by the relay
+- `R` - Keys corresponding to requirements per [NIP 11](https://github.com/nostr-protocol/nips/blob/master/11.md)'s `limitations` array, including `auth`, `writes`, `pow`, and `payment`. False values should be specified using a `!` prefix, for example `!auth`.
+- `t` - A topic associated with this relay
+- `k` - Accepted and unaccepted kinds (false values prepended by `!`) 
+- `g` - A [NIP-52](https://github.com/nostr-protocol/nips/blob/master/52.md) geohash

-### 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.
+Tags with more than one value should be repeated, rather than putting all values in a single tag, for example `[["t", "cats"], ["t", "dogs"]]`, rather than `[["t", "cats", "dogs"]]`.

-### Purpose 
-Discovery of relays over nostr. 
+Example:

-### 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": "{}",
+  "content": "<optional nip 11 document>",
  "kind": 30166,
-  "tags": [  
+  "tags": [
    ["d","wss://some.relay/"],
    ["n", "clearnet"],
    ["N", "40"],
@@ -144,64 +51,28 @@ _Relay was online, and you can filter on a number of different tags_
    ["R", "!payment"],
    ["R", "auth"],
    ["g", "ww8p1r4t8"],
-    ["p", "somehexkey..."],
    ["l", "en", "ISO-639-1"],
    ["t", "nsfw" ],
-    ["rtt-open", 234 ]
+    ["rtt-open", "234" ]
  ]
-} 
+}
 ```

-## `10166`: "Relay Monitor Announcement" Events <a id="k10166"></a>
+## Relay Monitor Announcements

-### 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.
+Kind `10166` relay monitor announcements advertise the author's intent to publish `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.
+Tags include:

-### Schema
+- `frequency` - The frequency in seconds at which the monitor publishes events.
+- `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.
+- `c` - a lowercase string describing the checks conducted by a monitor. Examples include `open`, `read`, `write`, `auth`, `nip11`, `dns`, and `geo`.
+- `g` - [NIP-52](https://github.com/nostr-protocol/nips/blob/master/11.md) geohash tag

-#### Standard Tags
+Monitors SHOULD also publish a `kind 0` profile and a `kind 10002` relay selections event.

- `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. 
+Example:

-  ```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>",
@@ -209,46 +80,18 @@ Monitors **SHOULD** have the following
  "created_at": "<created_at  [some recent date ...]>",
  "signature": "<signature>",
  "content": "",
-  "tags": [  
-
+  "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
@@ -41,7 +41,8 @@ Events are [addressable events](01.md#kinds) and use `38383` as event kind, a p2
    ["name", "Nakamoto"],
    ["g", "<geohash>"],
    ["bond", "0"],
-    ["expiration", "1719391096"],
+    ["expires_at", "1719391096"],
+    ["expiration", "1719995896"],
    ["y", "lnp2pbot"],
    ["z", "order"]
  ],
@@ -55,7 +56,7 @@ Events are [addressable events](01.md#kinds) and use `38383` as event kind, a p2
 - `d` < Order ID >: A unique identifier for the order.
 - `k` < Order type >: `sell` or `buy`.
 - `f` < Currency >: The asset being traded, using the [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217) standard.
- `s` < Status >: `pending`, `canceled`, `in-progress`, `success`.
+- `s` < Status >: `pending`, `canceled`, `in-progress`, `success`, `expired`.
 - `amt` < Amount >: The amount of Bitcoin to be traded, the amount is defined in satoshis, if `0` means that the amount of satoshis will be obtained from a public API after the taker accepts the order.
 - `fa` < Fiat amount >: The fiat amount being traded, for range orders two values are expected, the minimum and maximum amount.
 - `pm` < Payment method >: The payment method used for the trade, if the order has multiple payment methods, they should be separated by a comma.
@@ -67,7 +68,8 @@ Events are [addressable events](01.md#kinds) and use `38383` as event kind, a p2
 - `name` [Name]: The name of the maker.
 - `g` [Geohash]: The geohash of the operation, it can be useful in a face to face trade.
 - `bond` [Bond]: The bond amount, the bond is a security deposit that both parties must pay.
- `expiration` < Expiration\>: The expiration date of the order ([NIP-40](40.md)).
+- `expires_at` < Expires At\>: The expiration date of the event being published in `pending` status, after this time the event status SHOULD be changed to `expired`.
+- `expiration` < Expiration\>: The expiration date of the event, after this time the relay SHOULD delete it ([NIP-40](40.md)).
 - `y` < Platform >: The platform that created the order.
 - `z` < Document >: `order`.

--- a/71.md
+++ b/71.md
@@ -26,6 +26,11 @@ The primary source of video information is the `imeta` tags which is defined in

 Each `imeta` tag can be used to specify a variant of the video by the `dim` & `m` properties.

+This NIP defines the following additional `imeta` properties aside form those listen in [NIP-92](92.md) & [NIP-94](94.md):
+
+* `duration` (recommended) the duration of the video/audio in seconds (floating point number)
+* `bitrate` (recommended) the average bitrate of the video/audio in bits/sec
+
 Example:
 ```json
 [
@@ -39,6 +44,8 @@ Example:
    "fallback https://myotherserver.com/1080/12345.mp4",
    "fallback https://andanotherserver.com/1080/12345.mp4",
    "service nip96",
+    "bitrate 3000000",
+    "duration 29.223"
  ],
  ["imeta",
    "dim 1280x720",
@@ -50,6 +57,8 @@ Example:
    "fallback https://myotherserver.com/720/12345.mp4",
    "fallback https://andanotherserver.com/720/12345.mp4",
    "service nip96",
+    "bitrate 2000000",
+    "duration 29.24"
  ],
  ["imeta",
    "dim 1280x720",
@@ -61,6 +70,7 @@ Example:
    "fallback https://myotherserver.com/720/12345.m3u8",
    "fallback https://andanotherserver.com/720/12345.m3u8",
    "service nip96",
+    "duration 29.21"
  ],
 ]
 ```
@@ -74,7 +84,6 @@ Additionally `service nip96` may be included to allow clients to search the auth
 ### Other tags:
 * `title` (required) title of the video
 * `published_at`, for the timestamp in unix seconds (stringified) of the first time the video was published
-* `duration` (optional) video duration in seconds
 * `text-track` (optional, repeated) link to WebVTT file for video, type of supplementary information (captions/subtitles/chapters/metadata), optional language code
 * `content-warning` (optional) warning about content of NSFW video
 * `alt` (optional) description for accessibility
@@ -85,15 +94,15 @@ Additionally `service nip96` may be included to allow clients to search the auth

 ```jsonc
 {
-  "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>,
+  "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": 21 | 22,
  "content": "<summary / description of video>",
  "tags": [
    ["title", "<title of video>"],
    ["published_at", "<unix timestamp>"],
-    ["alt", <description>],
+    ["alt", "<description>"],

    // video Data
    ["imeta",
@@ -108,7 +117,6 @@ Additionally `service nip96` may be included to allow clients to search the auth
      "service nip96",
    ],

-    ["duration", <duration of video in seconds>],
    ["text-track", "<encoded `kind 6000` event>", "<recommended relay urls>"],
    ["content-warning", "<reason>"],
    ["segment", <start>, <end>, "<title>", "<thumbnail URL>"],
--- a/72.md
+++ b/72.md
@@ -8,7 +8,7 @@ Moderated Communities (Reddit Style)

 The goal of this NIP is to enable public communities. It defines the replaceable event `kind:34550` to define the community and the current list of moderators/administrators. Users that want to post into the community, simply tag any Nostr event with the community's `a` tag. Moderators may issue an approval event `kind:4550`.

-# Community Definition
+## Community Definition

 `Kind:34550` SHOULD include any field that helps define the community and the set of moderators. `relay` tags MAY be used to describe the preferred relay to download requests and approvals. A community definition event's `d` tag MAY double as its name, but if a `name` tag is provided, it SHOULD be displayed instead of the `d` tag.

@@ -39,11 +39,11 @@ The goal of this NIP is to enable public communities. It defines the replaceable
 }
 ```

-# Posting to a community
+## Posting to a community

 [NIP-22](NIP-22) kind 1111 events SHOULD be used for text notes posted to a community, with the `A` tag always scoped to the community definition.

-## Top-level posts
+### Top-level posts

 For top-level posts, the uppercase and lowercase NIP-22 tags should both refer to the community definition itself.

@@ -63,7 +63,7 @@ For top-level posts, the uppercase and lowercase NIP-22 tags should both refer t
 }
 ```

-## Nested replies
+### Nested replies

 For nested replies, the uppercase tags should still refer to the community definition, while the lowercase tags should refer to the parent post or reply.

@@ -86,11 +86,11 @@ For nested replies, the uppercase tags should still refer to the community defin
 }
 ```

-## Backwards compatibility note
+### Backwards compatibility note

 Previously kind 1 events were used for posts in communities, with an "a" tag pointing to the community. For backwards compatibility, clients MAY still query for kind 1 events, but SHOULD NOT use them for new posts. Instead, clients SHOULD use kind 1111 events with the `A` and `a` tags as described above.

-# Moderation
+## Moderation

 Anyone may issue an approval event to express their opinion that a post is appropriate for a community. Clients MAY choose which approval events to honor, but SHOULD at least use ones published by the group's defined moderators.

@@ -127,6 +127,6 @@ Since relays are instructed to delete old versions of a replaceable event, the `

 Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be approved for all `34550:*` `a` tags.

-# Cross-posting
+## Cross-posting

 Clients MAY support cross-posting between communities by posting a NIP 18 `kind 6` or `kind 16` repost to one or more communities using `a` tags as described above. The `content` of the repost MUST be the original event, not the approval event.
--- a/73.md
+++ b/73.md
@@ -6,7 +6,7 @@ External Content IDs

 `draft` `optional`

-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.
+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 associated 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.
@@ -47,7 +47,7 @@ For the webpage "https://myblog.example.com/post/2012-03-27/hello-world" the "i"

 - Book ISBN: `["i", "isbn:9780765382030"]` - https://isbnsearch.org/isbn/9780765382030

-Book ISBNs MUST be referenced _**without hyphens**_ as many book search APIs return the ISBNs without hyphens. Removing hypens from ISBNs is trivial, whereas adding the hyphens back in is non-trivial requiring a library.
+Book ISBNs MUST be referenced _**without hyphens**_ as many book search APIs return the ISBNs without hyphens. Removing hyphens from ISBNs is trivial, whereas adding the hyphens back in is non-trivial requiring a library.

 ### Podcasts:

--- a/77.md
+++ b/77.md
@@ -99,7 +99,7 @@ When finished, the client should tell the relay it can release its resources wit

 ### Preparation

-There are two protocol participants: Client and server. The client creates an initial message and transmits it to the server, which replies with its own message in response. The client continues querying the server until it is satisifed, and then terminates the protocol. Messages in either direction have the same format.
+There are two protocol participants: Client and server. The client creates an initial message and transmits it to the server, which replies with its own message in response. The client continues querying the server until it is satisfied, and then terminates the protocol. Messages in either direction have the same format.

 Each participant has a collection of records. A records consists of a 64-bit numeric timestamp and a 256-bit ID. Each participant starts by sorting their items according to timestamp, ascending. If two timestamps are equal then items are sorted lexically by ID, ascending by first differing byte. Items may not use the max uint64 value (`2**64 - 1`) as a timestamp since this is reserved as a special "infinity" value.

--- a/87.md
+++ b/87.md
@@ -41,7 +41,7 @@ There are three actors to this workflow:
 }
 ```

-The recommendation event is a parameterized-replacable event so that a user can change edit their recommendation without creating a new event.
+The recommendation event is a parameterized-replaceable event so that a user can change edit their recommendation without creating a new event.

 The `d` tag in `kind:38000` is the `kind:38173`/`kind:38172` event identifier this event is recommending, if no event exists, the `d` tag can still be calculated from the mint's pubkey/id.
 The `k` tag is the kind number that corresponds to the event kind that the user is recommending, in this case `kind:38173` for fedimints and `kind:38172` for cashu mints.
--- a/89.md
+++ b/89.md
@@ -47,7 +47,7 @@ Multiple `a` tags can appear on the same `kind:31989`.
 The second value of the tag SHOULD be a relay hint.
 The third value of the tag SHOULD be the platform where this recommendation might apply.

-## Handler information
+### Handler information
 ```jsonc
 {
  "kind": 31990,
@@ -76,7 +76,7 @@ Multiple tags might be registered by the app, following NIP-19 nomenclature as t

 A tag without a second value in the array SHOULD be considered a generic handler for any NIP-19 entity that is not handled by a different tag.

-# Client tag
+## Client tag
 When publishing events, clients MAY include a `client` tag. Identifying the client that published the note. This tag is a tuple of `name`, `address` identifying a handler event and, a relay `hint` for finding the handler event. This has privacy implications for users, so clients SHOULD allow users to opt-out of using this tag.

 ```jsonc
--- a/90.md
+++ b/90.md
@@ -68,7 +68,7 @@ All tags are optional.
 * `relays`: List of relays where Service Providers SHOULD publish responses to
 * `p`: Service Providers the customer is interested in. Other SPs MIGHT still choose to process the job

-## Encrypted Params
+### Encrypted Params

 If the user wants to keep the input parameters a secret, they can encrypt the `i` and `param` tags with the service provider's 'p' tag and add it to the content field. Add a tag `encrypted` as tags. Encryption for private tags will use [NIP-04 - Encrypted Direct Message encryption](04.md), using the user's private and service provider's public key for the shared secret

@@ -122,7 +122,7 @@ Service providers publish job results, providing the output of the job result. T
 * `amount`: millisats that the Service Provider is requesting to be paid. An optional third value can be a bolt11 invoice.
 * `i`: The original input(s) specified in the request.

-## Encrypted Output
+### Encrypted Output

 If the request has encrypted params, then output should be encrypted and placed in  `content` field. If the output is encrypted, then avoid including `i` tag with input-data as clear text.
 Add a tag encrypted to mark the output content as `encrypted`
@@ -180,7 +180,7 @@ Service providers can give feedback about a job back to the customer.
 Any job feedback event MIGHT include results in the `.content` field, as described in the [Job Result](#job-result-kind6000-6999) section. This is useful for service providers to provide a sample of the results that have been processed so far.


-# Protocol Flow
+## Protocol Flow

 * 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.).
@@ -191,24 +191,24 @@ Job feedback (`kind:7000`) and Job Results (`kind:6000-6999`) events MAY include

 Customers can always either pay the included `bolt11` invoice or zap the event requesting the payment and service providers should monitor for both if they choose to include a bolt11 invoice.

-## Notes about the protocol flow
+### Notes about the protocol flow
 The flow is deliberately ambiguous, allowing vast flexibility for the interaction between customers and service providers so that service providers can model their behavior based on their own decisions/perceptions of risk.

 Some service providers might choose to submit a `payment-required` as the first reaction before sending a `processing` or before delivering results, some might choose to serve partial results for the job (e.g. a sample), send a `payment-required` to deliver the rest of the results, and some service providers might choose to assess likelihood of payment based on an npub's past behavior and thus serve the job results before requesting payment for the best possible UX.

 It's not up to this NIP to define how individual vending machines should choose to run their business.

-# Cancellation
+## Cancellation
 A job request might be canceled by publishing a `kind:5` delete request event tagging the job request event.

-# Appendix 1: Job chaining
+## Appendix 1: Job chaining
 A Customer MAY request multiple jobs to be processed as a chain, where the output of a job is the input of another job. (e.g. podcast transcription -> summarization of the transcription). This is done by specifying as input an event id of a different job with the `job` type.

 Service Providers MAY begin processing a subsequent job the moment they see the prior job's result, but they will likely wait for a zap to be published first. This introduces a risk that Service Provider of job #1 might delay publishing the zap event in order to have an advantage. This risk is up to Service Providers to mitigate or to decide whether the service provider of job #1 tends to have good-enough results so as to not wait for an explicit zap to assume the job was accepted.

 This gives a higher level of flexibility to service providers (which sophisticated service providers would take anyway).

-# Appendix 2: Service provider discoverability
+## Appendix 2: Service provider discoverability
 Service Providers MAY use NIP-89 announcements to advertise their support for job kinds:

 ```jsonc
--- a/96.md
+++ b/96.md
@@ -1,3 +1,5 @@
+> __Warning__  `unrecommended`: deprecated in favor of [NIP-B7](B7.md)
+
 NIP-96
 ======

--- a/99.md
+++ b/99.md
@@ -40,7 +40,7 @@ The following tags, used for structured metadata, are standardized and SHOULD be
  - `"<number>"` is the amount in numeric format (but included in the tag as a string)
  - `"<currency>"` is the currency unit in 3-character ISO 4217 format or ISO 4217-like currency code (e.g. `"btc"`, `"eth"`).
  - `"<frequency>"` is optional and can be used to describe recurring payments. SHOULD be in noun format (hour, day, week, month, year, etc.)
- - `"status"` (optional), the status of the listing. SHOULD be either "active" or "sold".
+- `"status"` (optional), the status of the listing. SHOULD be either "active" or "sold".

 #### `price` examples

@@ -48,7 +48,7 @@ The following tags, used for structured metadata, are standardized and SHOULD be
 - €15 per month `["price", "15", "EUR", "month"]`
 - £50,000 per year `["price", "50000", "GBP", "year"]`

-Other standard tags that might be useful.
+Other common tags that might be useful.

 - `"g"`, a geohash for more precise location

--- a/A0.md
+++ b/A0.md
@@ -0,0 +1,60 @@
+NIP-A0
+======
+
+Voice Messages
+-----------
+
+**Status:** Draft
+
+This NIP defines new events `kind: 1222` for root messages and `kind: 1244` for reply messages to be used for short voice messages, typically up to 60 seconds in length.
+
+## Specification
+
+### Event Kind `1222` and Kind `1244`
+
+The `kind: 1222` event is defined as follows:
+
+-   `content`: MUST be a URL pointing directly to an audio file.
+    -   The audio file SHOULD be in `audio/mp4` (.m4a) format using AAC or Opus encoding. Clients MAY support other common audio formats like `audio/ogg`, `audio/webm`, or `audio/mpeg` (mp3), but `audio/mp4` is recommended for broad compatibility and efficiency.
+    -   The audio duration SHOULD be no longer than 60 seconds. Clients publishing `kind: 1222` events SHOULD enforce this limit or provide a clear warning to the user if exceeded.
+-   `tags`:
+    -   Tags MAY be included as per other NIPs (e.g., `t` for hashtags, `g` for geohash, etc.).
+
+  The `kind: 1244` event is defined as follows:
+  
+-    To be used for replies, `kind: 1244` events MUST follow the structure of `NIP-22`.
+-   `content`: MUST be a URL pointing directly to an audio file.
+    -   The audio file SHOULD be in `audio/mp4` (.m4a) format using AAC or Opus encoding. Clients MAY support other common audio formats like `audio/ogg`, `audio/webm`, or `audio/mpeg` (mp3), but `audio/mp4` is recommended for broad compatibility and efficiency.
+    -   The audio duration SHOULD be no longer than 60 seconds. Clients publishing `kind: 1222` events SHOULD enforce this limit or provide a clear warning to the user if exceeded.
+-   `tags`:
+    -   Tags MAY be included as per other NIPs (e.g., `t` for hashtags, `g` for geohash, etc.).
+
+
+## Visual representation with `imeta` (NIP-92) tag (optional)
+
+The following imeta (NIP-92) tags MAY be included so clients can render a visual preview without having to download the audio file first:
+
+- `waveform`: amplitude values over time, space separated full integers, less than 100 values should be enough to render a nice visual
+- `duration`: audio length in seconds
+
+## Examples
+
+### Root Voice Message Example
+
+```json
+{
+  "content": "https://blossom.primal.net/5fe7df0e46ee6b14b5a8b8b92939e84e3ca5e3950eb630299742325d5ed9891b.mp4",
+  "created_at": 1752501052,
+  "id": "...",
+  "kind": 1222,
+  "pubkey": "...",
+  "sig": "...",
+  "tags": [
+    [
+      "imeta",
+      "url https://blossom.primal.net/5fe7df0e46ee6b14b5a8b8b92939e84e3ca5e3950eb630299742325d5ed9891b.mp4",
+      "waveform 0 7 35 8 100 100 49 8 4 16 8 10 7 2 20 10 100 100 100 100 100 100 15 100 100 100 25 60 5 4 3 1 0 100 100 15 100 29 88 0 33 11 39 100 100 19 4 100 42 35 5 0 1 5 0 0 11 38 100 94 17 11 44 58 5 100 100 100 55 14 72 100 100 57 6 1 14 2 16 100 100 40 16 100 100 6 32 14 13 41 36 16 14 6 3 0 1 2 1 6 0",
+      "duration 8"
+    ]
+  ]
+}
--- a/B0.md
+++ b/B0.md
@@ -6,31 +6,23 @@ 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.
+This NIP defines `kind:39701` for a URI as editable web bookmark which uses the HTTP scheme.

 ### Format

-The format uses an _addressable event_ of `kind:39701`.
+The format uses `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 `.content` should be a detailed description of the web bookmark. It can be an empty string.

-The `d` tag is required.
+The `d` tag is just their URL without the scheme, which is always and everywhere assumed to be `https://` or `http://`.

-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.
+In this way web bookmarks events can be queried by the `d` tag by clients.

 ### 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.
+Metadata fields can be added as tags to the event as necessary.

+* `"t"`, for "tags"/"hashtags" (i.e. topics about which the event might be of relevance)
 * `"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

--- a/BE.md
+++ b/BE.md
@@ -0,0 +1,137 @@
+NIP-BE
+======
+
+Nostr BLE Communications Protocol
+---------------------------------
+
+`draft` `optional`
+
+This NIP specifies how Nostr apps can use BLE to communicate and synchronize with each other. The BLE protocol follows a client-server pattern, so this NIP emulates the WS structure in a similar way, but with some adaptations to its limitations.
+
+## Device advertisement
+A device advertises itself with:
+- Service UUID: `0000180f-0000-1000-8000-00805f9b34fb`
+- Data: Device UUID in ByteArray format
+
+## GATT service
+The device exposes a Nordic UART Service with the following characteristics:
+
+1. Write Characteristic
+   - UUID: `87654321-0000-1000-8000-00805f9b34fb`
+   - Properties: Write
+
+2. Read Characteristic
+   - UUID: `12345678-0000-1000-8000-00805f9b34fb`
+   - Properties: Notify, Read
+
+## Role assignment
+
+When one device initially finds another advertising the service, it will read the service's data to get the device UUID and compare it with its own advertised device UUID. For this communication, the device with the highest ID will take the role of GATT Server (Relay), the other will be considered the GATT Client (Client) and will proceed to establish the connection.
+
+For devices whose purpose will require a single role, its device UUID will always be:
+
+- GATT Server: `FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF`
+- GATT Client: `00000000-0000-0000-0000-000000000000`
+
+## Messages
+
+All messages will follow [NIP-01](/01.md) message structure. For a given message, a compression stream (DEFLATE) is applied to the message to generate a byte array. Depending on the BLE version, the byte array can be too large for a single message (20-23 bytes in BLE 4.2, 256 bytes in BLE > 4.2). In that case, this byte array is split into any number of batches following the structure:
+
+```
+[batch index (first 2 bytes)][batch n][is last batch (last byte)]
+```
+After reception of all batches, the other device can then join them and decompress. To ensure reliability, only 1 message will be read/written at a time. MTU can be negotiated in advance. The maximum size for a message is 64KB; bigger messages will be rejected.
+
+## Examples
+
+This example implements a function to split and compress a byte array into chunks, as well as another function to join and decompress them in order to obtain the initial result:
+
+```kotlin
+fun splitInChunks(message: ByteArray): Array<ByteArray> {
+   val chunkSize = 500 // define the chunk size
+   var byteArray = compressByteArray(message)
+   val numChunks = (byteArray.size + chunkSize - 1) / chunkSize // calculate the number of chunks
+   var chunkIndex = 0
+   val chunks = Array(numChunks) { ByteArray(0) }
+
+   for (i in 0 until numChunks) {
+         val start = i * chunkSize
+         val end = minOf((i + 1) * chunkSize, byteArray.size)
+         val chunk = byteArray.copyOfRange(start, end)
+
+         // add chunk index to the first 2 bytes and last chunk flag to the last byte
+         val chunkWithIndex = ByteArray(chunk.size + 2)
+         chunkWithIndex[0] = chunkIndex.toByte() // chunk index
+         chunk.copyInto(chunkWithIndex, 1)
+         chunkWithIndex[chunkWithIndex.size - 1] = numChunks.toByte()
+
+         // store the chunk in the array
+         chunks[i] = chunkWithIndex
+
+         chunkIndex++
+   }
+
+   return chunks
+}
+
+fun joinChunks(chunks: Array<ByteArray>): ByteArray {
+   val sortedChunks = chunks.sortedBy { it[0] }
+   var reassembledByteArray = ByteArray(0)
+   for (chunk in sortedChunks) {
+         val chunkData = chunk.copyOfRange(1, chunk.size - 1)
+         reassembledByteArray = reassembledByteArray.copyOf(reassembledByteArray.size + chunkData.size)
+         chunkData.copyInto(reassembledByteArray, reassembledByteArray.size - chunkData.size)
+   }
+
+   return decompressByteArray(reassembledByteArray)
+}
+
+```
+
+## Workflows
+
+### Client to relay
+
+- Any message the client wants to send to a relay will be a write message.
+- Any message the client receives from a relay will be a read message.
+
+### Relay to client
+
+The relay should notify the client about any new event matching subscription's filters by using the Notify action of the Read Characteristic. After that, the client can proceed to read messages from the relay.
+
+### Device synchronization
+
+Given the nature of BLE, it is expected that the direct connection between two devices might be extremely intermittent, with gaps of hours or even days. That's why it's crucial to define a synchronization process by following [NIP-77](./77.md) but with an adaptation to the limitations of the technology.
+
+After two devices have successfully connected and established the Client-Server roles, the devices will use half-duplex communication to intermittently send and receive messages.
+
+#### Half-duplex synchronization
+
+Right after the 2 devices connect, the Client starts the workflow by sending the first message.
+
+1. Client - Writes ["NEG-OPEN"](/77.md#initial-message-client-to-relay) message.
+2. Server - Sends `write-success`.
+3. Client - Sends `read-message`.
+4. Server - Responds with ["NEG-MSG"](./77.md#subsequent-messages-bidirectional) message.
+5. Client -
+   1. If the Client has messages missing on the Server, it writes one `EVENT`.
+   2. If the Client doesn't have any messages missing on the Server, it writes `EOSE`. In this case, subsequent messages to the Server will be empty while the Server claims to have more notes for the Client.
+6. Server - Sends `write-success`.
+7. Client - Sends `read-message`.
+8. Server -
+   1. If the Server has messages missing on the Client, it responds with one `EVENT`.
+   2. If the Client doesn't have any messages missing on the Server, it responds with `EOSE`. In this case, subsequent responses to the Client will be empty.
+9. If the Client detects that the devices are not synchronized yet, jump to step 5.
+10. After the two devices detect that there are no more missing events on both ends, the workflow will pause at this point.
+
+#### Half-duplex event spread
+
+While two devices are connected and synchronized, it might happen that one of them receives a new message from another connected peer. Devices MUST keep track of which notes have been sent to its peers while they are connected. If the newly received event is detected as missing in one of the connected and synchronized peers:
+
+1. If the peer is a Server:
+   1. Client - It writes the `EVENT`.
+   2. Server - Sends `write-success`.
+2. If the peer is a Client:
+   1. Server - It will send an empty notification to the Client.
+   2. Client - Sends `read-message`.
+   3. Server - Responds with the `EVENT`.
--- a/BREAKING.md
+++ b/BREAKING.md
@@ -1,68 +0,0 @@
-# Breaking Changes
-
-This is a history of NIP changes that potentially break pre-existing implementations, in
-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) |
-| 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 |
-| 2024-11-12  | [926a51e7](https://github.com/nostr-protocol/nips/commit/926a51e7) | [46](46.md) | `connect` params and result were changed |
-| 2024-10-29  | [f1e8d2c4](https://github.com/nostr-protocol/nips/commit/f1e8d2c4) | [46](46.md) | bunker URL should use `remote-signer-key` |
-| 2024-10-15  | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [71](71.md) | some tags were replaced with `imeta` tag |
-| 2024-10-15  | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [71](71.md) | `kind: 34237` was dropped |
-| 2024-10-07  | [7bb8997b](https://github.com/nostr-protocol/nips/commit/7bb8997b) | [55](55.md) | some fields and passing data were changed |
-| 2024-08-18  | [3aff37bd](https://github.com/nostr-protocol/nips/commit/3aff37bd) | [54](54.md) | content should be Asciidoc |
-| 2024-07-31  | [3ea2f1a4](https://github.com/nostr-protocol/nips/commit/3ea2f1a4) | [45](45.md) | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) was reverted |
-| 2024-07-30  | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) | [45](45.md) | NIP-45 was deprecated |
-| 2024-07-26  | [ecee40df](https://github.com/nostr-protocol/nips/commit/ecee40df) | [19](19.md) | `nrelay` was deprecated |
-| 2024-07-23  | [0227a2cd](https://github.com/nostr-protocol/nips/commit/0227a2cd) | [01](01.md) | events should be sorted by id after created_at |
-| 2024-06-06  | [58e94b20](https://github.com/nostr-protocol/nips/commit/58e94b20) | [25](25.md) | [8073c848](https://github.com/nostr-protocol/nips/commit/8073c848) was reverted |
-| 2024-06-06  | [a6dfc7b5](https://github.com/nostr-protocol/nips/commit/a6dfc7b5) | [55](55.md) | NIP number was changed |
-| 2024-05-25  | [5d1d1c17](https://github.com/nostr-protocol/nips/commit/5d1d1c17) | [71](71.md) | `aes-256-gcm` tag was removed |
-| 2024-05-07  | [8073c848](https://github.com/nostr-protocol/nips/commit/8073c848) | [25](25.md) | e-tags were changed to not include entire thread |
-| 2024-04-30  | [bad88262](https://github.com/nostr-protocol/nips/commit/bad88262) | [34](34.md) | `earliest-unique-commit` tag was removed (use `r` tag instead) |
-| 2024-02-25  | [4a171cb0](https://github.com/nostr-protocol/nips/commit/4a171cb0) | [18](18.md) | quote repost should use `q` tag |
-| 2024-02-21  | [c6cd655c](https://github.com/nostr-protocol/nips/commit/c6cd655c) | [46](46.md) | Params were stringified |
-| 2024-02-16  | [cbec02ab](https://github.com/nostr-protocol/nips/commit/cbec02ab) | [49](49.md) | Password first normalized to NFKC |
-| 2024-02-15  | [afbb8dd0](https://github.com/nostr-protocol/nips/commit/afbb8dd0) | [39](39.md) | PGP identity was removed |
-| 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), [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 |
-| 2023-11-28  | [6de35f9e](https://github.com/nostr-protocol/nips/commit/6de35f9e) | [89](89.md) | `client` tag value was changed |
-| 2023-11-20  | [7822a8b1](https://github.com/nostr-protocol/nips/commit/7822a8b1) | [51](51.md) | `kind: 30001` was deprecated |
-| 2023-11-20  | [7822a8b1](https://github.com/nostr-protocol/nips/commit/7822a8b1) | [51](51.md) | the meaning of `kind: 30000` was changed |
-| 2023-11-11  | [cbdca1e9](https://github.com/nostr-protocol/nips/commit/cbdca1e9) | [84](84.md) | `range` tag was removed |
-| 2023-11-10  | [c945d8bd](https://github.com/nostr-protocol/nips/commit/c945d8bd) | [32](32.md) | `l` tag annotations was removed |
-| 2023-11-07  | [108b7f16](https://github.com/nostr-protocol/nips/commit/108b7f16) | [01](01.md) | `OK` message must have 4 items |
-| 2023-10-17  | [cf672b76](https://github.com/nostr-protocol/nips/commit/cf672b76) | [03](03.md) | `block` tag was removed |
-| 2023-09-29  | [7dc6385f](https://github.com/nostr-protocol/nips/commit/7dc6385f) | [57](57.md) | optional `a` tag was included in `zap receipt` |
-| 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), [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` |
-| 2023-07-12  | [a1cd2bd8](https://github.com/nostr-protocol/nips/commit/a1cd2bd8) | [25](25.md) | custom emoji was supported |
-| 2023-06-18  | [83cbd3e1](https://github.com/nostr-protocol/nips/commit/83cbd3e1) | [11](11.md) | `image` was renamed to `icon` |
-| 2023-04-13  | [bf0a0da6](https://github.com/nostr-protocol/nips/commit/bf0a0da6) | [15](15.md) | different NIP was re-added as NIP-15 |
-| 2023-04-09  | [fb5b7c73](https://github.com/nostr-protocol/nips/commit/fb5b7c73) | [15](15.md) | NIP-15 was merged into NIP-01 |
-| 2023-03-29  | [599e1313](https://github.com/nostr-protocol/nips/commit/599e1313) | [18](18.md) | NIP-18 was bring back |
-| 2023-03-15  | [e1004d3d](https://github.com/nostr-protocol/nips/commit/e1004d3d) | [19](19.md) | `1: relay` was changed to optionally |
-
-Breaking changes prior to 2023-03-01 are not yet documented.
-
-## NOTES
-
- If it isn't clear that a change is breaking or not, we list it.
- The date is the date it was merged, not necessarily the date of the commit.
--- a/C0.md
+++ b/C0.md
@@ -23,9 +23,9 @@ The `.content` field contains the actual code snippet text.
 - `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")
+- `license` - License under which the code (along with any related data contained within the event, when available, such as the description) is shared. This MUST be a standard [SPDX](https://spdx.org/licenses/) short identifier (e.g., "MIT", "GPL-3.0-or-later", "Apache-2.0") when available. An additional parameter containing a reference to the actual text of the license MAY be provided. This tag can be repeated, to indicate multi-licensing, allowing recipients to use the code under any license of choosing among the referenced ones
 - `dep` - Dependency required for the code to run (can be repeated)
- `repo` - Reference to a repository where this code originates
+- `repo` - Reference to a repository where this code originates. This MUST be a either standard URL or, alternatively, the address of a [NIP-34](34.md) Git repository annoucement event in the form `"30617:<32-bytes hex a pubkey>:<d tag value>"`. If a repository announcement is referenced, a recommended relay URL where to find the event should be provided as an additional parameter

 ## Format

--- a/EE.md
+++ b/EE.md
@@ -0,0 +1,288 @@
+# NIP-EE
+
+## E2EE Messaging using the Messaging Layer Security (MLS) Protocol
+
+`draft` `optional`
+
+This NIP standardizes how to use the [MLS Protocol](https://www.rfc-editor.org/rfc/rfc9420.html) with Nostr for efficient and E2EE (end-to-end encrypted) direct and group messaging.
+
+## Context
+
+Originally, one-to-one direct messages (DMs) in Nostr happened via the scheme defined in [NIP-04](04.md). This NIP is not recommended because, while it encrypts the content of the message (provides decent confidentiality), it leaks significant amounts of metadata about the parties involved in the conversation (completely lacks privacy).
+
+With the addition of [NIP-44](44.md), we have an updated encryption scheme that improves confidentiality guarantees but stops short of defining a new scheme for doing direct messages using this encryption scheme. Hence, makes little to no difference to privacy.
+
+Most recently, [NIP-17](17.md) combines [NIP-44](44.md) encryption with [NIP-59](59.md) gift-wrapping to hide the encrypted direct message inside another set of events to ensure that it's impossible to see who is talking to who and when messages passed between the users. This largely solves the metadata leakage problem; while it's still possible to see that a user is receiving gift-wrapped events, you can't tell from whom and what kind of events are within the gift-wrap outer event. This gives some degree of deniability/repudiation but doesn't solve forward secrecy or post compromise security. That is to say, if a user's private key (or the calculated conversation key shared between two users used to encrypt messages) is compromised, the attacker will have full access to all past and future DMs sent between those users.
+
+In addition, neither [NIP-04](04.md) or [NIP-17](17.md) attempt to solve the problem of group messages.
+
+### Why is this important?
+
+Without proper E2EE, Nostr cannot be used as the protocol for secure messaging clients. While clients like Signal do a fantastic job with E2EE, they still rely on centralized servers and as a result can be shut down by a powerful (i.e. state-level) actor. The goal of Nostr is not only to protect against centralized entities censoring you and your communications, but also protect against the ability of a state-level actor to stop these sorts of services from existing in the first place. By replacing centralized servers with decentralized relays, we make it nearly impossible for a centralized actor to completely stop communications between individual users.
+
+### Goals of this NIP
+
+1. Private _and_ Confidential DMs and Group messages
+   1. **Private** means that an observer cannot tell that Alice and Bob are talking to one another, or that Alice is part of a specific group. This necessarily requires protecting metadata.
+   2. **Confidential** means that the contents of conversations can only be viewed by the intended recipients.
+2. Forward secrecy and Post-compromise security
+   1. **Forward secrecy** means that encrypted content in the past remains encrypted even if a key material is leaked.
+   2. **Post compromise security** means that leaking key material doesn't allow an attacker to continue to read messages indefinitely into the future.
+3. Scales efficiently for large groups
+4. Allows for the use of multiple device/clients in a single conversation/group.
+
+### Why MLS?
+
+This scheme adapts the Message Layer Security (MLS) protocol for use with Nostr. You can think of MLS as an evolution of the Signal Protocol. However, it significantly improves the scalability of encryption operations for large group messaging significantly (linear -> log), is built to accommodate federated environments, and also allows for graceful updating of ciphersuites and versions over time. In addition, it's very flexible and agnostic about the message content that is sent.
+
+It's beyond the scope of this NIP to explain the MLS protocol but you can read more about it in it's [Architectural Overview](https://www.ietf.org/archive/id/draft-ietf-mls-architecture-13.html) or the [RFC](https://www.rfc-editor.org/rfc/rfc9420). MLS is on track to become an internet standard under the IETF so the protocol itself is extremely well vetted and researched. This also means there is the potential for cross network messaging interoperability in the future as MLS gains more adoption.
+
+## Core MLS Concepts
+
+From the [MLS Architectural Overview](https://www.ietf.org/archive/id/draft-ietf-mls-architecture-13.html):
+
+> MLS provides a way for clients to form groups within which they can communicate securely. For example, a set of users might use clients on their phones or laptops to join a group and communicate with each other. A group may be as small as two clients (e.g., for simple person to person messaging) or as large as hundreds of thousands. A client that is part of a group is a member of that group. As groups change membership and group or member properties, they advance from one epoch to another and the cryptographic state of the group evolves.
+>
+> The group is represented as a tree, which represents the members as the leaves of a tree. It is used to efficiently encrypt to subsets of the members. Each member has a state called a LeafNode object holding the client's identity, credentials, and capabilities.
+
+The MLS protocol's job is to manage and evolve the cryptographic state of a group. This includes managing the membership of a group, the cryptographic state of a group (ratchet tree, keys, and encryption/decryption/authentication of messages), and managing the evolution of the group over time.
+
+### Groups
+
+Groups are created by their first member, who then invites one or more other members. Groups evolve over time in blocks called `Epochs`. New epochs are proposed via one ore more `Proposal` messages and then committed to via a `Commit` message.
+
+### Clients
+
+The device/client pair (e.g. Primal on iOS or Coracle on web) with which a user joins the group is represented as a `LeafNode` in the tree. The terms `Client` and `Member` are interchangeable in this regard. It is not possible to share group state across multiple `Clients`. If a user joins a group from 2 separate devices, their state is separate and they will be tracked as 2 separate members of the group.
+
+### Messages
+
+There are several different types of messages sent within a group. Some of these are control messages that are used to update the group state over time. These include `Welcome`, `Proposal`, and `Commit` messages. Others are the actual messages that are sent between members in a group. These include `Application` messages.
+
+Messages in MLS are "framed". Meaning that they are wrapped in a data structure that includes information about the sender, the epoch, the message index within the epoch and the message content. This framing makes it possible to authenticate and decrypt messages correctly, even if they arrive out of order.
+
+MLS is agnostic to the "content" of the messages that are sent. This is a key feature of MLS that allows for the use of MLS for a wide variety of applications.
+
+MLS is also agnostic to the transport protocol that is used to send messages. Obviously for us, we'll be using websockets, Nostr events and relays.
+
+## The focus of this NIP
+
+This NIP focuses on how to use Nostr to perform the Authentication Service and Delivery Service functions required by the MLS protocol. Most clients will choose to use an MLS implementation to handle keys, ratcheting, group state management, and other aspects of the MLS protocol itself. [OpenMLS](https://github.com/openmls/openmls) is the most actively developed library that implements MLS.
+
+This NIP specifies the following:
+
+1. A standardized way that Nostr clients should [create MLS groups](#creating-groups).
+2. The required format of the MLS [`Credential`](#mls-credentials) that Nostr clients should use to represent a Nostr user in a group.
+3. The structure of [KeyPackage Events](#keypackage-event-and-signing-keys) published to relays that allow Nostr users to be added to a group asynchronously.
+4. The structure of [Group Events](#group-events) published to relays that represent the evolution of a group's state and the contents of the messages sent in the group.
+
+## Security Considerations
+
+This is a concise overview of the security trade-offs and considerations of this NIP in various scenarios. The NIP strives to fully maintain MLS security guarantees.
+
+### Forward Secrecy and Post-compromise Security
+
+- As per the MLS spec, keys are deleted as soon as they are used to encrypt or decrypt a message. This is usually handled by the MLS implementation library itself but attention needs to be paid by clients to ensure they're not storing secrets (especially the [exporter secret](#group-events)) for longer than absolutely necessary.
+- This NIP maintains MLS forward secrecy and post-compromise security guarantees. You can read more about those in the MLS Architectural Overview section on [Forward Secrecy and Post-compromise Security](https://www.ietf.org/archive/id/draft-ietf-mls-architecture-15.html#name-forward-and-post-compromise).
+
+### Leakage of various keys
+
+- This NIP does not depend on a user's Nostr identity key for any aspect of the MLS messaging protocol. Compromise of a user's Nostr identity key does not give access to past or future messages in any MLS-based group.
+- For a complete discussion of MLS key leakage, please see the Endpoint Compromise section of the [MLS Architectural Overview](https://www.ietf.org/archive/id/draft-ietf-mls-architecture-15.html#name-endpoint-compromise).
+
+### Metadata
+
+- The only group specific metadata published to relays is the Nostr group ID value. This value is used to identify the group in the `h` tag of the Group Message Event (`kind: 445`). These events are published ephemerally and this Nostr group ID value can be updated over the lifetime of the group by group admins. This is a tradeoff to ensure that group participants and group size are obfuscated but still makes it possible to efficiently fan out group messages to all participants. The content field of this event is a value encrypted in two separate ways (using NIP-44 and MLS) with MLS group state/keys. Only group members with up-to-date group state can decrypt and read these messages.
+- A user's key package events can be used one or more times to be added to groups. There is a tradeoff inherent here: Reusing key packages (initial signing keys) carries some degree of risk but this risk is mitigated as long as a user rotates their signing key immediately upon joining a group. This step also improves the forward secrecy of the entire group.
+
+### Device Compromise
+
+Clients implementing this NIP should take every precaution to ensure that data is stored in a secure way on the device and is protected against unwanted access in the case that a device is compromised (e.g. encryption at rest, biometric authentication, etc.). That said, full device compromise should be viewed as a catastrophic event and any group the compromised device was a part of should be considered compromised until they can remove that member and update their group's state. Some suggestions:
+
+- Clients should support and encourage self-destructing messages (ensuring that full transcript history isn't available on a device forever).
+- Clients should regularly suggest to group admins that inactive users be removed.
+- Clients should regularly suggest (or automatically) rotate a user's signing key in each of their groups.
+- Clients should encrypt group state and keys on the device using a secret value that isn't part of the group state or the user's Nostr identity key.
+- Clients should use secure enclave storage where possible.
+
+For a full discussion of the security considerations of MLS, please see the Security Considerations section of the [MLS RFC](https://www.rfc-editor.org/rfc/rfc9420.html#name-security-considerations).
+
+## Creating groups
+
+MLS Groups are created with a random 32-byte ID value that is effectively permanent. This ID should be treated as private to the group and MUST not be published to relays in any form.
+
+Clients must also ensure that the ciphersuite, capabilities, and extensions they use when creating the group are compatible with those advertised by the users they'd like to invite to the group. They can check this info via the user's published KeyPackage Events.
+
+When creating a new group, the following MLS extensions MUST be used.
+
+- [`required_capabilities`](https://docs.rs/openmls/latest/openmls/extensions/struct.RequiredCapabilitiesExtension.html)
+- [`ratchet_tree`](https://docs.rs/openmls/latest/openmls/extensions/struct.RatchetTreeExtension.html)
+- [`nostr_group_data`](https://github.com/rust-nostr/nostr/blob/master/mls/nostr-mls/src/extension.rs)
+
+And the following MLS extension is highly recommended (more [here](#keypackage-event-and-signing-keys)):
+- [`last_resort`](https://docs.rs/openmls/latest/openmls/extensions/struct.LastResortExtension.html)
+
+Changes to an MLS group are affected by first creating one or more `Proposal` events and then committing to a set of proposals in a `Commit` event. These are MLS events, not Nostr events. However, for the group state to properly evolve the Commit events (which represent a specific set of proposals - like adding a new user to the group) must be published to relays for the other group members to see. See [Group Messages](#group-events) for more information.
+
+## MLS Credentials
+
+A `Credential` in MLS is an assertion of who the user is coupled with a signing key. When constructing `Credentials` for MLS, clients MUST use the `BasicCredential` type and set the `identity` value as the 32-byte hex-encoded public key of the user's Nostr identity key. Clients MUST not allow users to change the identity field and MUST validate that all `Proposal` messages do not attempt to change the identity field on any credential in the group.
+
+A `Credential` also has an associated signing key. The initial signing key for a user is included in the KeyPackage event. The signing key MUST be different from the user's Nostr identity key. This signing key SHOULD be rotated over time to provide improved post-compromise security.
+
+## Nostr Group Data Extension
+
+As mentioned above, the `nostr_group_data` extension is a required MLS extension used to associate Nostr-specific data with an MLS group in a cryptographically secure and proveable way. This extension MUST be included as a required capability when creating a new group.
+
+The extension stores the following data about the group:
+
+- `nostr_group_id`: A 32-byte ID for the group. This is a different value from the group ID used by MLS and CAN be changed over time. This value is the group ID value used in the `h` tags when sending group message events.
+- `name`: The name of the group.
+- `description`: A short description of the group.
+- `admin_pubkeys`: An array of the hex-encoded public keys of the group admins. The MLS protocol itself does not have a concept of group admins. Clients MUST check the list of `admin_pubkeys` before making any change to the group data (anything in this extension), or before changing group membership (add/remove members), or updating any other aspect of the group itself (e.g. ciphersuite, etc.). Note, all members of the group can send `Proposal` and `Commits` messages for changes to their own credentials (e.g. updating their signing key).
+- `relays`: An array of the Nostr relay URLs that the group uses to publish and receive messages.
+
+All of these values can be updated over time using MLS `Proposal` and `Commit` events (by group admins).
+
+## KeyPackage Event and Signing Keys
+
+Each user that wishes to be reachable via MLS-based messaging MUST first publish at least one KeyPackage event. The KeyPackage Event is used to authenticate users and create the necessary `Credential` to add members to groups in an asynchronous way. Users can publish multiple KeyPackage Events with different parameters (supporting different ciphersuites or MLS extensions, for example). KeyPackages include a signing key that is used for signing MLS messages within a group. This signing key MUST not be the same as the user's Nostr identity key.
+
+KeyPackage reuse SHOULD be minimized. However, in normal MLS use, KeyPackages are consumed when joining a group. In order to reduce race conditions between invites for multiple groups using the same Key Package, Nostr clients SHOULD use "Last resort" KeyPackages. This requires the inclusion of the `last_resort` extension on the KeyPackage's capabilities (same as with the Group).
+
+It's important that clients immediately rotate a user's signing key after joining a group via a last resort key package to improve post-compromise security. The signing key (the public key included in the KeyPackage Event) is used for signing within the group. Therefore, clients implementing this NIP MUST ensure that they retain access to the private key material of the signing key for each group they are a member of.
+
+In most cases, it's assumed that clients implementing this NIP will manage the creation and rotation of KeyPackage Events.
+
+### Example KeyPackage Event
+
+```json
+  {
+    "id": <id>,
+    "kind": 443,
+    "created_at": <unix timestamp in seconds>,
+    "pubkey": <main identity pubkey>,
+    "content": "",
+    "tags": [
+        ["mls_protocol_version", "1.0"],
+        ["ciphersuite", <MLS CipherSuite ID value e.g. "0x0001">],
+        ["extensions", <An array of MLS Extension ID values e.g. "0x0001, 0x0002">],
+        ["client", <client name>, <handler event id>, <optional relay url>],
+        ["relays", <array of relay urls>],
+        ["-"]
+    ],
+    "sig": <signed with main identity key>
+}
+```
+
+- The `content` hex encoded serialized `KeyPackageBundle` from MLS.
+- The `mls_protocol_version` tag is required and MUST be the version number of the MLS protocol version being used. For now, this is `1.0`.
+- The `ciphersuite` tag is the value of the MLS ciphersuite that this KeyPackage Event supports. [Read more about ciphersuites in MLS](https://www.rfc-editor.org/rfc/rfc9420.html#name-mls-cipher-suites).
+- The `extensions` tag is an array of MLS extension IDs that this KeyPackage Event supports. [Read more about MLS extensions](https://www.rfc-editor.org/rfc/rfc9420.html#name-extensions).
+- (optional) The `client` tag helps other clients manage the user experience when they receive group invites but don't have access to the signing key.
+- The `relays` tag identifies each of the relays that the client will attempt to publish this KeyPackage event. This allows for deletion of KeyPackage Events at a later date.
+- (optional) The `-` tag can be used to ensure that KeyPackage Events are only published by their authenticated author. Read more in [NIP-70](70.md)
+
+### Deleting KeyPackage Events
+
+Clients SHOULD delete the KeyPackage Event on all the listed relays any time they successfully process a group request event for a given KeyPackage Event. Clients MAY also create a new KeyPackage Event at the same time.
+
+If clients cannot process a Welcome message (e.g. because the signing key was generated on another client), clients MUST not delete the KeyPackage Event and SHOULD show a human-understandable error to the user.
+
+### Rotating Signing Keys
+
+Clients MUST regularly rotate the user's signing key in each group that they are a part of. The more often the signing key is rotated the stronger the post-compromise security. This rotation is done via `Proposal` and `Commit` events and broadcast to the group via a Group Event. [Read more about forward secrecy and post-compromise security inherent in MLS](https://www.rfc-editor.org/rfc/rfc9420.html#name-forward-secrecy-and-post-co).
+
+### KeyPackage Relays List Event
+
+A `kind: 10051` event indicates the relays that a user will publish their KeyPackage Events to. The event MUST include a list of relay tags with relay URIs. These relays SHOULD be readable by anyone the user wants to be able to contact them.
+
+```json
+{
+  "kind": 10051,
+  "tags": [
+    ["relay", "wss://inbox.nostr.wine"],
+    ["relay", "wss://myrelay.nostr1.com"],
+  ],
+  "content": "",
+  //...other fields
+}
+```
+
+### Welcome Event
+
+When a new user is added to a group via an MLS `Commit` message. The member who sends the `Commit` message to the group is responsible for sending the user being added to the group a Welcome Event. This Welcome Event is sent to the user as a [NIP-59](59.md) gift-wrapped event. The Welcome Event gives the new member the context they need to join the group and start sending messages.
+
+Clients creating the Welcome Event SHOULD wait until they have received acknowledgement from relays that their Group Event with the `Commit` has been received before publishing the Welcome Event.
+
+```json
+{
+   "id": <id>,
+   "kind": 444,
+   "created_at": <unix timestamp in seconds>,
+   "pubkey": <nostr identity pubkey of sender>,
+   "content": <serialized Welcome object>,
+   "tags": [
+      ["e", <ID of the KeyPackage Event used to add the user to the group>],
+      ["relays", <array of relay urls>],
+   ],
+   "sig": <NOT SIGNED>
+}
+```
+
+- The `content` field is required and is a serialized MLSMessage object containing the MLS `Welcome` object.
+- The `e` tag is required and is the ID of the KeyPackage Event used to add the user to the group.
+- The `relays` tag is required and is a list of relays clients should query for Group Events.
+
+Welcome Events are then sealed and gift-wrapped as detailed in [NIP-59](59.md) before being published. Like all events that are sealed and gift-wrapped, `kind: 444` events MUST never be signed. This ensures that if they were ever leaked they would not be publishable to relays.
+
+#### Large Groups
+
+For groups above ~150 participants, welcome messages will become larger than the maximum event size allowed by Nostr. There is currently work underway on the MLS protocol to support "light" client welcomes that don't require the full Ratchet Tree state to be sent to the new member. This section will be updated with recommendations for how to handle large groups.
+
+## Group Events
+
+Group Events are all the messages that are sent within a group. This includes all "control" events that update the shared group state over time (`Proposal`, `Commit`) and messages sent between members of the group (`Application` messages).
+
+Group Events are published using an ephemeral Nostr keypair to obfuscate the number and identity of group participants. Clients MUST use a new Nostr keypair for each Group Event they publish.
+
+```json
+{
+   "id": <id>,
+   "kind": 445,
+   "created_at": <unix timestamp in seconds>,
+   "pubkey": <ephemeral sender pubkey>,
+   "content": <NIP-44 encrypted serialized MLSMessage object>,
+   "tags": [
+      ["h", <group id>]
+   ],
+   "sig": <signed with ephemeral sender key>
+}
+```
+- The `content` field is a [tls-style](https://www.rfc-editor.org/rfc/rfc9420.html#name-the-message-mls-media-type) serialized [`MLSMessage`](https://www.rfc-editor.org/rfc/rfc9420.html#section-6-4) object which is then encrypted according to [NIP-44](44.md). However, instead of using the sender and receivers keys to derive a `conversation_key`, the NIP-44 encryption is done using a Nostr keypair generated from the MLS [`exporter_secret`](https://www.rfc-editor.org/rfc/rfc9420.html#section-8.5) to calculate the `conversation_key` value. Essentially, you use the hex-encoded `exporter_secret` value as the private key (used as the sender key), calculate the public key for that private key (used as the receiver key), and then proceed with the standard NIP-44 scheme to encrypt and decrypt messages.
+- The `exporter_secret` value should be generated with a 32-byte length and labeled `nostr`. This `exporter_secret` value is rotated on each new epoch in the group. Clients should generate a new 32-byte value each time they process a valid `Commit` message.
+- The `pubkey` is the hex-encoded public key of the ephemeral sender.
+- The `h` tag is the nostr group ID value (from the Nostr Group Data Extension).
+
+### Application Messages
+
+Application messages are the messages that are sent within the group by members. These are contained within the `MLSMessage` object. The format of these messages should be unsigned Nostr events of the appropriate kind. For normal DM or group messages, clents SHOULD use `kind: 9` chat message events. If the user reacts to a message, it would be a `kind: 7` event, and so on.
+
+This means that once the application message has been decrypted and deserialized, clients can store those events and treat them as any other Nostr event, effectively creating a private Nostr feed of the group's activity and taking advantage of all the features of Nostr.
+
+These inner unsigned Nostr events MUST use the member's Nostr identity key for the `pubkey` field and clients MUST check that the identity of them member who sent the message matches the pubkey of the inner Nostr event.
+
+These Nostr events MUST remain **unsigned** to ensure that if they were to leak to relays they would not be published publicly. These Nostr events MUST not include any "h" tags or other tags that would identify the group that they belong to.
+
+### `Commit` Message race conditions
+
+The MLS protocol is resilient to almost all messages arriving out of order. However, the order of `Commit` messages is important for the group state to move forward from one epoch to the next correctly. Given Nostr's nature as a decentralized network, it is possible for a client to receive 2 or more `Commit` messages all attempting to update to a new epoch at the same time.
+
+Clients sending commit messages MUST wait until they receive acknowledgement from at least one relay that their Group Message Event with the `Commit` has been received before applying the commit to their own group state.
+
+If a client receives 2 or more `Commit` messages attempting to change same epoch, they MUST apply only one of the `Commit` messages they receive, determined by the following:
+
+1. Using the `created_at` timestamp on the kind `445` event. The `Commit` with the lowest value for `created_at` is the message to be applied. The other `Commit` message is discarded.
+2. If the `created_at` timestamp is the same for two or more `Commit` messages, the `Commit` message with the lowest value for `id` field is the message to be applied.
+
+Clients SHOULD retain previous group state for a short period of time in order to recover from forked group state.
--- a/README.md
+++ b/README.md
@@ -11,11 +11,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [Message Types](#message-types)
  - [Client to Relay](#client-to-relay)
  - [Relay to Client](#relay-to-client)
- [Standardized Tags](#standardized-tags)
+- [Common Tags](#common-tags)
 - [Criteria for acceptance of NIPs](#criteria-for-acceptance-of-nips)
 - [Is this repository a centralizing factor?](#is-this-repository-a-centralizing-factor)
 - [How this repository works](#how-this-repository-works)
- [Breaking Changes](#breaking-changes)
 - [License](#license)

 ---
@@ -44,7 +43,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) --- **unrecommended**: adds unecessary burden for little gain
+- [NIP-26: Delegated Event Signing](26.md) --- **unrecommended**: adds unnecessary burden for little gain
 - [NIP-27: Text Note References](27.md)
 - [NIP-28: Public Chat](28.md)
 - [NIP-29: Relay-based Groups](29.md)
@@ -59,6 +58,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-39: External Identities in Profiles](39.md)
 - [NIP-40: Expiration Timestamp](40.md)
 - [NIP-42: Authentication of clients to relays](42.md)
+- [NIP-43: Relay Access Metadata and Requests](43.md)
 - [NIP-44: Encrypted Payloads (Versioned)](44.md)
 - [NIP-45: Counting results](45.md)
 - [NIP-46: Nostr Remote Signing](46.md)
@@ -99,13 +99,16 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-90: Data Vending Machines](90.md)
 - [NIP-92: Media Attachments](92.md)
 - [NIP-94: File Metadata](94.md)
- [NIP-96: HTTP File Storage Integration](96.md)
+- [NIP-96: HTTP File Storage Integration](96.md) --- **unrecommended**: replaced by blossom APIs
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
+- [NIP-A0: Voice Messages](A0.md)
 - [NIP-B0: Web Bookmarks](B0.md)
 - [NIP-B7: Blossom](B7.md)
+- [NIP-BE: Nostr BLE Communications Protocol](BE.md)
 - [NIP-C0: Code Snippets](C0.md)
 - [NIP-C7: Chats](C7.md)
+- [NIP-EE: E2EE Messaging using MLS Protocol](EE.md)

 ## Event Kinds
 | kind          | description                     | NIP                                    |
@@ -142,6 +145,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `44`          | Channel Mute User               | [28](28.md)                            |
 | `62`          | Request to Vanish               | [62](62.md)                            |
 | `64`          | Chess (PGN)                     | [64](64.md)                            |
+| `443`         | KeyPackage                      | [EE](EE.md)                            |
+| `444`         | Welcome Message                 | [EE](EE.md)                            |
+| `445`         | Group Event                     | [EE](EE.md)                            |
 | `818`         | Merge Requests                  | [54](54.md)                            |
 | `1018`        | Poll Response                   | [88](88.md)                            |
 | `1021`        | Bid                             | [15](15.md)                            |
@@ -151,9 +157,13 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1063`        | File Metadata                   | [94](94.md)                            |
 | `1068`        | Poll                            | [88](88.md)                            |
 | `1111`        | Comment                         | [22](22.md)                            |
+| `1222`        | Voice Message                   | [A0](A0.md)                            |
+| `1244`        | Voice Message Comment           | [A0](A0.md)                            |
 | `1311`        | Live Chat Message               | [53](53.md)                            |
 | `1337`        | Code Snippet                    | [C0](C0.md)                            |
 | `1617`        | Patches                         | [34](34.md)                            |
+| `1618`        | Pull Requests                   | [34](34.md)                            |
+| `1619`        | Pull Request Updates            | [34](34.md)                            |
 | `1621`        | Issues                          | [34](34.md)                            |
 | `1622`        | Git Replies (deprecated)        | [34](34.md)                            |
 | `1630`-`1633` | Status                          | [34](34.md)                            |
@@ -172,6 +182,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `7374`        | Reserved Cashu Wallet Tokens    | [60](60.md)                            |
 | `7375`        | Cashu Wallet Tokens             | [60](60.md)                            |
 | `7376`        | Cashu Wallet History            | [60](60.md)                            |
+| `7516`        | Geocache log                    | [geocaching][geocaching]               |
+| `7517`        | Geocache proof of find          | [geocaching][geocaching]               |
+| `8000`        | Add User                        | [43](43.md)                            |
+| `8001`        | Remove User                     | [43](43.md)                            |
 | `9000`-`9030` | Group Control Events            | [29](29.md)                            |
 | `9041`        | Zap Goal                        | [75](75.md)                            |
 | `9321`        | Nutzap                          | [61](61.md)                            |
@@ -195,12 +209,16 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `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)               |
+| `10051`       | KeyPackage Relays List          | [EE](EE.md)                            |
 | `10063`       | User server list                | [Blossom][blossom]                     |
-| `10096`       | File storage server list        | [96](96.md)                            |
+| `10096`       | File storage server list        | [96](96.md) (deprecated)               |
 | `10166`       | Relay Monitor Announcement      | [66](66.md)                            |
+| `10312`       | Room Presence                   | [53](53.md)                            |
+| `10377`       | Proxy Announcement              | [Nostr Epoxy][nostr-epoxy]             |
+| `11111`       | Transport Method Announcement   | [Nostr Epoxy][nostr-epoxy]             |
 | `13194`       | Wallet Info                     | [47](47.md)                            |
+| `13534`       | Membership Lists                | [43](43.md)                            |
 | `17375`       | Cashu Wallet Event              | [60](60.md)                            |
-| `17375`       | Ecash Mint Recommendation       | [87](87.md)                            |
 | `21000`       | Lightning Pub RPC               | [Lightning.Pub][lnpub]                 |
 | `22242`       | Client Authentication           | [42](42.md)                            |
 | `23194`       | Wallet Request                  | [47](47.md)                            |
@@ -208,6 +226,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `24133`       | Nostr Connect                   | [46](46.md)                            |
 | `24242`       | Blobs stored on mediaservers    | [Blossom][blossom]                     |
 | `27235`       | HTTP Auth                       | [98](98.md)                            |
+| `28934`       | Join Request                    | [43](43.md)                            |
+| `28935`       | Invite Request                  | [43](43.md)                            |
+| `28936`       | Leave Request                   | [43](43.md)                            |
 | `30000`       | Follow sets                     | [51](51.md)                            |
 | `30001`       | Generic lists                   | 51 (deprecated)                        |
 | `30002`       | Relay sets                      | [51](51.md)                            |
@@ -232,6 +253,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30166`       | Relay Discovery                 | [66](66.md)                            |
 | `30267`       | App curation sets               | [51](51.md)                            |
 | `30311`       | Live Event                      | [53](53.md)                            |
+| `30312`       | Interactive Room                | [53](53.md)                            |
+| `30313`       | Conference Event                | [53](53.md)                            |
 | `30315`       | User Statuses                   | [38](38.md)                            |
 | `30388`       | Slide Set                       | [Corny Chat][cornychat-slideset]       |
 | `30402`       | Classified Listing              | [99](99.md)                            |
@@ -253,6 +276,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `34550`       | Community Definition            | [72](72.md)                            |
 | `38172`       | Cashu Mint Announcement         | [87](87.md)                            |
 | `38173`       | Fedimint Announcement           | [87](87.md)                            |
+| `37516`       | Geocache listing                | [geocaching](geocaching)               |
 | `38383`       | Peer-to-peer Order events       | [69](69.md)                            |
 | `39000-9`     | Group metadata events           | [29](29.md)                            |
 | `39089`       | Starter packs                   | [51](51.md)                            |
@@ -270,6 +294,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 [NKBIP-03]: https://wikistr.com/nkbip-03*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
 [blossom]: https://github.com/hzrd149/blossom
 [Tidal-nostr]: https://wikistr.com/tidal-nostr
+[geocaching]: https://nostrhub.io/naddr1qvzqqqrcvypzppscgyy746fhmrt0nq955z6xmf80pkvrat0yq0hpknqtd00z8z68qqgkwet0vdskx6rfdenj6etkv4h8guc6gs5y5
+[nostr-epoxy]: https://github.com/Origami74/nostr-epoxy-reverse-proxy

 ## Message types

@@ -295,12 +321,13 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `AUTH`   | used to send authentication challenges                  | [42](42.md) |
 | `COUNT`  | used to send requested event counts to clients          | [45](45.md) |

-## Standardized Tags
+## Common Tags

 | name              | value                                | other parameters                | NIP                                                |
 | ----------------- | ------------------------------------ | ------------------------------- | -------------------------------------------------- |
 | `a`               | coordinates to an event              | relay URL                       | [01](01.md)                                        |
 | `A`               | root address                         | relay URL                       | [22](22.md)                                        |
+| `c`               | commit id                            |                                 | [34](34.md)                                       |
 | `d`               | identifier                           | --                              | [01](01.md)                                        |
 | `e`               | event id (hex)                       | relay URL, marker, pubkey (hex) | [01](01.md), [10](10.md)                           |
 | `E`               | root event id                        | relay URL                       | [22](22.md)                                        |
@@ -329,6 +356,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `alt`             | summary                              | --                              | [31](31.md)                                        |
 | `amount`          | millisatoshis, stringified           | --                              | [57](57.md)                                        |
 | `bolt11`          | `bolt11` invoice                     | --                              | [57](57.md)                                        |
+| `branch-name`     | branch name suggestion               | --                              | [34](34.md)                                        |
 | `challenge`       | challenge string                     | --                              | [42](42.md)                                        |
 | `client`          | name, address                        | relay URL                       | [89](89.md)                                        |
 | `clone`           | git clone URL                        | --                              | [34](34.md)                                        |
@@ -342,6 +370,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `expiration`      | unix timestamp (string)              | --                              | [40](40.md)                                        |
 | `file`            | full path (string)                   | --                              | [35](35.md)                                        |
 | `goal`            | event id (hex)                       | relay URL                       | [75](75.md)                                        |
+| `merge-base`      | commit id                            |                                 | [34](34.md)                                        |
+| `HEAD`            | `ref: refs/heads/<branch-name>`      |                                 | [34](34.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)                                        |
@@ -390,10 +420,6 @@ Standards may emerge in two ways: the first way is that someone starts doing som

 These two ways of standardizing things are supported by this repository. Although the second is preferred, an effort will be made to codify standards emerged outside this repository into NIPs that can be later referenced and easily understood and implemented by others -- but obviously as in any human system discretion may be applied when standards are considered harmful.

-## Breaking Changes
-
-[Breaking Changes](BREAKING.md)
-
 ## License

 All NIPs are public domain.
Author	SHA1	Message	Date
KotlinGeekDev	f310614122	Complete removal of hashtag and url tags from bookmarks. (#2141 )	2025-12-01 20:12:23 -05:00
Cody Tseng	a4dadca077	Improve generic reposts for replaceable events (#2132 )	2025-12-01 17:07:37 -08:00
Valentino Giudice	2a33cceff6	Improve NIP-C0 (#2138 )	2025-11-26 09:05:45 -03:00
Vitor Pamplona	844c6fe15c	NIP-51: Removes hashtags and `r` tags from bookmarks (#2133 )	2025-11-21 20:04:54 -03:00
Vitor Pamplona	e0a2980d7a	NIP-59: Adds GiftWrap deletion requests (#2131 )	2025-11-21 07:11:35 -03:00
hodlbod	c45f504537	Add self to NIP 11 (#1764 ) Co-authored-by: Jon Staab <shtaab@gmail.com>	2025-11-17 10:50:04 -08:00
AsaiToshiya	d8e57865d7	add NIP-BE to README.	2025-11-15 05:27:17 +09:00
Francisco Calderón	f63c00213f	Add order expiration support to NIP-69 (#2118 )	2025-11-13 13:41:04 -05:00
KoalaSat	a47c460415	NIP-BE: Add BLE messaging and device synchronization (#1979 )	2025-11-11 11:05:09 -03:00
AsaiToshiya	45668383e3	add NIP-43 and its kinds to README. (#2110 )	2025-11-04 05:46:47 -08:00
Rob Woodgate	62f0b14ae8	Added base "unit" tag to NutZap kind:9321 event (#1915 )	2025-10-31 15:59:35 +02:00
hodlbod	3ec830cd23	refine wording of nip 17, include kind 7 reactions (#2098 ) Co-authored-by: Jon Staab <shtaab@gmail.com>	2025-10-30 15:53:24 -04:00
Leo Wandersleb	cc77619af8	replace jsonc syntax highlighting for javascript (#2100 )	2025-10-30 05:30:15 -07:00
hodlbod	8054526b87	Add relay access requests (#1079 ) Co-authored-by: Jonathan Staab <shtaab@gmail.com>	2025-10-30 07:44:48 -03:00
alltheseas	520b901629	NIP-17: Clarify client event publishing instructions (#2097 )	2025-10-28 10:49:19 -04:00
alltheseas	bcaad2957d	Enhance metadata/timestamp protection guidance in NIP-59 (#2095 )	2025-10-27 10:56:47 -07:00
DanConwayDev	6e6b9877b3	NIP-34: add PR and PR update events (#1966 )	2025-10-16 12:08:48 -05:00
Vitor Pamplona	3f79b7fde2	NIP-18: Normalize its `q` tags with the definition on NIP-22 (#1746 )	2025-10-16 04:44:37 -07:00
Kieran	a3c5554e34	Add `duration` & `bitrate` to NIP-71 (#1723 ) Co-authored-by: Vitor Pamplona <vitor@vitorpamplona.com>	2025-10-15 16:15:27 -04:00
Vitor Pamplona	7b24bf803f	NIP-37: Improving Draft events (#2016 )	2025-10-15 16:09:36 -04:00
greenart7c3	d54c426709	[NIP 55] - Instructions on how to use the get_public_key method with content resolver (#2086 )	2025-10-13 11:21:07 -07:00
Sandwich	179e421011	nip66: tags shouldn't have integers (#2085 )	2025-10-13 05:26:14 -07:00
Vitor Pamplona	74681c3c14	NIP-45 is not a subscription. Changing to query id to reduce confusion. (#2083 )	2025-10-08 17:43:37 -05:00
Pablo Fernandez	2ace01cf1a	NWC Deep Links (#1777 )	2025-10-08 14:34:47 +03:00
Sandwich	b516adbf42	Fix fundamentally incorrect assertions in NIP-66 (#2067 )	2025-09-20 07:39:40 -03:00
Yoji Shidara	90fcf4a44e	NIP-11: add comma and remove empty lines (#2066 )	2025-09-19 07:55:42 -04:00
hodlbod	abe6fb959c	Remove lud06 field (#2065 ) Co-authored-by: Jon Staab <shtaab@gmail.com>	2025-09-18 17:09:53 -07:00
AsaiToshiya	4b19bf2e40	delete BREAKING.md (#2058 )	2025-09-18 12:30:58 +09:00
Roland	7dfb3b35d8	docs: clarify NIP-47 zap request metadata (#2064 )	2025-09-17 08:07:11 -04:00
Roland	400d975da3	feat: add metadata to NIP-47 make_invoice and payment commands (#2063 )	2025-09-15 09:42:07 -07:00
Rosano	e35a1bebbc	Quote values (#2057 ) Co-authored-by: Vitor Pamplona <vitor@vitorpamplona.com>	2025-09-10 15:48:05 -04:00
RΞDKAZ⚡	8b541fe8cd	Curation sets (kind-30005) should be regular event `e` tag and not `a`. (#2059 )	2025-09-10 07:32:39 -03:00
Vitor Pamplona	c3f92ca577	Deprecates NIP-96 (#2047 )	2025-09-09 19:24:13 -03:00
AsaiToshiya	020609ed9f	standard -> common	2025-09-09 19:01:01 +09:00
Vitor Pamplona	5d81c9100e	Removing the idea of "Standard" Tags (#2055 )	2025-09-08 15:25:05 -03:00
Yoji Shidara	3a126a51a6	Typos (#2054 )	2025-09-07 06:04:01 -07:00
Vitor Pamplona	4c5d5fff99	Allow multi-user AUTH (#1881 ) Co-authored-by: Leo Wandersleb <leo@leowandersleb.de>	2025-09-06 09:52:22 -03:00
SubatomicPlanets	d6fe55a6ad	Fix weird list in NIP-99 (#2053 )	2025-09-06 09:38:46 -03:00
Riccardo Balbo	7c4a2cb829	NIP-47: mark "state" field as optional in make_invoice response for backward compatibility (#2046 )	2025-09-04 11:12:45 -04:00
Vitor Pamplona	3760a6e308	NIP-53 Text Refinements and formatting fixes (#2052 )	2025-09-04 11:50:33 -03:00
Alex Gleason	8c45ff5d96	NIP-11: fix default_limit (#2049 )	2025-09-02 22:39:19 -03:00
AsaiToshiya	fd9c627b36	add NIP-EE kinds (#2044 )	2025-08-28 23:15:52 +09:00
Jeff Gardner	fe114c6473	Fix link to nostr_data_extension and clarify how to use exporter_secret with NIP-44 (#2043 ) Co-authored-by: hodlbod <jstaab@protonmail.com>	2025-08-27 13:24:50 -07:00
Jeff Gardner	581452e845	Add NIP-EE: E2EE messaging using MLS (#1427 )	2025-08-27 09:03:06 -07:00
Vitor Pamplona	1f4d6d1c46	NIP-51: Updates lists to NIP-44, deprecates NIP-04 (#2034 )	2025-08-25 09:09:44 -07:00
AsaiToshiya	3f4c696f24	clean up B0. (#2039 )	2025-08-22 16:20:13 -07:00
Oscar Merry	84e0b44f93	NIP-25: Add External Content Reactions (#2020 )	2025-08-22 09:44:53 -07:00
Yoji Shidara	0d7c5ef0f8	NIP-61: Fix heading levels (#2030 )	2025-08-19 09:12:04 -07:00
Yoji Shidara	d5bfb6e848	NIP-72: Fix heading levels (#2031 )	2025-08-19 09:11:55 -07:00
Yoji Shidara	38bc891e67	NIP-89: Fix heading levels (#2032 )	2025-08-19 09:11:47 -07:00
Yoji Shidara	c222f71102	NIP-60: Fix heading levels (#2029 )	2025-08-19 09:11:40 -07:00
Yoji Shidara	68e5d0ada4	NIP-90: Fix heading levels (#2033 )	2025-08-19 09:11:14 -07:00
Awiteb	4b14bf831f	nip34: Add `HEAD` tag to the README (#2017 )	2025-08-18 11:11:50 -07:00
hodlbod	212f52a90a	Add kinds used by nostr epoxy (#1976 ) Co-authored-by: Jon Staab <shtaab@gmail.com>	2025-08-18 10:32:18 -07:00
Yoji Shidara	b333434223	NIP-54: Fix heading levels (#2021 )	2025-08-18 10:18:08 -07:00
Yoji Shidara	b1720f4fdc	NIP-55: Fix heading levels (#2022 )	2025-08-18 10:17:27 -07:00
Yoji Shidara	bc96d5f447	NIP-59: Fix heading levels (#2023 )	2025-08-18 10:16:42 -07:00
Yoji Shidara	645986da49	README: Fix brackets to use references correctly (#2026 )	2025-08-18 10:16:23 -07:00
Yoji Shidara	15a49873ea	NIP-38: Fix heading levels (#2015 )	2025-08-13 09:52:51 -04:00
Yoji Shidara	0e91133320	Fix typos (#2014 )	2025-08-13 21:26:30 +09:00
Yoji Shidara	252f746010	NIP-26: Fix typos (#2013 )	2025-08-13 18:07:45 +09:00
Yoji Shidara	01c6bc9ea7	NIP-22: Fix typo (#2012 )	2025-08-13 18:06:32 +09:00
Awiteb	7dec812f99	nip22: fix example type for external URL (#2011 )	2025-08-11 17:26:05 -04:00
Yoji Shidara	739f3c5263	NIP-24: Fix heading levels (#2009 )	2025-08-11 19:37:53 +09:00
Yoji Shidara	8830525250	NIP-21: Fix markup issue by closing backtick (#2008 )	2025-08-11 19:35:36 +09:00
fiatjaf_	b224b0ecb8	include missing "k" tag in some reactions (#2001 )	2025-08-04 17:31:37 -03:00
G!l	ce130e504a	NIP-52: Add collaborative calendar event request (#1970 )	2025-08-04 20:28:18 +00:00
hodlbod	0b45265a93	Clean up nip 66 (#1986 ) Co-authored-by: Jon Staab <shtaab@gmail.com>	2025-08-04 15:47:20 +00:00
hodlbod	e33f5cd38f	Add geocaching kinds (#1977 ) Co-authored-by: Jon Staab <shtaab@gmail.com>	2025-08-01 19:39:33 +00:00
Adithya Vardhan	0595d438aa	NIP-47: add state to transactions (#1933 )	2025-07-31 09:26:27 -04:00
Jeremy Klein	f30a43bd37	[NWC] Add an encryption tag to negotiate upgrading to NIP44. (#1780 ) Co-authored-by: Roland <33993199+rolznz@users.noreply.github.com>	2025-07-31 09:21:18 -04:00
DanConwayDev	faba3f016d	NIP-34: `mention` marker ~> `q` tag NIP-10 update (#1998 )	2025-07-31 08:43:14 -04:00
AsaiToshiya	e6de76f76b	remove duplicate kind (#1995 )	2025-07-29 15:28:29 -03:00
reis	aefad1876b	nip25: remove duplicate (#1993 )	2025-07-29 08:42:47 -03:00
Fabian	4984b057c2	Update audio format and waveform recommendation for NIP-A0: Voice Messages (#1990 )	2025-07-27 16:23:50 -03:00
AsaiToshiya	9be455bf57	fix A0 nip number	2025-07-24 23:04:12 +09:00
Fabian	e50f37a527	NIP-A0: Voice Messages (#1984 )	2025-07-23 17:31:55 -03:00
AsaiToshiya	074b8eeb01	add kinds 10312, 30312 and 30313 (from nip53)	2025-07-19 01:17:44 +09:00