nip46: simple public key login using kind:10046

05.md

@@ -10,7 +10,7 @@ On events of kind `0` (`user metadata`) one can specify the key `"nip05"` with a
 
 Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`.
 
-The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `user metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
+The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `user's metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
 
 ### Example
 

10.md

@@ -10,6 +10,33 @@ On "e" and "p" tags in Text Events (kind 1)
 ## Abstract
 This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events.  It helps clients thread the replies into a tree rooted at the original event.
 
+## Positional "e" tags (DEPRECATED)
+>This scheme is in common use; but should be considered deprecated.
+
+`["e", <event-id>, <relay-url>]`  as per NIP-01.
+
+Where:
+
+ * `<event-id>` is the id of the event being referenced.
+ * `<relay-url>` is the URL of a recommended relay associated with the reference.  Many clients treat this field as optional.
+
+**The positions of the "e" tags within the event denote specific meanings as follows**:
+
+ * No "e" tag: <br>
+ This event is not a reply to, nor does it refer to, any other event.
+
+ * One "e" tag: <br>
+ `["e", <id>]`: The id of the event to which this event is a reply.
+
+ * Two "e" tags:  `["e", <root-id>]`, `["e", <reply-id>]` <br>
+ `<root-id>` is the id of the event at the root of the reply chain.  `<reply-id>` is the id of the article to which this event is a reply.
+
+ * Many "e" tags: `["e", <root-id>]` `["e", <mention-id>]`, ..., `["e", <reply-id>]`<br>
+There may be any number of `<mention-ids>`.  These are the ids of events which may, or may not be in the reply chain.
+They are citing from this event.  `root-id` and `reply-id` are as above.
+
+>This scheme is deprecated because it creates ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.
+
 ## Marked "e" tags (PREFERRED)
 `["e", <event-id>, <relay-url>, <marker>, <pubkey>]`
 
@@ -35,33 +62,3 @@ When replying to a text event E the reply event's "p" tags should contain all of
 
 Example:  Given a text event authored by `a1` with "p" tags [`p1`, `p2`, `p3`] then the "p" tags of the reply should be [`a1`, `p1`, `p2`, `p3`]
 in no particular order.
-
-## Deprecated Positional "e" tags
-
-This scheme is not in common use anymore and is here just to keep backward compatibility with older events on the network. 
-
-Positional `e` tags are deprecated because they create ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.
-
-They use simple `e` tags without any marker. 
-
-`["e", <event-id>, <relay-url>]` as per NIP-01.
-
-Where:
-
- * `<event-id>` is the id of the event being referenced.
- * `<relay-url>` is the URL of a recommended relay associated with the reference.  Many clients treat this field as optional.
-
-**The positions of the "e" tags within the event denote specific meanings as follows**:
-
- * No "e" tag: <br>
- This event is not a reply to, nor does it refer to, any other event.
-
- * One "e" tag: <br>
- `["e", <id>]`: The id of the event to which this event is a reply.
-
- * Two "e" tags:  `["e", <root-id>]`, `["e", <reply-id>]` <br>
- `<root-id>` is the id of the event at the root of the reply chain.  `<reply-id>` is the id of the article to which this event is a reply.
-
- * Many "e" tags: `["e", <root-id>]` `["e", <mention-id>]`, ..., `["e", <reply-id>]`<br>
-There may be any number of `<mention-ids>`.  These are the ids of events which may, or may not be in the reply chain.
-They are citing from this event.  `root-id` and `reply-id` are as above.

11.md

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

17.md

@@ -47,7 +47,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An
 
 Following [NIP-59](59.md), the **unsigned** `kind:14` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
 
-```jsonc
+```js
 {
   "id": "<usual hash>",
   "pubkey": randomPublicKey,

22.md

@@ -13,7 +13,7 @@ It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other forma
 Comments MUST point to the root scope using uppercase tag names (e.g. `K`, `E`, `A` or `I`)
 and MUST point to the parent item with lowercase ones (e.g. `k`, `e`, `a` or `i`).
 
-```jsonc
+```js
 {
   kind: 1111,
   content: '<comment>',
@@ -56,7 +56,7 @@ If the parent item is an event, a `p` tag set to the parent event's author SHOUL
 
 A comment on a blog post looks like this:
 
-```jsonc
+```js
 {
   kind: 1111,
   content: 'Great blog post!',
@@ -79,7 +79,7 @@ A comment on a blog post looks like this:
 
 A comment on a [NIP-94](94.md) file looks like this:
 
-```jsonc
+```js
 {
   kind: 1111,
   content: 'Great file!',
@@ -100,7 +100,7 @@ A comment on a [NIP-94](94.md) file looks like this:
 
 A reply to a comment looks like this:
 
-```jsonc
+```js
 {
   kind: 1111,
   content: 'This is a reply to "Great file!"',
@@ -121,7 +121,7 @@ A reply to a comment looks like this:
 
 A comment on a website's url looks like this:
 
-```jsonc
+```js
 {
   kind: 1111,
   content: 'Nice article!',
@@ -142,7 +142,7 @@ A comment on a website's url looks like this:
 
 A podcast comment example:
 
-```jsonc
+```js
 {
   id: "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
   pubkey: "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
@@ -164,7 +164,7 @@ A podcast comment example:
 
 A reply to a podcast comment:
 
-```jsonc
+```js
 {
   kind: 1111,
   content: "I'm replying to the above comment.",

24.md

@@ -6,7 +6,7 @@ Extra metadata fields and tags
 
 `draft` `optional`
 
-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.
+This NIP defines extra optional fields added to events.
 
 kind 0
 ======

29.md

@@ -26,7 +26,7 @@ Group identifiers must be strings restricted to the characters `a-z0-9-_`.
 
 When encountering just the `<host>` without the `'<group-id>`, clients can choose to connect to the group with id `_`, which is a special top-level group dedicated to relay-local discussions.
 
