21 files changed, 861 insertions, 251 deletions

diff --git a/05.md b/05.md
index ca6da7b..7e823fb 100644
--- a/05.md
+++ b/05.md
@@ -10,7 +10,7 @@ On events of kind `0` (`user metadata`) one can specify the key `"nip05"` with a
 
 Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`.
 
-The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `user's metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
+The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `user metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
 
 ### Example
 
@@ -33,7 +33,7 @@ It will make a GET request to `https://example.com/.well-known/nostr.json?name=b
     "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
   }
 }
-````
+```
 
 or with the **recommended** `"relays"` attribute:
 
@@ -46,7 +46,7 @@ or with the **recommended** `"relays"` attribute:
     "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ]
   }
 }
-````
+```
 
 If the pubkey matches the one given in `"names"` (as in the example above) that means the association is right and the `"nip05"` identifier is valid and can be displayed.
 
diff --git a/10.md b/10.md
index 94db4fa..c1d5068 100644
--- a/10.md
+++ b/10.md
@@ -10,33 +10,6 @@ On "e" and "p" tags in Text Events (kind 1)
 ## Abstract
 This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events.  It helps clients thread the replies into a tree rooted at the original event.
 
-## Positional "e" tags (DEPRECATED)
->This scheme is in common use; but should be considered deprecated.
-
-`["e", <event-id>, <relay-url>]`  as per NIP-01.
-
-Where:
-
- * `<event-id>` is the id of the event being referenced.
- * `<relay-url>` is the URL of a recommended relay associated with the reference.  Many clients treat this field as optional.
-
-**The positions of the "e" tags within the event denote specific meanings as follows**:
-
- * No "e" tag: <br>
- This event is not a reply to, nor does it refer to, any other event.
-
- * One "e" tag: <br>
- `["e", <id>]`: The id of the event to which this event is a reply.
-
- * Two "e" tags:  `["e", <root-id>]`, `["e", <reply-id>]` <br>
- `<root-id>` is the id of the event at the root of the reply chain.  `<reply-id>` is the id of the article to which this event is a reply.
-
- * Many "e" tags: `["e", <root-id>]` `["e", <mention-id>]`, ..., `["e", <reply-id>]`<br>
-There may be any number of `<mention-ids>`.  These are the ids of events which may, or may not be in the reply chain.
-They are citing from this event.  `root-id` and `reply-id` are as above.
-
->This scheme is deprecated because it creates ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.
-
 ## Marked "e" tags (PREFERRED)
 `["e", <event-id>, <relay-url>, <marker>, <pubkey>]`
 
@@ -62,3 +35,33 @@ When replying to a text event E the reply event's "p" tags should contain all of
 
 Example:  Given a text event authored by `a1` with "p" tags [`p1`, `p2`, `p3`] then the "p" tags of the reply should be [`a1`, `p1`, `p2`, `p3`]
 in no particular order.
