grammar.

update flow and add images.
nip4e: decoupling encryption from identity
2025-12-09 00:28:51 +00:00 · 2025-10-08 09:52:21 +00:00 · 2025-10-08 09:48:57 +00:00 · 2025-10-08 09:48:57 +00:00 · 2025-08-18 11:11:50 -07:00 · 2025-08-18 10:32:18 -07:00
23 changed files with 392 additions and 282 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/18.md
+++ b/18.md
@@ -40,6 +40,5 @@ 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.
-
--- 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.
--- 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
@@ -45,7 +45,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>"]
  ]
@@ -150,7 +150,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>"]
--- 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/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
@@ -295,6 +335,7 @@ Response:
    "result_type": "make_invoice",
    "result": {
        "type": "incoming", // "incoming" for invoices, "outgoing" for payments
+        "state": "pending",
        "invoice": "string", // encoded invoice, optional
        "description": "string", // invoice's description, optional
        "description_hash": "string", // invoice's description hash, optional
@@ -328,6 +369,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)
        "invoice": "string", // encoded invoice, optional
        "description": "string", // invoice's description, optional
        "description_hash": "string", // invoice's description hash, optional
@@ -376,6 +418,7 @@ Response:
        "transactions": [
            {
               "type": "incoming", // "incoming" for invoices, "outgoing" for payments
+               "state": "pending", // can be "pending", "settled", "expired" (for invoices) or "failed" (for payments)
               "invoice": "string", // encoded invoice, optional
               "description": "string", // invoice's description, optional
               "description_hash": "string", // invoice's description hash, optional
@@ -452,6 +495,7 @@ Notification:
    "notification_type": "payment_received",
    "notification": {
        "type": "incoming",
+        "state": "settled",
        "invoice": "string", // encoded invoice
        "description": "string", // invoice's description, optional
        "description_hash": "string", // invoice's description hash, optional
@@ -477,6 +521,7 @@ Notification:
    "notification_type": "payment_sent",
    "notification": {
        "type": "outgoing",
+        "state": "settled",
        "invoice": "string", // encoded invoice
        "description": "string", // invoice's description, optional
        "description_hash": "string", // invoice's description hash, optional
@@ -499,6 +544,71 @@ 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.

@@ -513,6 +623,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"
--- a/4e.md
+++ b/4e.md
@@ -0,0 +1,78 @@
+NIP-4e
+======
+
+Decoupling encryption from identity
+-----------------------------------
+
+`optional` `draft`
+
+This NIP describes a system for users to share private data between their own devices that doesn't rely on all devices holding the user account private key.
+
+### The problem
+
+Currently many NIPs rely on encrypting data from the user to themselves -- such that the data can be accessed later on a different device -- using NIP-04 or NIP-44 and the users as both the sender and the receiver, e.g. [NIP-51](51.md) and [NIP-60](60.md). This works fine, but it assumes all devices have direct or indirect access to the same secret key. This assumption cannot be fulfilled in the case of approaches where the key isn't known, such as when using bunkers powered by FROST, MuSig2 or hosted secure enclaves.
+
+Also, in some use cases having the encryption key be on device can drastically increase performance of encrypting and decrypting stuff, and such a thing is not possible to do while also using [NIP-46](46.md) for keeping the user's main Nostr key safer. It's also not possible to perform any encryption while offline if the encryption keys live in a remote bunker.
+
+There are probably other advantages to not tying the user's identity to the keys used for more mundane things such as encryption, which we can write here later.
+
+### The solution
+
+1. Every client can generate a new _client key_ and store it locally, while making its public key public in a Nostr event.
+2. The first client to come into the world will generate a random _encryption key_.
+3. When another client's _client key_ is spotted, the client that knows the original encryption key encrypts that key to the target client's _client key_ using [NIP-44](44.md) and sends it out.
+4. Encryption and decryption are performed using the _encryption key_, not the user's _identity key_.
+
+### The protocol flow
+
+1. **Alice** creates a keypair `(a, A)` (`a` is the secret key, `A` is the public key) on some onboarding website, say **jump.nostrstart.com**.
+2. `A` is Alice's main identity on Nostr, her npub will be, say, `npub1A`;
+3. Alice installs a client called **Cope**, **Cope** somehow realizes Alice can't use her `a` secret key for encryption because it's behind a FROST bunker, so **Cope** creates an encryption keypair `(e, E)`. This doesn't change Alice's identity, it will only be used for encryption.
+4. **Cope** publishes an event (`kind:10044`) to announce this to the world:
+
+```jsonc
+{
+  "kind": 10044,
+  "pubkey": "<A>",
+  "tags": [
+    ["n", "<E>"] // `n` is for "encryption", doesn't matter
+  ]
+}
+```
+
+5. Now **Bob** (keypair `(b, B)`) will send a DM to **Alice**. Because Bob's client fetched Alice's `kind:10044` event, instead of computing the conversation key with `ecdh(b, A)` he does `ecdh(b, E) = S`
+6. Because Alice knows `e`, she can decrypt Bob's message doing `ecdh(e, B) = S` and all is good
+7. Now the fun part starts: Alice has decided to use a client called **Tortilla** to chat on her phone, and **Tortilla** wants to do encryption stuff.
+8. **Tortilla** sees that Alice has a `kind:10044` published, which means **Tortilla** won't create a new key, **Tortilla** will have to ask for **Cope** to share that key securely. So **Tortilla** generates a local keypair `(t, T)` that won't be shown or leave the device ever, and **Tortilla** publishes an announcement (`kind:4454`) for that local key (signed by Alice):
+
+```jsonc
+{
+  "kind": 4454,
+  "pubkey": "<A>",
+  "tags": [
+    ["client", "Tortilla on Android"],
+    ["pubkey", "<T>"]
+  ]
+}
+```
+
+9. **Tortilla** cannot proceed without knowing the secret key `e`, so it has to tell the user to turn **Cope** on.
+10. Alice opens up **Cope** and **Cope** immediately looks for all `kind:4454` events from Alice, and sees that there is this app called "Tortilla on Android" signed by Alice herself, so **Cope** publishes the secret key `e`  nip44-encrypted to `ecdh(c, T)` -- in which `c` is the secret key of a keypair that **Cope** has just generated locally. **Cope** does that using a new event, `kind:4455`:
+
+```jsonc
+{
+  "kind": 4455,
+  "pubkey": "<A>",
+  "tags": [
+    ["P", "<C>"],
+    ["p", "<T>"]
+  ],
+  "content": "<nip44(content=e, conversationkey=get_conversation_key(c, T))>"
+}
+```
+
+11. Immediately **Tortilla** wakes up and sees the `kind:4455` that has just been published by **Cope**, decrypts the content using `ecdh(t, C)` and now **Tortilla** also knows the secret key `e`. **Tortilla** can now decrypt and encrypt the same things **Cope** could before.
+
+### The protocol flow again, now in a colorful infographic
+
+![](https://cdn.azzamo.net/89c543d261ad0d665c1dea78f91e527c2e39e7fe503b440265a3c47e63c9139f.png)
--- 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/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,7 @@ 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
+#### Methods

 - **get_public_key**
  - params:
@@ -482,7 +482,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 +496,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 +547,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
@@ -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,7 @@ 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
+## An Example

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

@@ -108,7 +108,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 +124,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 +142,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 +160,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/61.md
+++ b/61.md
@@ -53,6 +53,7 @@ Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu
        [ "proof", "{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}" ],
        [ "u", "https://stablenut.umint.cash" ],
        [ "e", "<nutzapped-event-id>", "<relay-hint>" ],
+        [ "k", "<nutzapped-kind>"],
        [ "p", "e9fbced3a42dcf551486650cc752ab354347dd413b307484e4fd1818ab53f991" ], // recipient of nutzap
    ]
 }
@@ -77,7 +78,7 @@ 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> }`.

--- a/66.md
+++ b/66.md
@@ -6,137 +6,46 @@ 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` - An event kind accepted by the relay
+- `!k` - An event kind not accepted by the relay
+- `g` - A [NIP-52](https://github.com/nostr-protocol/nips/blob/master/52.md) geohash
+- `l` - A language tag

-### 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 +53,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 ]
  ]
-} 
+}
 ```

-## `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 +82,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/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/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/README.md
+++ b/README.md
@@ -44,7 +44,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-23: Long-form Content](23.md)
 - [NIP-24: Extra metadata fields and tags](24.md)
 - [NIP-25: Reactions](25.md)