-Group identifiers in most cases should be random or pseudo-random, as that mitigates message replay confusion and ensures they can be migrated or forked to other relays easily without risking conflicting with other groups using the same id in these new relays. This isn't a hard rule, as, for example, in `unmanaged` and/or ephemeral relays groups might not want to migrate ever, so they might not care about this. Notably, the `_` relay-local group isn't expected to be migrated ever.
+Group identifiers in most cases should be random or pseudo-random, as that mitigates message replay confusiong and ensures they can be migrated or forked to other relays easily without risking conflicting with other groups using the same id in these new relays. This isn't a hard rule, as, for example, in `unmanaged` and/or ephemeral relays groups might not want to migrate ever, so they might not care about this. Notably, the `_` relay-local group isn't expected to be migrated ever.
 
 ## The `h` tag
 
@@ -64,7 +64,39 @@ These are the events expected to be found in NIP-29 groups.
 
 ### Normal user-created events
 
-Groups may accept any event kind, including chats, threads, long-form articles, calendar, livestreams, market announcements and so on. These should be as defined in their respective NIPs, with the addition of the `h` tag.
+These events generally can be sent by all members of a group and they require the `h` tag to be present so they're attached to a specific group.
+
+- _chat message_ (`kind:9`)
+
+This is the basic unit of a _chat message_ sent to a group.
+
+```jsonc
+  "kind": 9,
+  "content": "hello my friends lovers of pizza",
+  "tags": [
+    ["h", "<group-id>"],
+    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", /*...*/]
+  ]
+  // other fields...
+```
+
+- _thread root post_ (`kind:11`)
+
+This is the basic unit of a forum-like root thread post sent to a group.
+
+```jsonc
+  "kind": 11,
+  "content": "hello my friends lovers of pizza",
+  "tags": [
+    ["h", "<group-id>"],
+    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", /*...*/]
+  ]
+  // other fields...
+```
+
+- _other events_:
+
+Groups may also accept other events, like [NIP-22](22.md) comments as threaded replies to both chats messages and threads, long-form articles, calendar, livestreams, market announcements and so on. These should be as defined in their respective NIPs, with the addition of the `h` tag.
 
 ### User-related group management events
 