+
+## Deprecated Positional "e" tags
+
+This scheme is not in common use anymore and is here just to keep backward compatibility with older events on the network. 
+
+Positional `e` tags are deprecated because they create ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.
+
+They use simple `e` tags without any marker. 
+
+`["e", <event-id>, <relay-url>]` as per NIP-01.
+
+Where:
+
+ * `<event-id>` is the id of the event being referenced.
+ * `<relay-url>` is the URL of a recommended relay associated with the reference.  Many clients treat this field as optional.
+
+**The positions of the "e" tags within the event denote specific meanings as follows**:
+
+ * No "e" tag: <br>
+ This event is not a reply to, nor does it refer to, any other event.
+
+ * One "e" tag: <br>
+ `["e", <id>]`: The id of the event to which this event is a reply.
+
+ * Two "e" tags:  `["e", <root-id>]`, `["e", <reply-id>]` <br>
+ `<root-id>` is the id of the event at the root of the reply chain.  `<reply-id>` is the id of the article to which this event is a reply.
+
+ * Many "e" tags: `["e", <root-id>]` `["e", <mention-id>]`, ..., `["e", <reply-id>]`<br>
+There may be any number of `<mention-ids>`.  These are the ids of events which may, or may not be in the reply chain.
+They are citing from this event.  `root-id` and `reply-id` are as above.
\ No newline at end of file
diff --git a/11.md b/11.md
index 0ca5870..8af4f31 100644
--- a/11.md
+++ b/11.md
@@ -14,6 +14,8 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
 {
   "name": <string identifying relay>,
   "description": <string with detailed information>,
+  "banner": <a link to an image (e.g. in .jpg, or .png format)>,
+  "icon": <a link to an icon (e.g. in .jpg, or .png format>,
   "pubkey": <administrative contact pubkey>,
   "contact": <administrative alternate contact>,
   "supported_nips": <a list of NIP numbers supported by the relay>,
@@ -35,6 +37,21 @@ A relay may select a `name` for use in client software.  This is a string, and S
 
 Detailed plain-text information about the relay may be contained in the `description` string.  It is recommended that this contain no markup, formatting or line breaks for word wrapping, and simply use double newline characters to separate paragraphs.  There are no limitations on length.
 
+### Banner
+
+To make nostr relay management more user friendly, an effort should be made by relay owners to communicate with non-dev non-technical nostr end users. A banner is a visual representation of the relay. It should aim to visually communicate the brand of the relay, complementing the text `Description`. [Here is an example banner](https://image.nostr.build/232ddf6846e8aea5a61abcd70f9222ab521f711aa545b7ab02e430248fa3a249.png) mockup as visualized in Damus iOS relay view of the Damus relay.
+
+### Icon
+
+Icon is a compact visual representation of the relay for use in UI with limited real estate such as a nostr user's relay list view. Below is an example URL pointing to an image to be used as an icon for the relay. Recommended to be squared in shape.
+
+```jsonc
+{
+  "icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg",
+  // other fields...
+}
+```
+
 ### Pubkey
 
 An administrative contact may be listed with a `pubkey`, in the same format as Nostr events (32-byte hex for a `secp256k1` public key).  If a contact is listed, this provides clients with a recommended address to send encrypted direct messages (See [NIP-17](17.md)) to a system administrator.  Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance.
@@ -245,7 +262,7 @@ processed by appropriate client software.
 
 Relays that require payments may want to expose their fee schedules.
 
-```json
+```jsonc
 {
   "payments_url": "https://my-relay/payments",
   "fees": {
@@ -253,17 +270,6 @@ 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" }],
   },
-  ...
-}
-```
-
-### Icon
-
-A URL pointing to an image to be used as an icon for the relay. Recommended to be squared in shape.
-
-```jsonc
-{
-  "icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg",
   // other fields...
 }
 ```
diff --git a/17.md b/17.md
index 4b96bce..72f40c4 100644
--- a/17.md
+++ b/17.md
@@ -47,7 +47,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An
 
 Following [NIP-59](59.md), the **unsigned** `kind:14` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
 
-```js
+```jsonc
 {
   "id": "<usual hash>",
   "pubkey": randomPublicKey,
diff --git a/22.md b/22.md
new file mode 100644
index 0000000..f11925f
--- /dev/null
+++ b/22.md
@@ -0,0 +1,184 @@
+NIP-22
+======
+
+Comment
+-------
+
+`draft` `optional`
+
+A comment is a threading note always scoped to a root event or an `I`-tag.
+
+It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other formatting).
+
+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
+{
+  kind: 1111,
+  content: '<comment>',
+  tags: [
+    // root scope: event addresses, event ids, or I-tags.
+    ["<A, E, I>", "<address, id or I-value>", "<relay or web page hint>", "<root event's pubkey, if an E tag>"],
+    // the root item kind
+    ["K", "<root kind>"],
+
+    // parent item: event addresses, event ids, or i-tags.
+    ["<a, e, i>", "<address, id or i-value>", "<relay or web page hint>", "<parent event's pubkey, if an e tag>"],
+    // parent item kind
+    ["k", "<parent comment kind>"]
+  ]
+  // other fields
+}
+```
+
+Tags `K` and `k` MUST be present to define the event kind of the root and the parent items.
+
+`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).
+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).
+
+```json
+["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
+```
+
+`p` tags SHOULD be used when mentioning pubkeys in the `.content` with [NIP-21](21.md).
+If the parent item is an event, a `p` tag set to the parent event's author SHOULD be added.
+
+```json
+["p", "<pubkey>", "<relay-url>"]
+```
+
+## Examples
+
+A comment on a blog post looks like this:
+
+```jsonc
+{
+  kind: 1111,
+  content: 'Great blog post!',
+  tags: [
+    // top-level comments scope to event addresses or ids
+    ["A", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
+    // the root kind
+    ["K", "30023"],
+
+    // the parent event address (same as root for top-level comments)
+    ["a", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
+    // when the parent event is replaceable or addressable, also include an `e` tag referencing its id
+    ["e", "5b4fc7fed15672fefe65d2426f67197b71ccc82aa0cc8a9e94f683eb78e07651", "wss://example.relay"],
+    // the parent event kind
+    ["k", "30023"]
+  ]
+  // other fields
+}
+```
+
+A comment on a [NIP-94](94.md) file looks like this:
+
+```jsonc
+{
+  kind: 1111,
+  content: 'Great file!',
+  tags: [
+    // top-level comments have the same scope and reply to addresses or ids
+    ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
+    // the root kind
+    ["K", "1063"],
+
+    // the parent event id (same as root for top-level comments)
+    ["e", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
+    // the parent kind
+    ["k", "1063"]
+  ]
+  // other fields
+}
+```
+
+A reply to a comment looks like this:
+
+```jsonc
+{
+  kind: 1111,
+  content: 'This is a reply to "Great file!"',
+  tags: [
+    // nip-94 file event id
+    ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
+    // the root kind
+    ["K", "1063"],
+
+    // the parent event
+    ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://example.relay", "93ef2ebaaf9554661f33e79949007900bbc535d239a4c801c33a4d67d3e7f546"],
+    // the parent kind
+    ["k", "1111"]
+  ]
+  // other fields
+}
+```
+
+A comment on a website's url looks like this:
+
+```jsonc
+{
+  kind: 1111,
+  content: 'Nice article!',
+  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 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"]
+  ]
+  // other fields
+}
+```
+
+A podcast comment example:
+
+```jsonc
+{
+  id: "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
+  pubkey: "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
+  kind: 1111,
+  content: "This was a great episode!",
+  tags: [
+    // podcast episode reference
+    ["I", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
+    // podcast episode type
+    ["K", "podcast:item:guid"],
+
+    // same value as "I" tag above, because it is a top-level comment (not a reply to a comment)
+    ["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
+    ["k", "podcast:item:guid"]
+  ]
+  // other fields
+}
+```
+
+A reply to a podcast comment:
+
+```jsonc
+{
+  kind: 1111,
+  content: "I'm replying to the above comment.",
+  tags: [
+    // podcast episode reference
+    ["I", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
+    // podcast episode type
+    ["K", "podcast:item:guid"],
+
+    // this is a reference to the above comment
+    ["e", "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05", "wss://example.relay", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"],
+    // the parent comment kind
+    ["k", "1111"]
+  ]
+  // other fields
+}
+```
diff --git a/24.md b/24.md
index 1afa7c7..df3a932 100644
--- a/24.md
+++ b/24.md
@@ -6,7 +6,7 @@ Extra metadata fields and tags
 
 `draft` `optional`
 
-This NIP defines extra optional fields added to events.
+This NIP keeps track of extra optional fields that can added to events which are not defined anywhere else but have become _de facto_ standards and other minor implementation possibilities that do not deserve their own NIP and do not have a place in other NIPs.
 
 kind 0
 ======
diff --git a/29.md b/29.md
index 6232f8b..331047f 100644
--- a/29.md
+++ b/29.md
@@ -22,9 +22,15 @@ Relays are supposed to generate the events that describe group metadata and grou
 
 A group may be identified by a string in the format `<host>'<group-id>`. For example, a group with _id_ `abcdef` hosted at the relay `wss://groups.nostr.com` would be identified by the string `groups.nostr.com'abcdef`.
 
+Group identifiers must be strings restricted to the characters `a-z0-9-_`, and SHOULD be random in order to avoid name collisions.
+
+When encountering just the `<host>` without the `'<group-id>`, clients MAY infer `_` as the group id, which is a special top-level group dedicated to relay-local discussions.
+
 ## The `h` tag
 
-Events sent by users to groups (chat messages, text notes, moderation events etc) must have an `h` tag with the value set to the group _id_.
+Events sent by users to groups (chat messages, text notes, moderation events etc) MUST have an `h` tag with the value set to the group _id_.
+
+`h` tags MAY include the group's name as the second argument. This allows `unmanaged` groups to be assigned human-readable names without relay support.
 
 ## Timeline references
 
@@ -36,48 +42,33 @@ This is a hack to prevent messages from being broadcasted to external relays tha
 
 Relays should prevent late publication (messages published now with a timestamp from days or even hours ago) unless they are open to receive a group forked or moved from another relay.
 
-## Event definitions
+## Group management
 
-- *text root note* (`kind:11`)
+Groups can have any number of users with elevated access. These users are identified by role labels which are arbitrarily defined by the relays (see also the description of `kind:39003`). What each role is capable of not defined in this NIP either, it's a relay policy that can vary. Roles can be assigned by other users (as long as they have the capability to add roles) by publishing a `kind:9000` event with that user's pubkey in a `p` tag and the roles afterwards (even if the user is already a group member a `kind:9000` can be issued and the user roles must just be updated).
 
-This is the basic unit of a "microblog" root text note sent to a group.
+The roles supported by the group as to having some special privilege assigned to them should be accessible on the event `kind:39003`, but the relay may also accept other role names, arbitrarily defined by clients, and just not do anything with them.
 
-```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...
-```
+Users with any roles that have any privilege can be considered _admins_ in a broad sense and be returned in the `kind:39001` event for a group.
 
-- *threaded text reply* (`kind:12`)
+## Unmanaged groups
 
-This is the basic unit of a "microblog" reply note sent to a group. It's the same as `kind:11`, except for the fact that it must be used whenever it's in reply to some other note (either in reply to a `kind:11` or a `kind:12`). `kind:12` events SHOULD use NIP-10 markers, leaving an empty relay url:
+Unmanaged groups are impromptu groups that can be used in any public relay unaware of NIP-29 specifics. They piggyback on relays' natural white/blacklists (or lack of) but aside from that are not actively managed and won't have any admins, group state or metadata events.
 
-* `["e", "<kind-11-root-id>", "", "root"]`
-* `["e", "<kind-12-event-id>", "", "reply"]`
+In `unmanaged` groups, everybody is considered to be a member.
 
-- *chat message* (`kind:9`)
+Unmanaged groups can transition to managed groups, in that case the relay master key just has to publish moderation events setting the state of all groups and start enforcing the rules they choose to.
 
-This is the basic unit of a _chat message_ sent to a group.
+## Event definitions
 
-```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...
-```
+These are the events expected to be found in NIP-29 groups.
 
-- *chat message threaded reply* (`kind:10`)
+### Normal user-created events
 
-Similar to `kind:12`, this is the basic unit of a chat message sent to a group. This is intended for in-chat threads that may be hidden by default. Not all in-chat replies MUST use `kind:10`, only when the intention is to create a hidden thread that isn't part of the normal flow of the chat (although clients are free to display those by default too).
+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.
 
-`kind:10` SHOULD use NIP-10 markers, just like `kind:12`.
+### User-related group management events
+
+These are events that can be sent by users to manage their situation in a group, they also require the `h` tag.
 
 - *join request* (`kind:9021`)
 
@@ -88,11 +79,14 @@ Any user can send one of these events to the relay in order to be automatically
   "kind": 9021,
   "content": "optional reason",
   "tags": [
-    ["h", "<group-id>"]
+    ["h", "<group-id>"],
+    ["code", "<optional-invite-code>"]
   ]
 }
 ```
 
+The optional `code` tag may be used by the relay to preauthorize acceptances in `closed` groups, together with the `kind:9009` `create-invite` moderation event.
+
 - *leave request* (`kind:9022`)
 
 Any user can send one of these events to the relay in order to be automatically removed from the group. The relay will automatically issue a `kind:9001` in response removing this user.
@@ -107,11 +101,15 @@ Any user can send one of these events to the relay in order to be automatically
 }
 ```
 
+### Group state -- or moderation
+
+These are events expected to be sent by the relay master key or by group admins -- and relays should reject them if they don't come from an authorized admin. They also require the `h` tag.
+
 - *moderation events* (`kinds:9000-9020`) (optional)
 
-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. The relay may discard the event after taking action or keep it as a moderation log.
+Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action based on its role and the relay's internal policy (see also the description of `kind:39003`).
 
-```json
+```jsonc
 {
   "kind": 90xx,
   "content": "optional reason",
@@ -124,17 +122,21 @@ Clients can send these events to a relay in order to accomplish a moderation act
 
 Each moderation action uses a different kind and requires different arguments, which are given as tags. These are defined in the following table:
 
-| kind | name                | tags                                      |
-| ---  | ---                 | ---                                       |
-| 9000 | `add-user`          | `p` (pubkey hex)                          |
-| 9001 | `remove-user`       | `p` (pubkey hex)                          |
-| 9002 | `edit-metadata`     | `name`, `about`, `picture` (string)       |
-| 9003 | `add-permission`    | `p` (pubkey), `permission` (name)         |
-| 9004 | `remove-permission` | `p` (pubkey), `permission` (name)         |
-| 9005 | `delete-event`      | `e` (id hex)                              |
-| 9006 | `edit-group-status` | `public` or `private`, `open` or `closed` |
-| 9007 | `create-group`      |                                           |
-| 9008 | `delete-group`      |                                           |
+| kind | name                | tags                                           |
+| ---  | ---                 | ---                                            |
+| 9000 | `put-user`          | `p` with pubkey hex and optional roles         |
+| 9001 | `remove-user`       | `p` with pubkey hex                            |
+| 9002 | `edit-metadata`     | fields from `kind:39000` to be modified        |
+| 9005 | `delete-event`      | `e` with event id hex                          |
+| 9007 | `create-group`      |                                                |
+| 9008 | `delete-group`      |                                                |
+| 9009 | `create-invite`     |                                                |
+
+It's expected that the group state (of who is an allowed member or not, who is an admin and with which permission or not, what are the group name and picture etc) can be fully reconstructed from the canonical sequence of these events.
+
+### Group metadata events
+
+These events contain the group id in a `d` tag instead of the `h` tag. They MUST be created by the relay master key only and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).
 
 - *group metadata* (`kind:39000`) (optional)
 
@@ -142,6 +144,8 @@ This event defines the metadata for the group -- basically how clients should di
 
 If the group is forked and hosted in multiple relays, there will be multiple versions of this event in each different relay and so on.
 
+When this event is not found, clients may still connect to the group, but treat it as having a different status, `unmanaged`,
+
 ```jsonc
 {
   "kind": 39000,
@@ -162,41 +166,29 @@ If the group is forked and hosted in multiple relays, there will be multiple ver
 
 - *group admins* (`kind:39001`) (optional)
 
-Similar to the group metadata, this event is supposed to be generated by relays that host the group.
+Each admin is listed along with one or more roles. These roles SHOULD have a correspondence with the roles supported by the relay, as advertised by the `kind:39003` event.
 
-Each admin gets a label that is only used for display purposes, and a list of permissions it has are listed afterwards. These permissions can inform client building UI, but ultimately are evaluated by the relay in order to become effective.
-
-The list of capabilities, as defined by this NIP, for now, is the following:
-
-- `add-user`
-- `edit-metadata`
-- `delete-event`
-- `remove-user`
-- `add-permission`
-- `remove-permission`
-- `edit-group-status`
-- `delete-group`
-
-```json
+```jsonc
 {
   "kind": 39001,
   "content": "list of admins for the pizza lovers group",
   "tags": [
     ["d", "<group-id>"],
-    ["p", "<pubkey1-as-hex>", "ceo", "add-user", "edit-metadata", "delete-event", "remove-user"],
-    ["p", "<pubkey2-as-hex>", "secretary", "add-user", "delete-event"]
-  ]
+    ["p", "<pubkey1-as-hex>", "ceo"],
+    ["p", "<pubkey2-as-hex>", "secretary", "gardener"],
+    // other pubkeys...
+  ],
   // other fields...
 }
 ```
 
 - *group members* (`kind:39002`) (optional)
 
-Similar to *group admins*, this event is supposed to be generated by relays that host the group.
+It's a list of pubkeys that are members of the group. Relays might choose to not to publish this information, to restrict what pubkeys can fetch it or to only display a subset of the members in it.
 
-It's a NIP-51-like list of pubkeys that are members of the group. Relays might choose to not to publish this information or to restrict what pubkeys can fetch it.
+Clients should not assume this will always be present or that it will contain a full list of members.
 
-```json
+```jsonc
 {
   "kind": 39002,
   "content": "list of members for the pizza lovers group",
@@ -205,10 +197,48 @@ It's a NIP-51-like list of pubkeys that are members of the group. Relays might c
     ["p", "<admin1>"],
     ["p", "<member-pubkey1>"],
     ["p", "<member-pubkey2>"],
-  ]
+    // other pubkeys...
+  ],
+  // other fields...
 }
 ```
 
-## Storing the list of groups a user belongs to
+- *group roles* (`kind:39003`) (optional)
+
+This is an event that MAY be published by the relay informing users and clients about what are the roles supported by this relay according to its internal logic.
+
+For example, a relay may choose to support the roles `"admin"` and `"moderator"`, in which the `"admin"` will be allowed to edit the group metadata, delete messages and remove users from the group, while the `"moderator"` can only delete messages (or the relay may choose to call these roles `"ceo"` and `"secretary"` instead, the exact role name is not relevant).
+
+The process through which the relay decides what roles to support and how to handle moderation events internally based on them is specific to each relay and not specified here.
+
+```jsonc
+{
+  "kind": 39003,
+  "content": "list of roles supported by this group",
+  "tags": [
+    ["d", "<group-id>"],
+    ["role", "<role-name>", "<optional-description>"],
+    ["role", "<role-name>", "<optional-description>"],
+    // other roles...
+  ],
+  // other fields...
+}
+```
+
+## Implementation quirks
+
+### Checking your own membership in a group
+
+The latest of either `kind:9000` or `kind:9001` events present in a group should tell a user that they are currently members of the group or if they were removed. In case none of these exist the user is assumed to not be a member of the group -- unless the group is `unmanaged`, in which case the user is assumed to be a member.
+
+### Adding yourself to a group
+
+When a group is `open`, anyone can send a `kind:9021` event to it in order to be added, then expect a `kind:9000` event to be emitted confirming that the user was added. The same happens with `closed` groups, except in that case a user may only send a `kind:9021` if it has an invite code.
+
+### Storing your list of groups
+
+A definition for `kind:10009` was included in [NIP-51](51.md) that allows clients to store the list of groups a user wants to remember being in.
+
+### Using `unmanaged` relays
 
-A definition for kind `10009` was included in [NIP-51](51.md) that allows clients to store the list of groups a user wants to remember being in.
+To prevent event leakage, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
diff --git a/46.md b/46.md
index e1675b0..824059c 100644
--- a/46.md
+++ b/46.md
@@ -4,6 +4,10 @@ NIP-46
 Nostr Remote Signing
 --------------------
 
+## Changes
+
+`remote-signer-key` is introduced, passed in bunker url, clients must differentiate between `remote-signer-pubkey` and `user-pubkey`, must call `get_public_key` after connect, nip05 login is removed, create_account moved to another NIP.
+
 ## Rationale
 
 Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface.
@@ -12,102 +16,70 @@ This NIP describes a method for 2-way communication between a remote signer and
 
 ## Terminology
 
-- **Local keypair**: A local public and private key-pair used to encrypt content and communicate with the remote signer. Usually created by the client application.
-- **Remote user pubkey**: The public key that the user wants to sign as. The remote signer has control of the private key that matches this public key.
-- **Remote signer pubkey**: This is the public key of the remote signer itself. This is needed in both `create_account` command because you don't yet have a remote user pubkey.
+- **user**: A person that is trying to use Nostr.
+- **client**: A user-facing application that _user_ is looking at and clicking buttons in. This application will send requests to _remote-signer_.
+- **remote-signer**: A daemon or server running somewhere that will answer requests from _client_, also known as "bunker".
+- **client-keypair/pubkey**: The keys generated by _client_. Used to encrypt content and communicate with _remote-signer_.
+- **remote-signer-keypair/pubkey**: The keys used by _remote-signer_ to encrypt content and communicate with _client_. This keypair MAY be same as _user-keypair_, but not necessarily.
+- **user-keypair/pubkey**: The actual keys representing _user_ (that will be used to sign events in response to `sign_event` requests, for example). The _remote-signer_ generally has control over these keys.
 
 All pubkeys specified in this NIP are in hex format.
 
-## Initiating a connection
-
-To initiate a connection between a client and a remote signer there are a few different options.
-
-### Direct connection initiated by remote signer
-
-This is most common in a situation where you have your own nsecbunker or other type of remote signer and want to connect through a client that supports remote signing.
+## Overview
 
-The remote signer would provide a connection token in the form:
+1. _client_ generates `client-keypair`. This keypair doesn't need to be communicated to _user_ since it's largely disposable. _client_ might choose to store it locally and they should delete it on logout;
+2. A connection is established (see below), _remote-signer_ learns `client-pubkey`, _client_ learns `remote-signer-pubkey`.
+3. _client_ uses `client-keypair` to send requests to _remote-signer_ by `p`-tagging and encrypting to `remote-signer-pubkey`;
+4. _remote-signer_ responds to _client_ by `p`-tagging and encrypting to the `client-pubkey`.
+5. _client_ requests `get_public_key` to learn `user-pubkey`.
 
-```
-bunker://<remote-user-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
-```
+## Initiating a connection
 
-This token is pasted into the client by the user and the client then uses the details to connect to the remote signer via the specified relay(s). Optional secret can be used for single successfully established connection only, remote signer SHOULD ignore new attempts to establish connection with old optional secret.
+There are two ways to initiate a connection:
 
-### Direct connection initiated by the client
+### Direct connection initiated by _remote-signer_
 
-In this case, basically the opposite direction of the first case, the client provides a connection token (or encodes the token in a QR code) and the signer initiates a connection to the client via the specified relay(s).
+_remote-signer_ provides connection token in the form:
 
 ```
-nostrconnect://<local-keypair-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json metadata in the form: {"name":"...", "url": "...", "description": "..."}>
+bunker://<remote-signer-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
 ```
 
-## The flow
+_user_ passes this token to _client_, which then sends `connect` request to _remote-signer_ via the specified relays. Optional secret can be used for single successfully established connection only, _remote-signer_ SHOULD ignore new attempts to establish connection with old secret.
 
-1. Client creates a local keypair. This keypair doesn't need to be communicated to the user since it's largely disposable (i.e. the user doesn't need to see this pubkey). Clients might choose to store it locally and they should delete it when the user logs out.
-2. Client gets the remote user pubkey (either via a `bunker://` connection string or a NIP-05 login-flow; shown below)
-3. Clients use the local keypair to send requests to the remote signer by `p`-tagging and encrypting to the remote user pubkey.
-4. The remote signer responds to the client by `p`-tagging and encrypting to the local keypair pubkey.
+### Direct connection initiated by the _client_
 
-### Example flow for signing an event
+_client_ provides a connection token using `nostrconnect://` as the protocol, and `client-pubkey` as the origin. Additional information should be passed as query parameters:
 
-- Remote user pubkey (e.g. signing as) `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52`
-- Local pubkey is `eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86`
+- `relay` (required) - one or more relay urls on which the _client_ is listening for responses from the _remote-signer_.
+- `secret` (required) - a short random string that the _remote-signer_ should return as the `result` field of its response.
+- `perms` (optional) - a comma-separated list of permissions the _client_ is requesting be approved by the _remote-signer_
+- `name` (optional) - the name of the _client_ application
+- `url` (optional) - the canonical url of the _client_ application
+- `image` (optional) - a small image representing the _client_ application
 
-#### Signature request
+Here's an example:
 
-```json
-{
-    "kind": 24133,
-    "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
-    "content": nip04({
-        "id": <random_string>,
-        "method": "sign_event",
-        "params": [json_stringified(<{
-            content: "Hello, I'm signing remotely",
-            kind: 1,
-            tags: [],
-            created_at: 1714078911
-        }>)]
-    }),
-    "tags": [["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]], // p-tags the remote user pubkey
-}
 ```
-
-#### Response event
-
-```json
-{
-    "kind": 24133,
-    "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
-    "content": nip04({
-        "id": <random_string>,
-        "result": json_stringified(<signed-event>)
-    }),
-    "tags": [["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]], // p-tags the local keypair pubkey
-}
+nostrconnect://83f3b2ae6aa368e8275397b9c26cf550101d63ebaab900d19dd4a4429f5ad8f5?relay=wss%3A%2F%2Frelay1.example.com&perms=nip44_encrypt%2Cnip44_decrypt%2Csign_event%3A13%2Csign_event%3A14%2Csign_event%3A1059&name=My+Client&secret=0s8j2djs&relay=wss%3A%2F%2Frelay2.example2.com
 ```
 
-#### Diagram
-
-![signing-example](https://i.nostr.build/P3gW.png)
+_user_ passes this token to _remote-signer_, which then sends `connect` *response* event to the `client-pubkey` via the specified relays. Client discovers `remote-signer-pubkey` from connect response author. `secret` value MUST be provided to avoid connection spoofing, _client_ MUST validate the `secret` returned by `connect` response.
 
 ## Request Events `kind: 24133`
 
 ```jsonc
 {
-    "id": <id>,
     "kind": 24133,
     "pubkey": <local_keypair_pubkey>,
     "content": <nip04(<request>)>,
-    "tags": [["p", <remote_user_pubkey>]], // NB: in the `create_account` event, the remote signer pubkey should be `p` tagged.
-    "created_at": <unix timestamp in seconds>
+    "tags": [["p", <remote-signer-pubkey>]],
 }
 ```
 
 The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted and has the following structure:
 
-```json
+```jsonc
 {
     "id": <random_string>,
     "method": <method_name>,
@@ -121,15 +93,15 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted
 
 ### Methods/Commands
 
-Each of the following are methods that the client sends to the remote signer.
+Each of the following are methods that the _client_ sends to the _remote-signer_.
 
 | Command                  | Params                                                                        | Result                                                                 |
 | ------------------------ | -------------------------------------------------                             | ---------------------------------------------------------------------- |
-| `connect`                | `[<remote_user_pubkey>, <optional_secret>, <optional_requested_permissions>]` | "ack"                                                                  |
+| `connect`                | `[<remote-signer-pubkey>, <optional_secret>, <optional_requested_permissions>]`        | "ack" OR `<required-secret-value>`                                                                  |
 | `sign_event`             | `[<{kind, content, tags, created_at}>]`                                       | `json_stringified(<signed_event>)`                                     |
 | `ping`                   | `[]`                                                                          | "pong"                                                                 |
 | `get_relays`             | `[]`                                                                          | `json_stringified({<relay_url>: {read: <boolean>, write: <boolean>}})` |
-| `get_public_key`         | `[]`                                                                          | `<hex-pubkey>`                                                         |
+| `get_public_key`         | `[]`                                                                          | `<user-pubkey>`                                                         |
 | `nip04_encrypt`          | `[<third_party_pubkey>, <plaintext_to_encrypt>]`                              | `<nip04_ciphertext>`                                                   |
 | `nip04_decrypt`          | `[<third_party_pubkey>, <nip04_ciphertext_to_decrypt>]`                       | `<plaintext>`                                                          |
 | `nip44_encrypt`          | `[<third_party_pubkey>, <plaintext_to_encrypt>]`                              | `<nip44_ciphertext>`                                                   |
@@ -137,7 +109,7 @@ Each of the following are methods that the client sends to the remote signer.
 
 ### Requested permissions
 
-The `connect` method may be provided with `optional_requested_permissions` for user convenience. The permissions are a comma-separated list of `method[:params]`, i.e. `nip04_encrypt,sign_event:4` meaning permissions to call `nip04_encrypt` and to call `sign_event` with `kind:4`. Optional parameter for `sign_event` is the kind number, parameters for other methods are to be defined later.
+The `connect` method may be provided with `optional_requested_permissions` for user convenience. The permissions are a comma-separated list of `method[:params]`, i.e. `nip04_encrypt,sign_event:4` meaning permissions to call `nip04_encrypt` and to call `sign_event` with `kind:4`. Optional parameter for `sign_event` is the kind number, parameters for other methods are to be defined later. Same permission format may be used for `perms` field of `metadata` in `nostrconnect://` string.
 
 ## Response Events `kind:24133`
 
@@ -145,9 +117,9 @@ The `connect` method may be provided with `optional_requested_permissions` for u
 {
     "id": <id>,
     "kind": 24133,
-    "pubkey": <remote_signer_pubkey>,
+    "pubkey": <remote-signer-pubkey>,
     "content": <nip04(<response>)>,
-    "tags": [["p", <local_keypair_pubkey>]],
+    "tags": [["p", <client-pubkey>]],
     "created_at": <unix timestamp in seconds>
 }
 ```
@@ -166,66 +138,90 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted
 - `results` is a string of the result of the call (this can be either a string or a JSON stringified object)
 - `error`, _optionally_, it is an error in string form, if any. Its presence indicates an error with the request.
 
-### Auth Challenges
+## Example flow for signing an event
 
-An Auth Challenge is a response that a remote signer can send back when it needs the user to authenticate via other means. This is currently used in the OAuth-like flow enabled by signers like [Nsecbunker](https://github.com/kind-0/nsecbunkerd/). The response `content` object will take the following form:
+- `remote-signer-pubkey` is `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52`
+- `user-pubkey` is also `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52`
+- `client-pubkey` is `eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86`
 
-```json
+### Signature request
+
+```jsonc
 {
-    "id": <request_id>,
-    "result": "auth_url",
-    "error": <URL_to_display_to_end_user>
+    "kind": 24133,
+    "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
+    "content": nip04({
+        "id": <random_string>,
+        "method": "sign_event",
+        "params": [json_stringified(<{
+            content: "Hello, I'm signing remotely",
+            kind: 1,
+            tags: [],
+            created_at: 1714078911
+        }>)]
+    }),
+    "tags": [["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]], // p-tags the remote-signer-pubkey
 }
 ```
 
-Clients should display (in a popup or new tab) the URL from the `error` field and then subscribe/listen for another response from the remote signer (reusing the same request ID). This event will be sent once the user authenticates in the other window (or will never arrive if the user doesn't authenticate). It's also possible to add a `redirect_uri` url parameter to the auth_url, which is helpful in situations when a client cannot open a new window or tab to display the auth challenge.
-
-#### Example event signing request with auth challenge
-
-![signing-example-with-auth-challenge](https://i.nostr.build/W3aj.png)
-
-## Remote Signer Commands
-
-Remote signers might support additional commands when communicating directly with it. These commands follow the same flow as noted above, the only difference is that when the client sends a request event, the `p`-tag is the pubkey of the remote signer itself and the `content` payload is encrypted to the same remote signer pubkey.
+### Response event
 
-### Methods/Commands
-
-Each of the following are methods that the client sends to the remote signer.
-
-| Command          | Params                                     | Result                               |
-| ---------------- | ------------------------------------------ | ------------------------------------ |
-| `create_account` | `[<username>, <domain>, <optional_email>, <optional_requested_permissions>]` | `<newly_created_remote_user_pubkey>` |
+```jsonc
+{
+    "kind": 24133,
+    "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
+    "content": nip04({
+        "id": <random_string>,
+        "result": json_stringified(<signed-event>)
+    }),
+    "tags": [["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]], // p-tags the client-pubkey
+}
+```
 
-## Appendix
+### Diagram
 
-### NIP-05 Login Flow
+![signing-example](https://i.nostr.build/P3gW.png)
 
-Clients might choose to present a more familiar login flow, so users can type a NIP-05 address instead of a `bunker://` string.
 
-When the user types a NIP-05 the client:
+## Auth Challenges
 
-- Queries the `/.well-known/nostr.json` file from the domain for the NIP-05 address provided to get the user's pubkey (this is the **remote user pubkey**)
-- In the same `/.well-known/nostr.json` file, queries for the `nip46` key to get the relays that the remote signer will be listening on.
-- Now the client has enough information to send commands to the remote signer on behalf of the user.
+An Auth Challenge is a response that a _remote-signer_ can send back when it needs the _user_ to authenticate via other means. The response `content` object will take the following form:
 
-### OAuth-like Flow
+```json
+{
+    "id": <request_id>,
+    "result": "auth_url",
+    "error": <URL_to_display_to_end_user>
+}
+```
 
-#### Remote signer discovery via NIP-89
+_client_ should display (in a popup or new tab) the URL from the `error` field and then subscribe/listen for another response from the _remote-signer_ (reusing the same request ID). This event will be sent once the user authenticates in the other window (or will never arrive if the user doesn't authenticate).
 
-In this last case, most often used to facilitate an OAuth-like signin flow, the client first looks for remote signers that have announced themselves via NIP-89 application handler events.
+### Example event signing request with auth challenge
 
-First the client will query for `kind: 31990` events that have a `k` tag of `24133`.
+![signing-example-with-auth-challenge](https://i.nostr.build/W3aj.png)
 
-These are generally shown to a user, and once the user selects which remote signer to use and provides the remote user pubkey they want to use (via npub, pubkey, or nip-05 value), the client can initiate a connection. Note that it's on the user to select the remote signer that is actually managing the remote key that they would like to use in this case. If the remote user pubkey is managed on another remote signer, the connection will fail.
+## Appendix
 
-In addition, it's important that clients validate that the pubkey of the announced remote signer matches the pubkey of the `_` entry in the `/.well-known/nostr.json` file of the remote signer's announced domain.
+### Announcing _remote-signer_ metadata
 
-Clients that allow users to create new accounts should also consider validating the availability of a given username in the namespace of remote signer's domain by checking the `/.well-known/nostr.json` file for existing usernames. Clients can then show users feedback in the UI before sending a `create_account` event to the remote signer and receiving an error in return. Ideally, remote signers would also respond with understandable error messages if a client tries to create an account with an existing username.
+_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>,
+    },
+    "nip46": {
+        "relays": ["wss://relay1","wss://relay2"...],
+        "nostrconnect_url": "https://remote-signer-domain.com/<nostrconnect>"
+    }
+}
+```
 
-#### Example Oauth-like flow to create a new user account with Nsecbunker
+The `<remote-signer-app-pubkey>` MAY be used to verify the domain from _remote-signer_'s NIP-89 event (see below). `relays` SHOULD be used to construct a more precise `nostrconnect://` string for the specific `remote-signer`. `nostrconnect_url` template MAY be used to redirect users to _remote-signer_'s connection flow by replacing `<nostrconnect>` placeholder with an actual `nostrconnect://` string.
 
-Coming soon...
+### Remote signer discovery via NIP-89
 
-## References
+_remote-signer_ MAY publish a NIP-89 `kind: 31990` event with `k` tag of `24133`, which MAY also include one or more `relay` tags and MAY include `nostrconnect_url` tag. The semantics of `relay` and `nostrconnect_url` tags are the same as in the section above.
 
-- [NIP-04 - Encryption](04.md)
+_client_ MAY improve UX by discovering _remote-signers_ using their `kind: 31990` events. _client_ MAY then pre-generate `nostrconnect://` strings for the _remote-signers_, and SHOULD in that case verify that `kind: 31990` event's author is mentioned in signer's `nostr.json?name=_` file as `<remote-signer-app-pubkey>`. 
diff --git a/47.md b/47.md
index a19230f..d1030a4 100644
--- a/47.md
+++ b/47.md
@@ -8,32 +8,42 @@ Nostr Wallet Connect
 
 ## Rationale
 
-This NIP describes a way for clients to access a remote Lightning wallet through a standardized protocol. Custodians may implement this, or the user may run a bridge that bridges their wallet/node and the Nostr Wallet Connect protocol.
+This NIP describes a way for clients to access a remote lightning wallet through a standardized protocol. Custodians may implement this, or the user may run a bridge that bridges their wallet/node and the Nostr Wallet Connect protocol.
 
 ## Terms
 
-* **client**: Nostr app on any platform that wants to pay Lightning invoices.
-* **user**: The person using the **client**, and want's to connect their wallet app to their **client**.
+* **client**: Nostr app on any platform that wants to interact with a lightning wallet.
+* **user**: The person using the **client**, and wants to connect their wallet to their **client**.
 * **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi).  This app has access to the APIs of the wallets it serves.
 
 ## Theory of Operation
- 1. **Users** who wish to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
+ 1. **Users** who wish to use this NIP to allow **client(s)** to interact with their wallet must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
  
- 2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc.  The **client(s)** should save this URI and use it later whenever the **user** makes a payment.  The **client** should then request an `info` (13194) event from the relay(s) specified in the URI.  The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.  
+ 2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc.  The **client(s)** should save this URI and use it later whenever the **user** (or the **client** on the user's behalf) wants to interact with the wallet.  The **client** should then request an `info` (13194) event from the relay(s) specified in the URI.  The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.  
  
  3. When the **user** initiates a payment their nostr **client** create a `pay_invoice` request, encrypts it using a token from the URI, and sends it (kind 23194) to the relay(s) specified in the connection URI.  The **wallet service** will be listening on those relays and will decrypt the request and then contact the **user's** wallet application to send the payment.  The **wallet service** will know how to talk to the wallet application because the connection URI specified relay(s) that have access to the wallet app API.  
  
- 4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI.  
+ 4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI.
+ 
+ 5. The **wallet service** may send encrypted notifications (kind 23196) of wallet events (such as a received payment) to the **client**.
 
 ## Events
 
-There are three event kinds:
+There are four event kinds:
 - `NIP-47 info event`: 13194
 - `NIP-47 request`: 23194
 - `NIP-47 response`: 23195
+- `NIP-47 notification event`: 23196
+
+### Info Event
+
+The info event should be a replaceable event that is published by the **wallet service** on the relay to indicate which capabilities it supports.
+
+The content should be a plaintext string with the supported capabilities space-separated, eg. `pay_invoice get_balance notifications`.
 
-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.
+If the **wallet service** supports notifications, the info event SHOULD contain a `notifications` tag with the supported notification types space-separated, eg. `payment_received payment_sent`.
+
+### Request and Response Events
 
 Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to.
 Optionally, a request can have an `expiration` tag that has a unix timestamp in seconds. If the request is received after this timestamp, it should be ignored.
@@ -68,6 +78,22 @@ The `result_type` field MUST contain the name of the method that this event is r
 The `error` field MUST contain a `message` field with a human readable error message and a `code` field with the error code if the command was not successful.
 If the command was successful, the `error` field must be null.
 
+### Notification Events
+
+The notification event SHOULD contain one `p` tag, the public key of the **user**.
+
+The content of notifications is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure:
+
+```jsonc
+{
+    "notification_type": "payment_received", //indicates the structure of the notification field
+    "notification": {
+        "payment_hash": "0123456789abcdef..." // notification-related data
+    }
+}
+```
+
+
 ### Error codes
 - `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds.
 - `NOT_IMPLEMENTED`: The command is not known or is intentionally not implemented.
@@ -120,7 +146,8 @@ Response:
 {
     "result_type": "pay_invoice",
     "result": {
-        "preimage": "0123456789abcdef..." // preimage of the payment
+        "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -148,14 +175,15 @@ Request:
 Response:
 
 For every invoice in the request, a separate response event is sent. To differentiate between the responses, each
-response event contains an `d` tag with the id of the invoice it is responding to, if no id was given, then the
+response event contains a `d` tag with the id of the invoice it is responding to, if no id was given, then the
 payment hash of the invoice should be used.
 
 ```jsonc
 {
     "result_type": "multi_pay_invoice",
     "result": {
-        "preimage": "0123456789abcdef..." // preimage of the payment
+        "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -189,6 +217,7 @@ Response:
     "result_type": "pay_keysend",
     "result": {
         "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -225,7 +254,8 @@ pubkey should be used.
 {
     "result_type": "multi_pay_keysend",
     "result": {
-        "preimage": "0123456789abcdef..." // preimage of the payment
+        "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -394,6 +424,59 @@ Response:
             "block_height": 1,
             "block_hash": "hex string",
             "methods": ["pay_invoice", "get_balance", "make_invoice", "lookup_invoice", "list_transactions", "get_info"], // list of supported methods for this connection
+            "notifications": ["payment_received", "payment_sent"], // list of supported notifications for this connection, optional.
+    }
+}
+```
+
+## Notifications
+
+### `payment_received`
+
+Description: A payment was successfully received by the wallet.
+
+Notification:
+```jsonc
+{
+    "notification_type": "payment_received",
+    "notification": {
+        "type": "incoming",
+        "invoice": "string", // encoded invoice
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "preimage": "string", // payment's preimage
+        "payment_hash": "string", // Payment hash for the payment
+        "amount": 123, // value in msats
+        "fees_paid": 123, // value in msats
+        "created_at": unixtimestamp, // invoice/payment creation time
+        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+        "settled_at": unixtimestamp, // invoice/payment settlement time
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
+    }
+}
+```
+
+### `payment_sent`
+
+Description: A payment was successfully sent by the wallet.
+
+Notification:
+```jsonc
+{
+    "notification_type": "payment_sent",
+    "notification": {
+        "type": "outgoing",
+        "invoice": "string", // encoded invoice
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "preimage": "string", // payment's preimage
+        "payment_hash": "string", // Payment hash for the payment
+        "amount": 123, // value in msats
+        "fees_paid": 123, // value in msats
+        "created_at": unixtimestamp, // invoice/payment creation time
+        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+        "settled_at": unixtimestamp, // invoice/payment settlement time
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
     }
 }
 ```
@@ -407,3 +490,24 @@ Response:
 
 ## Using a dedicated relay
 This NIP does not specify any requirements on the type of relays used. However, if the user is using a custodial service it might make sense to use a relay that is hosted by the custodial service. The relay may then enforce authentication to prevent metadata leaks. Not depending on a 3rd party relay would also improve reliability in this case.
+
+## Appendix
+
+### Example NIP-47 info event
+
+```jsonc
+{
+  "id": "df467db0a9f9ec77ffe6f561811714ccaa2e26051c20f58f33c3d66d6c2b4d1c",
+  "pubkey": "c04ccd5c82fc1ea3499b9c6a5c0a7ab627fbe00a0116110d4c750faeaecba1e2",
+  "created_at": 1713883677,
+  "kind": 13194,
+  "tags": [
+    [
+      "notifications",
+      "payment_received payment_sent"
+    ]
+  ],
+  "content": "pay_invoice pay_keysend get_balance get_info make_invoice lookup_invoice list_transactions multi_pay_invoice multi_pay_keysend sign_message notifications",
+  "sig": "31f57b369459b5306a5353aa9e03be7fbde169bc881c3233625605dd12f53548179def16b9fe1137e6465d7e4d5bb27ce81fd6e75908c46b06269f4233c845d8"
+}
+```
diff --git a/51.md b/51.md
index 3792d7f..4c0b1f4 100644
--- a/51.md
+++ b/51.md
@@ -29,7 +29,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | Public chats      | 10005 | [NIP-28](28.md) chat channels the user is in                | `"e"` (kind:40 channel definitions)                                               |
 | Blocked relays    | 10006 | relays clients should never connect to                      | `"relay"` (relay URLs)                                                            |
 | Search relays     | 10007 | relays clients should use when performing search queries    | `"relay"` (relay URLs)                                                            |
-| Simple groups     | 10009 | [NIP-29](29.md) groups the user is in                       | `"group"` ([NIP-29](29.md) group ids + mandatory relay URL)                       |
+| Simple groups     | 10009 | [NIP-29](29.md) groups the user is in                       | `"group"` ([NIP-29](29.md) group id + relay URL), `"r"` for each relay in use     |
 | Interests         | 10015 | topics a user may be interested in and pointers             | `"t"` (hashtags) and `"a"` (kind:30015 interest set)                              |
 | Emojis            | 10030 | user preferred emojis and pointers to emoji sets            | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set)                  |
 | DM relays         | 10050 | Where to receive [NIP-17](17.md) direct messages            | `"relay"` (see [NIP-17](17.md))                                                   |
diff --git a/53.md b/53.md
index ee12fef..c3f15ea 100644
--- a/53.md
+++ b/53.md
@@ -119,4 +119,4 @@ Common use cases include meeting rooms/workshops, watch-together activities, or
   "content": "Zaps to live streams is beautiful.",
   "sig": "997f62ddfc0827c121043074d50cfce7a528e978c575722748629a4137c45b75bdbc84170bedc723ef0a5a4c3daebf1fef2e93f5e2ddb98e5d685d022c30b622"
 }
-````
+```
diff --git a/55.md b/55.md
index 54dc44a..afca0aa 100644
--- a/55.md
+++ b/55.md
@@ -72,6 +72,35 @@ Set the Signer package name:
 intent.`package` = "com.example.signer"
 ```
 
+If you are sending multiple intents without awaiting you can add some intent flags to sign all events without opening multiple times the signer
+
+```kotlin
+intent.addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP or Intent.FLAG_ACTIVITY_CLEAR_TOP)
+```
+
+If you are developing a signer application them you need to add this to your AndroidManifest.xml so clients can use the intent flags above
+
+```kotlin
+android:launchMode="singleTop"
+```
+
+Signer MUST answer multiple permissions with an array of results
+
+```kotlin
+
+val results = listOf(
+  Result(
+    package = signerPackageName,
+    result = eventSignture,
+    id = intentId
+  )
+)
+
+val json = results.toJson()
+
+intent.putExtra("results", json)
+```
+
 Send the Intent:
 
 ```kotlin
diff --git a/57.md b/57.md
index b533811..3f55e57 100644
--- a/57.md
+++ b/57.md
@@ -66,7 +66,7 @@ A signed `zap request` event is not published, but is instead sent using a HTTP
 - `nostr` is the `9734` `zap request` event, JSON encoded then URI encoded
 - `lnurl` is the lnurl pay url of the recipient, encoded using bech32 with the prefix `lnurl`
 
-This request should return a JSON response with a `pr` key, which is the invoice the sender must pay to finalize his zap. Here is an example flow in javascript:
+This request should return a JSON response with a `pr` key, which is the invoice the sender must pay to finalize their zap. Here is an example flow in javascript:
 
 ```javascript
 const senderPubkey // The sender's pubkey
diff --git a/59.md b/59.md
index a4fc99d..9bb5845 100644
--- a/59.md
+++ b/59.md
@@ -245,7 +245,7 @@ const rumor = createRumor(
 const seal = createSeal(rumor, senderPrivateKey, recipientPublicKey)
 const wrap = createWrap(seal, recipientPublicKey)
 
-// Recipient unwraps with his/her private key.
+// Recipient unwraps with their private key.
 
 const unwrappedSeal = nip44Decrypt(wrap, recipientPrivateKey)
 const unsealedRumor = nip44Decrypt(unwrappedSeal, recipientPrivateKey)
diff --git a/60.md b/60.md
index 2f24841..64cd282 100644
--- a/60.md
+++ b/60.md
@@ -159,7 +159,7 @@ Her client:
         "proofs": [
             { "id": "1", "amount": 1 },
             { "id": "2", "amount": 2 },
-            { "id": "8", "amount": 8 },
+            { "id": "4", "amount": 8 },
         ]
     }),
     "tags": [
diff --git a/69.md b/69.md
new file mode 100644
index 0000000..330d6e5
--- /dev/null
+++ b/69.md
@@ -0,0 +1,86 @@
+# NIP-69
+
+## Peer-to-peer Order events
+
+`draft` `optional`
+
+## Abstract
+
+Peer-to-peer (P2P) platforms have seen an upturn in recent years, while having more and more options is positive, in the specific case of p2p, having several options contributes to the liquidity split, meaning sometimes there's not enough assets available for trading. If we combine all these individual solutions into one big pool of orders, it will make them much more competitive compared to centralized systems, where a single authority controls the liquidity.
+
+This NIP defines a simple standard for peer-to-peer order events, which enables the creation of a big liquidity pool for all p2p platforms participating.
+
+## The event
+
+Events are [addressable events](https://github.com/nostr-protocol/nips/blob/master/01.md#kinds) and use `38383` as event kind, a p2p event look like this:
+
+```json
+{
+  "id": "84fad0d29cb3529d789faeff2033e88fe157a48e071c6a5d1619928289420e31",
+  "pubkey": "dbe0b1be7aafd3cfba92d7463edbd4e33b2969f61bd554d37ac56f032e13355a",
+  "created_at": 1702548701,
+  "kind": 38383,
+  "tags": [
+    ["d", "ede61c96-4c13-4519-bf3a-dcf7f1e9d842"],
+    ["k", "sell"],
+    ["f", "VES"],
+    ["s", "pending"],
+    ["amt", "0"],
+    ["fa", "100"],
+    ["pm", "face to face", "bank transfer"],
+    ["premium", "1"],
+    [
+      "rating",
+      "{\"total_reviews\":1,\"total_rating\":3.0,\"last_rating\":3,\"max_rate\":5,\"min_rate\":1}"
+    ],
+    ["source", "https://t.me/p2plightning/xxxxxxx"],
+    ["network", "mainnet"],
+    ["layer", "lightning"],
+    ["name", "Nakamoto"],
+    ["g", "<geohash>"],
+    ["bond", "0"],
+    ["expiration", "1719391096"],
+    ["y", "lnp2pbot"],
+    ["z", "order"]
+  ],
+  "content": "",
+  "sig": "7e8fe1eb644f33ff51d8805c02a0e1a6d034e6234eac50ef7a7e0dac68a0414f7910366204fa8217086f90eddaa37ded71e61f736d1838e37c0b73f6a16c4af2"
+}
+```
+
+## Tags
+
+- `d` < Order ID >: A unique identifier for the order.
+- `k` < Order type >: `sell` or `buy`.
+- `f` < Currency >: The asset being traded, using the [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217) standard.
+- `s` < Status >: `pending`, `canceled`, `in-progress`, `success`.
+- `amt` < Amount >: The amount of Bitcoin to be traded, the amount is defined in satoshis, if `0` means that the amount of satoshis will be obtained from a public API after the taker accepts the order.
+- `fa` < Fiat amount >: The fiat amount being traded, for range orders two values are expected, the minimum and maximum amount.
+- `pm` < Payment method >: The payment method used for the trade, if the order has multiple payment methods, they should be separated by a comma.
+- `premium` < Premium >: The percentage of the premium the maker is willing to pay.
+- `source` [Source]: The source of the order, it can be a URL that redirects to the order.
+- `rating` [Rating]: The rating of the maker, this document does not define how the rating is calculated, it's up to the platform to define it.
+- `network` < Network >: The network used for the trade, it can be `mainnet`, `testnet`, `signet`, etc.
+- `layer` < Layer >: The layer used for the trade, it can be `onchain`, `lightning`, `liquid`, etc.
+- `name` [Name]: The name of the maker.
+- `g` [Geohash]: The geohash of the operation, it can be useful in a face to face trade.
+- `bond` [Bond]: The bond amount, the bond is a security deposit that both parties must pay.
+- `expiration` < Expiration\>: The expiration date of the order ([NIP-40](https://github.com/nostr-protocol/nips/blob/master/40.md)).
+- `y` < Platform >: The platform that created the order.
+- `z` < Document >: `order`.
+
+Mandatory tags are enclosed with `<tag>`, optional tags are enclosed with `[tag]`.
+
+## Implementations
+
+Currently implemented on the following platforms:
+
+- [Mostro](https://github.com/MostroP2P/mostro)
+- [@lnp2pBot](https://github.com/lnp2pBot/bot)
+- [Robosats](https://github.com/RoboSats/robosats/pull/1362)
+
+## References
+
+- [Mostro protocol specification](https://mostro.network/protocol/)
+- [Messages specification for peer 2 peer NIP proposal](https://github.com/nostr-protocol/nips/blob/8250274a22f4882f621510df0054fd6167c10c9e/31001.md)
+- [n3xB](https://github.com/nobu-maeda/n3xb)
diff --git a/7D.md b/7D.md
new file mode 100644
index 0000000..d8509a6
--- /dev/null
+++ b/7D.md
@@ -0,0 +1,34 @@
+NIP-7D
+======
+
+Threads
+-------
+
+`draft` `optional`
+
+A thread is a `kind 11` event.  Threads SHOULD include a `subject` with a summary
+of the thread's topic.
+
+```json
+{
+  "kind": 11,
+  "content": "Good morning",
+  "tags": [
+    ["subject", "GM"]
+  ]
+}
+```
+
+Replies to `kind 11` MUST use [NIP-22](./22.md) `kind 1111` comments. Replies should
+always be to the root `kind 11` to avoid arbitrarily nested reply hierarchies.
+
+```json
+{
+  "kind": 1111,
+  "content": "Cool beans",
+  "tags": [
+    ["K", "11"],
+    ["E", <event-id>, <relay-url>, <pubkey>]
+  ]
+}
+```
diff --git a/86.md b/86.md
new file mode 100644
index 0000000..6f64eee
--- /dev/null
+++ b/86.md
@@ -0,0 +1,90 @@
+NIP-86
+======
+
+Relay Management API
+--------------------
+
+`draft` `optional`
+
+Relays may provide an API for performing management tasks. This is made available as a JSON-RPC-like request-response protocol over HTTP, on the same URI as the relay's websocket.
+
+When a relay receives an HTTP(s) request with a `Content-Type` header of `application/nostr+json+rpc` to a URI supporting WebSocket upgrades, it should parse the request as a JSON document with the following fields:
+
+```json
+{
+  "method": "<method-name>",
+  "params": ["<array>", "<of>", "<parameters>"]
+}
+```
+
+Then it should return a response in the format
+
+```json
+{
+  "result": {"<arbitrary>": "<value>"},
+  "error": "<optional error message, if the call has errored>"
+}
+```
+
+This is the list of **methods** that may be supported:
+
+* `supportedmethods`:
+  - params: `[]`
+  - result: `["<method-name>", "<method-name>", ...]` (an array with the names of all the other supported methods)
+* `banpubkey`:
+  - params: `["<32-byte-hex-public-key>", "<optional-reason>"]`
+  - result: `true` (a boolean always set to `true`)
+* `listbannedpubkeys`:
+  - params: `[]`
+  - result: `[{"pubkey": "<32-byte-hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
+* `allowpubkey`:
+  - params: `["<32-byte-hex-public-key>", "<optional-reason>"]`
+  - result: `true` (a boolean always set to `true`)
+* `listallowedpubkeys`:
+  - params: `[]`
+  - result: `[{"pubkey": "<32-byte-hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
+* `listeventsneedingmoderation`:
+  - params: `[]`
+  - result: `[{"id": "<32-byte-hex>", "reason": "<optional-reason>"}]`, an array of objects
+* `allowevent`:
+  - params: `["<32-byte-hex-event-id>", "<optional-reason>"]`
+  - result: `true` (a boolean always set to `true`)
+* `banevent`:
+  - params: `["<32-byte-hex-event-id>", "<optional-reason>"]`
+  - result: `true` (a boolean always set to `true`)
+* `listbannedevents`:
+  - params: `[]`
+  - result: `[{"id": "<32-byte hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
+* `changerelayname`:
+  - params: `["<new-name>"]`
+  - result: `true` (a boolean always set to `true`)
+* `changerelaydescription`:
+  - params: `["<new-description>"]`
+  - result: `true` (a boolean always set to `true`)
+* `changerelayicon`:
+  - params: `["<new-icon-url>"]`
+  - result: `true` (a boolean always set to `true`)
+* `allowkind`:
+  - params: `[<kind-number>]`
+  - result: `true` (a boolean always set to `true`)
+* `disallowkind`:
+  - params: `[<kind-number>]`
+  - result: `true` (a boolean always set to `true`)
+* `listallowedkinds`:
+  - params: `[]`
+  - result: `[<kind-number>, ...]`, an array of numbers
+* `blockip`:
+  - params: `["<ip-address>", "<optional-reason>"]`
+  - result: `true` (a boolean always set to `true`)
+* `unblockip`:
+  - params: `["<ip-address>"]`
+  - result: `true` (a boolean always set to `true`)
+* `listblockedips`:
+  - params: `[]`
+  - result: `[{"ip": "<ip-address>", "reason": "<optional-reason>"}, ...]`, an array of objects
+
+### Authorization
+
+The request must contain an `Authorization` header with a valid [NIP-98](./98.md) event, except the `payload` tag is required. The `u` tag is the relay URL.
+
+If `Authorization` is not provided or is invalid, the endpoint should return a 401 response.
diff --git a/96.md b/96.md
index 05c1b18..3828e76 100644
--- a/96.md
+++ b/96.md
@@ -323,8 +323,8 @@ Note: HTTP File Storage Server developers may skip this section. This is meant f
 A File Server Preference event is a kind 10096 replaceable event meant to select one or more servers the user wants
 to upload files to. Servers are listed as `server` tags:
 
-```json
-{.
+```jsonc
+{
   "kind": 10096,
   "content": "",
   "tags": [
diff --git a/C7.md b/C7.md
new file mode 100644
index 0000000..0d94f18
--- /dev/null
+++ b/C7.md
@@ -0,0 +1,29 @@
+NIP-C7
+======
+
+Chats
+-----
+
+`draft` `optional`
+
+A chat message is a `kind 9` event.
+
+```json
+{
+  "kind": 9,
+  "content": "GM",
+  "tags": []
+}
+```
+
+A reply to a `kind 9` is an additional `kind 9` which quotes the parent using a `q` tag.
+
+```json
+{
+  "kind": 9,
+  "content": "nostr:nevent1...\nyes",
+  "tags": [
+    ["q", <event-id>, <relay-url>, <pubkey>]
+  ]
+}
+```
diff --git a/README.md b/README.md
index 400f1ec..9ef9fec 100644
--- a/README.md
+++ b/README.md
@@ -40,6 +40,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-18: Reposts](18.md)
 - [NIP-19: bech32-encoded entities](19.md)
 - [NIP-21: `nostr:` URI scheme](21.md)
+- [NIP-22: Comment](22.md)
 - [NIP-23: Long-form Content](23.md)
 - [NIP-24: Extra metadata fields and tags](24.md)
 - [NIP-25: Reactions](25.md)
@@ -77,6 +78,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-61: Nutzaps](61.md)
 - [NIP-64: Chess (PGN)](64.md)
 - [NIP-65: Relay List Metadata](65.md)
+- [NIP-69: Peer-to-peer Order events](69.md)
 - [NIP-70: Protected Events](70.md)
 - [NIP-71: Video Events](71.md)
 - [NIP-72: Moderated Communities](72.md)
@@ -84,6 +86,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-75: Zap Goals](75.md)
 - [NIP-78: Application-specific data](78.md)
 - [NIP-84: Highlights](84.md)
+- [NIP-86: Relay Management API](86.md)
 - [NIP-89: Recommended Application Handlers](89.md)
 - [NIP-90: Data Vending Machines](90.md)
 - [NIP-92: Media Attachments](92.md)
@@ -91,6 +94,8 @@ 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-7D: Threads](7D.md)
+- [NIP-C7: Chats](C7.md)
 
 ## Event Kinds
 
@@ -105,10 +110,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `6`           | Repost                          | [18](18.md)                            |
 | `7`           | Reaction                        | [25](25.md)                            |
 | `8`           | Badge Award                     | [58](58.md)                            |
-| `9`           | Group Chat Message              | [29](29.md)                            |
-| `10`          | Group Chat Threaded Reply       | [29](29.md)                            |
-| `11`          | Group Thread                    | [29](29.md)                            |
-| `12`          | Group Thread Reply              | [29](29.md)                            |
+| `9`           | Chat Message                    | [C7](C7.md)                            |
+| `10`          | Group Chat Threaded Reply       | 29 (deprecated)                        |
+| `11`          | Thread                          | [7D](7D.md)                            |
+| `12`          | Group Thread Reply              | 29 (deprecated)                        |
 | `13`          | Seal                            | [59](59.md)                            |
 | `14`          | Direct Message                  | [17](17.md)                            |
 | `16`          | Generic Repost                  | [18](18.md)                            |
@@ -125,6 +130,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1040`        | OpenTimestamps                  | [03](03.md)                            |
 | `1059`        | Gift Wrap                       | [59](59.md)                            |
 | `1063`        | File Metadata                   | [94](94.md)                            |
+| `1111`        | Comment                         | [22](22.md)                            |
 | `1311`        | Live Chat Message               | [53](53.md)                            |
 | `1617`        | Patches                         | [34](34.md)                            |
 | `1621`        | Issues                          | [34](34.md)                            |
@@ -217,6 +223,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `34236`       | Short-form Portrait Video Event | [71](71.md)                            |
 | `34550`       | Community Definition            | [72](72.md)                            |
 | `37375`       | Cashu Wallet Event              | [60](60.md)                            |
+| `38383`       | Peer-to-peer Order events       | [69](69.md)                            |
 | `39000-9`     | Group metadata events           | [29](29.md)                            |
 
 [NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/
@@ -258,22 +265,32 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 
 | name              | value                                | other parameters                | NIP                                                |
 | ----------------- | ------------------------------------ | ------------------------------- | -------------------------------------------------- |
-| `e`               | event id (hex)                       | relay URL, marker, pubkey (hex) | [01](01.md), [10](10.md)                           |
-| `p`               | pubkey (hex)                         | relay URL, petname              | [01](01.md), [02](02.md)                           |
 | `a`               | coordinates to an event              | relay URL                       | [01](01.md)                                        |
+| `A`               | root address                         | relay URL                       | [22](22.md)                                        |
 | `d`               | identifier                           | --                              | [01](01.md)                                        |
-| `-`               | --                                   | --                              | [70](70.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)                                        |
+| `f`               | currency code                        | --                              | [69](69.md)                                        |
 | `g`               | geohash                              | --                              | [52](52.md)                                        |
 | `h`               | group id                             | --                              | [29](29.md)                                        |
-| `i`               | external identity                    | proof, url hint                 | [39](39.md), [73](73.md)                           |
+| `i`               | external identity                    | proof, url hint                 | [35](35.md), [39](39.md), [73](73.md)              |
+| `I`               | root external identity               | --                              | [22](22.md)                                        |
 | `k`               | kind                                 | --                              | [18](18.md), [25](25.md), [72](72.md), [73](73.md) |
+| `K`               | root scope                           | --                              | [22](22.md)                                        |
 | `l`               | label, label namespace               | --                              | [32](32.md)                                        |
 | `L`               | label namespace                      | --                              | [32](32.md)                                        |
 | `m`               | MIME type                            | --                              | [94](94.md)                                        |
+| `p`               | pubkey (hex)                         | relay URL, petname              | [01](01.md), [02](02.md)                           |
 | `q`               | event id (hex)                       | relay URL, pubkey (hex)         | [18](18.md)                                        |
 | `r`               | a reference (URL, etc)               | --                              | [24](24.md), [25](25.md)                           |
 | `r`               | relay url                            | marker                          | [65](65.md)                                        |
-| `t`               | hashtag                              | --                              | [24](24.md), [34](34.md)                           |
+| `s`               | status                               | --                              | [69](69.md)                                        |
+| `t`               | hashtag                              | --                              | [24](24.md), [34](34.md), [35](35.md)              |
+| `u`               | url                                  | --                              | [61](61.md), [98](98.md)                           |
+| `x`               | infohash                             | --                              | [35](35.md)                                        |
+| `y`               | platform                             | --                              | [69](69.md)                                        |
+| `z`               | order number                         | --                              | [69](69.md)                                        |
+| `-`               | --                                   | --                              | [70](70.md)                                        |
 | `alt`             | summary                              | --                              | [31](31.md)                                        |
 | `amount`          | millisatoshis, stringified           | --                              | [57](57.md)                                        |
 | `bolt11`          | `bolt11` invoice                     | --                              | [57](57.md)                                        |
@@ -286,6 +303,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `emoji`           | shortcode, image URL                 | --                              | [30](30.md)                                        |
 | `encrypted`       | --                                   | --                              | [90](90.md)                                        |
 | `expiration`      | unix timestamp (string)              | --                              | [40](40.md)                                        |
+| `file`            | full path (string)                   | --                              | [35](35.md)                                        |
 | `goal`            | event id (hex)                       | relay URL                       | [75](75.md)                                        |
 | `image`           | image URL                            | dimensions in pixels            | [23](23.md), [52](52.md), [58](58.md)              |
 | `imeta`           | inline metadata                      | --                              | [92](92.md)                                        |
@@ -304,6 +322,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `summary`         | summary                              | --                              | [23](23.md), [52](52.md)                           |
 | `thumb`           | badge thumbnail                      | dimensions in pixels            | [58](58.md)                                        |
 | `title`           | article title                        | --                              | [23](23.md)                                        |
+| `tracker`         | torrent tracker URL                  | --                              | [35](35.md)                                        |
 | `web`             | webpage URL                          | --                              | [34](34.md)                                        |
 | `zap`             | pubkey (hex), relay URL              | weight                          | [57](57.md)                                        |