- [NIP-26: Delegated Event Signing](26.md) --- **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)
@@ -102,6 +102,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-96: HTTP File Storage Integration](96.md)
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
+- [NIP-A0: Voice Messages](A0.md)
 - [NIP-B0: Web Bookmarks](B0.md)
 - [NIP-B7: Blossom](B7.md)
 - [NIP-C0: Code Snippets](C0.md)
@@ -151,6 +152,8 @@ 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)                            |
@@ -172,6 +175,8 @@ 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]               |
 | `9000`-`9030` | Group Control Events            | [29](29.md)                            |
 | `9041`        | Zap Goal                        | [75](75.md)                            |
 | `9321`        | Nutzap                          | [61](61.md)                            |
@@ -198,9 +203,11 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10063`       | User server list                | [Blossom][blossom]                     |
 | `10096`       | File storage server list        | [96](96.md)                            |
 | `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)                            |
 | `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)                            |
@@ -232,6 +239,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 +262,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 +280,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

@@ -342,6 +354,7 @@ 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)                                        |
+| `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)                                        |
Author	SHA1	Message	Date
fiatjaf	5de76542c3	grammar.	2025-10-08 09:52:21 +00:00
fiatjaf	db85e13a58	update flow and add images.	2025-10-08 09:48:57 +00:00
fiatjaf	44af48327f	nip4e: decoupling encryption from identity	2025-10-08 09:48:57 +00: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