@@ -109,7 +141,7 @@ These are events expected to be sent by the relay master key or by group admins
 
 Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action based on its role and the relay's internal policy (see also the description of `kind:39003`).
 
-```jsonc
+```json
 {
   "kind": 90xx,
   "content": "optional reason",

46.md

@@ -58,7 +58,7 @@ _user_ passes this token to _remote-signer_, which then sends `connect` *respons
 
 ## Request Events `kind: 24133`
 
-```jsonc
+```js
 {
     "kind": 24133,
     "pubkey": <local_keypair_pubkey>,
@@ -136,7 +136,7 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted
 
 ### Signature request
 
-```jsonc
+```js
 {
     "kind": 24133,
     "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
@@ -156,7 +156,7 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted
 
 ### Response event
 
-```jsonc
+```js
 {
     "kind": 24133,
     "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
@@ -191,12 +191,36 @@ _client_ should display (in a popup or new tab) the URL from the `error` field a
 
 ![signing-example-with-auth-challenge](https://i.nostr.build/W3aj.png)
 
+## Pure public key login
+
+A _client_ SHOULD support logins with just an `npub`, an `nprofile` or a NIP-05 address instead of requiring a full `bunker://...` URI. In order to do that, it can follow these steps:
+
+  1. Read _user-pubkey_ from the provided NIP-05, `nprofile` or `npub` code;
+  2. Acquire the list of outbox relays for _user_ (either by fetching the user's `kind:10002` relay list from relay hints or hardcoded relays or by other means);
+  3. Query these relay for a `kind:10046` event from _user_;
+  4. Read NIP-46 bunker connection metadata from that event -- then proceed as if the user had typed that bunker URI.
+
+For this to work _user_ must have somehow published such `kind:10046` event beforehand (which might be a job for the bunker provider or app directly or not).
+
+### `kind:10046` event format:
+
+```jsonc
+{
+    "pubkey": "<user-pubkey>",
+    "kind": 10046,
+    "tags": [
+        ["relays", "<remote-signer-relay-url>", "<any-number-of-other-relay-urls...>"],
+        ["pubkey", "<remote-signer-pubkey>"]
+    ]
+}
+```
+
 ## Appendix
 
 ### Announcing _remote-signer_ metadata
 
 _remote-signer_ MAY publish it's metadata by using [NIP-05](05.md) and [NIP-89](89.md). With NIP-05, a request to `<remote-signer>/.well-known/nostr.json?name=_` MAY return this:
-```jsonc
+```
 {
     "names":{
         "_": <remote-signer-app-pubkey>,

47.md

@@ -8,42 +8,32 @@ Nostr Wallet Connect
 
 ## Rationale
 
-This NIP describes a way for clients to access a remote lightning wallet through a standardized protocol. Custodians may implement this, or the user may run a bridge that bridges their wallet/node and the Nostr Wallet Connect protocol.
+This NIP describes a way for clients to access a remote Lightning wallet through a standardized protocol. Custodians may implement this, or the user may run a bridge that bridges their wallet/node and the Nostr Wallet Connect protocol.
 
 ## Terms
 
-* **client**: Nostr app on any platform that wants to interact with a lightning wallet.
+* **client**: Nostr app on any platform that wants to pay Lightning invoices.
-* **user**: The person using the **client**, and wants to connect their wallet to their **client**.
+* **user**: The person using the **client**, and want's to connect their wallet app to their **client**.
 * **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi).  This app has access to the APIs of the wallets it serves.
 
 ## Theory of Operation
- 1. **Users** who wish to use this NIP to allow **client(s)** to interact with their wallet must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
+ 1. **Users** who wish to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
  
- 2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc.  The **client(s)** should save this URI and use it later whenever the **user** (or the **client** on the user's behalf) wants to interact with the wallet.  The **client** should then request an `info` (13194) event from the relay(s) specified in the URI.  The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.  
+ 2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc.  The **client(s)** should save this URI and use it later whenever the **user** makes a payment.  The **client** should then request an `info` (13194) event from the relay(s) specified in the URI.  The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.  
  
  3. When the **user** initiates a payment their nostr **client** create a `pay_invoice` request, encrypts it using a token from the URI, and sends it (kind 23194) to the relay(s) specified in the connection URI.  The **wallet service** will be listening on those relays and will decrypt the request and then contact the **user's** wallet application to send the payment.  The **wallet service** will know how to talk to the wallet application because the connection URI specified relay(s) that have access to the wallet app API.  
  
- 4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI.
+ 4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI.  
- 
- 5. The **wallet service** may send encrypted notifications (kind 23196) of wallet events (such as a received payment) to the **client**.
 
 ## Events
 
-There are four event kinds:
+There are three event kinds:
 - `NIP-47 info event`: 13194
 - `NIP-47 request`: 23194
 - `NIP-47 response`: 23195
-- `NIP-47 notification event`: 23196
 
-### Info Event
+The info event should be a replaceable event that is published by the **wallet service** on the relay to indicate which commands it supports. The content should be
-
+a plaintext string with the supported commands, space-separated, eg. `pay_invoice get_balance`. Only the `pay_invoice` command is described in this NIP, but other commands might be defined in different NIPs.
-The info event should be a replaceable event that is published by the **wallet service** on the relay to indicate which capabilities it supports.
-
-The content should be a plaintext string with the supported capabilities space-separated, eg. `pay_invoice get_balance notifications`.
-
-If the **wallet service** supports notifications, the info event SHOULD contain a `notifications` tag with the supported notification types space-separated, eg. `payment_received payment_sent`.
-
-### Request and Response Events
 
 Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to.
 Optionally, a request can have an `expiration` tag that has a unix timestamp in seconds. If the request is received after this timestamp, it should be ignored.
@@ -78,22 +68,6 @@ The `result_type` field MUST contain the name of the method that this event is r
 The `error` field MUST contain a `message` field with a human readable error message and a `code` field with the error code if the command was not successful.
 If the command was successful, the `error` field must be null.
 
-### Notification Events
-
-The notification event SHOULD contain one `p` tag, the public key of the **user**.
-
-The content of notifications is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure:
-
-```jsonc
-{
-    "notification_type": "payment_received", //indicates the structure of the notification field
-    "notification": {
-        "payment_hash": "0123456789abcdef..." // notification-related data
-    }
-}
-```
-
-
 ### Error codes
 - `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds.
 - `NOT_IMPLEMENTED`: The command is not known or is intentionally not implemented.
@@ -146,8 +120,7 @@ Response:
 {
     "result_type": "pay_invoice",
     "result": {
-        "preimage": "0123456789abcdef...", // preimage of the payment
+        "preimage": "0123456789abcdef..." // preimage of the payment
-        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -182,8 +155,7 @@ payment hash of the invoice should be used.
 {
     "result_type": "multi_pay_invoice",
     "result": {
-        "preimage": "0123456789abcdef...", // preimage of the payment
+        "preimage": "0123456789abcdef..." // preimage of the payment
-        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -217,7 +189,6 @@ Response:
     "result_type": "pay_keysend",
     "result": {
         "preimage": "0123456789abcdef...", // preimage of the payment
-        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -254,8 +225,7 @@ pubkey should be used.
 {
     "result_type": "multi_pay_keysend",
     "result": {
-        "preimage": "0123456789abcdef...", // preimage of the payment
+        "preimage": "0123456789abcdef..." // preimage of the payment
-        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -424,59 +394,6 @@ Response:
             "block_height": 1,
             "block_hash": "hex string",
             "methods": ["pay_invoice", "get_balance", "make_invoice", "lookup_invoice", "list_transactions", "get_info"], // list of supported methods for this connection
-            "notifications": ["payment_received", "payment_sent"], // list of supported notifications for this connection, optional.
-    }
-}
-```
-
-## Notifications
-
-### `payment_received`
-
-Description: A payment was successfully received by the wallet.
-
-Notification:
-```jsonc
-{
-    "notification_type": "payment_received",
-    "notification": {
-        "type": "incoming",
-        "invoice": "string", // encoded invoice
-        "description": "string", // invoice's description, optional
-        "description_hash": "string", // invoice's description hash, optional
-        "preimage": "string", // payment's preimage
-        "payment_hash": "string", // Payment hash for the payment
-        "amount": 123, // value in msats
-        "fees_paid": 123, // value in msats
-        "created_at": unixtimestamp, // invoice/payment creation time
-        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
-        "settled_at": unixtimestamp, // invoice/payment settlement time
-        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
-    }
-}
-```
-
-### `payment_sent`
-
-Description: A payment was successfully sent by the wallet.
-
-Notification:
-```jsonc
-{
-    "notification_type": "payment_sent",
-    "notification": {
-        "type": "outgoing",
-        "invoice": "string", // encoded invoice
-        "description": "string", // invoice's description, optional
-        "description_hash": "string", // invoice's description hash, optional
-        "preimage": "string", // payment's preimage
-        "payment_hash": "string", // Payment hash for the payment
-        "amount": 123, // value in msats
-        "fees_paid": 123, // value in msats
-        "created_at": unixtimestamp, // invoice/payment creation time
-        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
-        "settled_at": unixtimestamp, // invoice/payment settlement time
-        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
     }
 }
 ```
@@ -490,24 +407,3 @@ Notification:
 
 ## Using a dedicated relay
 This NIP does not specify any requirements on the type of relays used. However, if the user is using a custodial service it might make sense to use a relay that is hosted by the custodial service. The relay may then enforce authentication to prevent metadata leaks. Not depending on a 3rd party relay would also improve reliability in this case.
-
-## Appendix
-
-### Example NIP-47 info event
-
-```jsonc
-{
-  "id": "df467db0a9f9ec77ffe6f561811714ccaa2e26051c20f58f33c3d66d6c2b4d1c",
-  "pubkey": "c04ccd5c82fc1ea3499b9c6a5c0a7ab627fbe00a0116110d4c750faeaecba1e2",
-  "created_at": 1713883677,
-  "kind": 13194,
-  "tags": [
-    [
-      "notifications",
-      "payment_received payment_sent"
-    ]
-  ],
-  "content": "pay_invoice pay_keysend get_balance get_info make_invoice lookup_invoice list_transactions multi_pay_invoice multi_pay_keysend sign_message notifications",
-  "sig": "31f57b369459b5306a5353aa9e03be7fbde169bc881c3233625605dd12f53548179def16b9fe1137e6465d7e4d5bb27ce81fd6e75908c46b06269f4233c845d8"
-}
-```

7D.md

@@ -1,34 +0,0 @@
-NIP-7D
-======
-
-Threads
--------
-
-`draft` `optional`
-
-A thread is a `kind 11` event.  Threads SHOULD include a `subject` with a summary
-of the thread's topic.
-
-```json
-{
-  "kind": 11,
-  "content": "Good morning",
-  "tags": [
-    ["subject", "GM"]
-  ]
-}
-```
-
-Replies to `kind 11` MUST use [NIP-22](./22.md) `kind 1111` comments. Replies should
-always be to the root `kind 11` to avoid arbitrarily nested reply hierarchies.
-
-```json
-{
-  "kind": 1111,
-  "content": "Cool beans",
-  "tags": [
-    ["K", "11"],
-    ["E", <event-id>, <relay-url>, <pubkey>]
-  ]
-}
-```

96.md

@@ -323,8 +323,8 @@ Note: HTTP File Storage Server developers may skip this section. This is meant f
 A File Server Preference event is a kind 10096 replaceable event meant to select one or more servers the user wants
 to upload files to. Servers are listed as `server` tags:
 
-```jsonc
+```json
-{
+{.
   "kind": 10096,
   "content": "",
   "tags": [

C7.md

@@ -1,29 +0,0 @@
-NIP-C7
-======
-
-Chats
------
-
-`draft` `optional`
-
-A chat message is a `kind 9` event.
-
-```json
-{
-  "kind": 9,
-  "content": "GM",
-  "tags": []
-}
-```
-
-A reply to a `kind 9` is an additional `kind 9` which quotes the parent using a `q` tag.
-
-```json
-{
-  "kind": 9,
-  "content": "nostr:nevent1...\nyes",
-  "tags": [
-    ["q", <event-id>, <relay-url>, <pubkey>]
-  ]
-}
-```

FA.md

@@ -1,45 +0,0 @@
-NIP-FA
-======
-
-Kind-scoped follows
--------------------
-
-`draft` `optional`
-
-This NIP defines kind `967`, a kind-scoped follow event.
-
-```jsonc
-{
-  "kind": 967,
-  "tags": [
-    ["p", "<followed-pubkey>", 'relay-url'],
-    ["k", "<some-kind>"],
-    ["k", "<some-other-kind>"]
-  ]
-}
-```
-
-Multiple `p` tags and multiple `k` tags are allowed.
-
-The `k` tag(s) define the scope of the follows.
-
-### Unfollow action
-
-Unfollowing is done by deleting the follow event, copying over the `k` tags from the follow event.
-
-```jsonc
-{
-  "kind": 5,
-  "tags": [
-    ["e", "<follow-event-id>"],
-    ["k", "<some-kind>"],
-    ["k", "<some-other-kind>"]
-  ]
-}
-```
-
-### Constructing specialized follow lists
-
-A client can fetch the events of the kinds they are interested in, and perhaps adjacent kinds if they choose to. For example, a client specialized in videos might also want to extend its computed follow list to include events related to live streams.
-
-Clients can use the last `kind:967` and `kind:5` tagged with a `k` they care about and use the last `created_at` they have seen to REQ for updates.

README.md

@@ -108,9 +108,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `7`           | Reaction                        | [25](25.md)                            |
 | `8`           | Badge Award                     | [58](58.md)                            |
 | `9`           | Group Chat Message              | [29](29.md)                            |
-| `10`          | Group Chat Threaded Reply       | 29 (deprecated)                        |
+| `10`          | Group Chat Threaded Reply       | [29](29.md)                            |
 | `11`          | Group Thread                    | [29](29.md)                            |
-| `12`          | Group Thread Reply              | 29 (deprecated)                        |
+| `12`          | Group Thread Reply              | [29](29.md)                            |
 | `13`          | Seal                            | [59](59.md)                            |
 | `14`          | Direct Message                  | [17](17.md)                            |
 | `16`          | Generic Repost                  | [18](18.md)                            |
@@ -127,7 +127,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1040`        | OpenTimestamps                  | [03](03.md)                            |
 | `1059`        | Gift Wrap                       | [59](59.md)                            |
 | `1063`        | File Metadata                   | [94](94.md)                            |
-| `1111`        | Comment                         | [22](22.md)                            |
 | `1311`        | Live Chat Message               | [53](53.md)                            |
 | `1617`        | Patches                         | [34](34.md)                            |
 | `1621`        | Issues                          | [34](34.md)                            |
@@ -266,7 +265,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `A`               | root address                         | relay URL                       | [22](22.md)                                        |
 | `d`               | identifier                           | --                              | [01](01.md)                                        |
 | `e`               | event id (hex)                       | relay URL, marker, pubkey (hex) | [01](01.md), [10](10.md)                           |
-| `E`               | root event id                        | relay URL                       | [22](22.md)                                        |
+| `E`               | root event i                         | relay URL                       | [22](22.md)                                        |
 | `f`               | currency code                        | --                              | [69](69.md)                                        |
 | `g`               | geohash                              | --                              | [52](52.md)                                        |
 | `h`               | group id                             | --                              | [29](29.md)                                        |