Add previous tag

It's very confusing as to whether it refers to remote user pubkey vs remote signer pubkey. This is complicated further by the typo in the explanation of "remote signer pubkey".

01.md

@@ -81,7 +81,7 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
     - for a parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
     - for a non-parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
 
-As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"}` filter.
+As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter.
 
 ### Kinds
 
@@ -99,6 +99,8 @@ And also a convention for kind ranges that allow for easier experimentation and
 
 In case of replaceable events with the same timestamp, the event with the lowest id (first in lexical order) should be retained, and the other discarded.
 
+When the `previous` tag exists on a replaceable event relays SHOULD use this id as the id of the version the client wishes to replace, if the id does not match the stored version, relays MUST reject the update.
+
 When answering to `REQ` messages for replaceable events such as `{"kinds":[0],"authors":[<hex-key>]}`, even if the relay has more than one version stored, it SHOULD return just the latest one.
 
 These are just conventions and relay implementations may differ.

05.md

@@ -35,7 +35,7 @@ It will make a GET request to `https://example.com/.well-known/nostr.json?name=b
 }
 ````
 
-or with the **optional** `"relays"` attribute:
+or with the **recommended** `"relays"` attribute:
 
 ```json
 {
@@ -50,7 +50,7 @@ or with the **optional** `"relays"` attribute:
 
 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.
 
-The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays the specific user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available.
+The recommended `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays the specific user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available.
 
 ## Finding users from their NIP-05 identifier
 

18.md

@@ -20,9 +20,10 @@ reposted.
 
 ## Quote Reposts
 
-Quote reposts are `kind 1` events with an embedded `e` tag
-(see [NIP-08](08.md) and [NIP-27](27.md)). Because a quote repost includes
-an `e` tag, it may show up along replies to the reposted note.
+Quote reposts are `kind 1` events with an embedded `q` tag of the note being
+quote reposted. The `q` tag ensures quote reposts are not pulled and included
+as replies in threads. It also allows you to easily pull and count all of the
+quotes for a post.
 
 ## Generic Reposts
 

24.md

@@ -16,6 +16,7 @@ These are extra fields not specified in NIP-01 that may be present in the string
   - `display_name`: an alternative, bigger name with richer characters than `name`. `name` should always be set regardless of the presence of `display_name` in the metadata.
   - `website`: a web URL related in any way to the event author.
   - `banner`: an URL to a wide (~1024x768) picture to be optionally displayed in the background of a profile screen.
+  - `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
 
 ### Deprecated fields
 

28.md

@@ -23,11 +23,11 @@ Client-centric moderation gives client developers discretion over what types of
 
 Create a public chat channel.
 
-In the channel creation `content` field, Client SHOULD include basic channel metadata (`name`, `about`, `picture` as specified in kind 41).
+In the channel creation `content` field, Client SHOULD include basic channel metadata (`name`, `about`, `picture` and `relays` as specified in kind 41).
 
 ```json
 {
-  "content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\"}",
+  "content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
   ...
 }
 ```
@@ -46,6 +46,7 @@ Clients SHOULD support basic metadata fields:
 - `name` - string - Channel name
 - `about` - string - Channel description
 - `picture` - string - URL of channel picture
+- `relays` - array - List of relays to download and broadcast events to
 
 Clients MAY add additional metadata fields.
 
@@ -53,7 +54,7 @@ Clients SHOULD use [NIP-10](10.md) marked "e" tags to recommend a relay.
 
 ```json
 {
-  "content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\"}",
+  "content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
   "tags": [["e", <channel_create_event_id>, <relay-url>]],
   ...
 }
@@ -132,12 +133,11 @@ Clients MAY hide event 42s for users other than the user who sent the event 44.
 }
 ```
 
-## NIP-10 relay recommendations
+## Relay recommendations
 
-For [NIP-10](10.md) relay recommendations, clients generally SHOULD use the relay URL of the original (oldest) kind 40 event.
-
-Clients MAY recommend any relay URL. For example, if a relay hosting the original kind 40 event for a channel goes offline, clients could instead fetch channel data from a backup relay, or a relay that clients trust more than the original relay.
+Clients SHOULD use the relay URLs of the metadata events. 
 
+Clients MAY use any relay URL. For example, if a relay hosting the original kind 40 event for a channel goes offline, clients could instead fetch channel data from a backup relay, or a relay that clients trust more than the original relay.
 
 Motivation
 ----------

29.md

@@ -0,0 +1,197 @@
+NIP-29
+======
+
+Relay-based Groups
+------------------
+
+`draft` `optional`
+
+This NIP defines a standard for groups that are only writable by a closed set of users. They can be public for reading by external users or not.
+
+Groups are identified by a random string of any length that serves as an _id_.
+
+There is no way to create a group, what happens is just that relays (most likely when asked by users) will create rules around some specific ids so these ids can serve as an actual group, henceforth messages sent to that group will be subject to these rules.
+
+Normally a group will originally belong to one specific relay, but the community may choose to move the group to other relays or even fork the group so it exists in different forms -- still using the same _id_ -- across different relays.
+
+## Relay-generated events
+
+Relays are supposed to generate the events that describe group metadata and group admins. These are parameterized replaceable events signed by the relay keypair directly, with the group _id_ as the `d` tag.
+
+## Group identifier
+
+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`.
+
+## 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_.
+
+## Timeline references
+
+In order to not be used out of context, events sent to these groups may contain references to previous events seen from the same relay in the `previous` tag. The choice of which previous events to pick belongs to the clients. The references are to be made using the first 8 characters (4 bytes) of any event in the last 50 events seen by the user in the relay, excluding events by themselves. There can be any number of references (including zero), but it's recommended that clients include at least 3 and that relays enforce this.
+
+This is a hack to prevent messages from being broadcasted to external relays that have forks of one group out of context. Relays are expected to reject any events that contain timeline references to events not found in their own database. Clients should also check these to keep relays honest about them.
+
+## Late publication
+
+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
+
+- *text root note* (`kind:11`)
+
+This is the basic unit of a "microblog" root text note sent to a group.
+
+```js
+  "kind": 11,
+  "content": "hello my friends lovers of pizza",
+  "tags": [
+    ["h", "<group-id>"],
+    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", ...]
+  ]
+  ...
+```
+
+- *threaded text reply* (`kind:12`)
+
+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:
+
+* `["e", "<kind-11-root-id>", "", "root"]`
+* `["e", "<kind-12-event-id>", "", "reply"]`
+
+- *chat message* (`kind:9`)
+
+This is the basic unit of a _chat message_ sent to a group.
+
+```js
+  "kind": 9,
+  "content": "hello my friends lovers of pizza",
+  "tags": [
+    ["h", "<group-id>"],
+    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", ...]
+  ]
+  ...
+```
+
+- *chat message threaded reply* (`kind:10`)
+
+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).
+
+`kind:10` SHOULD use NIP-10 markers, just like `kind:12`.
+
+- *join request* (`kind:9021`)
+
+Any user can send one of these events to the relay in order to be automatically or manually added to the group. If the group is `open` the relay will automatically issue a `kind:9000` in response adding this user. Otherwise group admins may choose to query for these requests and act upon them.
+
+```js
+{
+  "kind": 9021,
+  "content": "optional reason",
+  "tags": [
+    ["h", "<group-id>"]
+  ]
+}
+```
+
+- *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.
+
+```js
+{
+  "kind": 90xx,
+  "content": "optional reason",
+  "tags": [
+    ["h", "<group-id>"],
+    ["previous", ...]
+  ]
+}
+```
+
+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` |
+
+- *group metadata* (`kind:39000`) (optional)
+
+This event defines the metadata for the group -- basically how clients should display it. It must be generated and signed by the relay in which is found. Relays shouldn't accept these events if they're signed by anyone else.
+
+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.
+
+```js
+{
+  "kind": 39000,
+  "content": "",
+  "tags": [
+    ["d", "<group-id>"],
+    ["name", "Pizza Lovers"],
+    ["picture", "https://pizza.com/pizza.png"],
+    ["about", "a group for people who love pizza"],
+    ["public"], // or ["private"]
+    ["open"] // or ["closed"]
+  ]
+  ...
+}
+```
+
+`name`, `picture` and `about` are basic metadata for the group for display purposes. `public` signals the group can be _read_ by anyone, while `private` signals that only AUTHed users can read. `open` signals that anyone can request to join and the request will be automatically granted, while `closed` signals that members must be pre-approved or that requests to join will be manually handled.
+
+- *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 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`
+
+```js
+{
+  "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"]
+  ]
+  ...
+}
+```
+
+- *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 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.
+
+```json
+{
+  "kind": 39002,
+  "content": "list of members for the pizza lovers group",
+  "tags": [
+    ["d", "<group-id>"],
+    ["p", "<admin1>"],
+    ["p", "<member-pubkey1>"],
+    ["p", "<member-pubkey2>"],
+  ]
+}
+```
+
+## Storing the list of groups a user belongs to
+
+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.

34.md

@@ -0,0 +1,102 @@
+NIP-34
+======
+
+`git` stuff
+-----------
+
+`draft` `optional`
+
+This NIP defines all the ways code collaboration using and adjacent to [`git`](https://git-scm.com/) can be done using Nostr.
+
+## Repository announcements
+
+Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events, as well as their willingness to receive patches, bug reports and comments in general.
+
+```jsonc
+{
+  "kind": 30617,
+  "content": "",
+  "tags": [
+    ["d", "<repo-id>"],
+    ["name", "<human-readable project name>"],
+    ["description", "brief human-readable project description>"],
+    ["web", "<url for browsing>", ...], // a webpage url, if the git server being used provides such a thing
+    ["clone", "<url for git-cloning>", ...], // a url to be given to `git clone` so anyone can clone it
+    ["relays", "<relay-url>", ...] // relays that this repository will monitor for patches and issues
+  ]
+}
+```
+
+The tags `web`, `clone`, `relays` can have multiple values.
+
+Except `d`, all tags are optional.
+
+## Patches
+
+Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch events SHOULD include an `a` tag pointing to that repository's announcement address.
+
+```jsonc
+{
+  "kind": 1617,
+  "content": "<patch>", // contents of <git format-patch>
+  "tags": [
+    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
+    ["p", "<repository-owner>"],
+    ["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention
+
+    // for the first patch in a thread or series
+    ["t", "root"],
+
+    // optional tags for when it is desirable that the merged patch has a stable commit id
+    // these fields are necessary for ensuring that the commit resulting from applying a patch
+    // has the same id as it had in the proposer's machine -- all these tags can be omitted
+    // if the maintainer doesn't care about these things
+    ["commit", "<current-commit-id>"],
+    ["parent-commit", "<parent-commit-id>"],
+    ["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit
+    ["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"],
+  ]
+}
+```
+
+## Issues
+
+Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag.
+
+```jsonc
+{
+  "kind": 1621,
+  "content": "<markdown text>",
+  "tags": [
+    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
+    ["p", "<repository-owner>"]
+  ]
+}
+```
+
+## Replies
+
+Replies are also Markdown text. The difference is that they MUST be issued as replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event. The threading of replies and patches should follow NIP-10 rules.
+
+```jsonc
+{
+  "kind": 1622,
+  "content": "<markdown text>",
+  "tags": [
+    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
+    ["e", "<issue-or-patch-id-hex>", "", "root"],
+
+    // other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
+    ["p", "<patch-author-pubkey-hex>", "", "mention"],
+    ["e", "<previous-reply-id-hex>", "", "reply"],
+    // ...
+  ]
+}
+```
+
+## Possible things to be added later
+
+- "status" kind (for letting people know a patch was merged or an issue was fixed or won't be fixed)
+- "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
+- "cover letter" kind (to which multiple patches can refer and serve as a unifying layer to them)
+- inline file comments kind (we probably need one for patches and a different one for merged files)

46.md

@@ -25,7 +25,7 @@ This is most common in a situation where you have your own nsecbunker or other t
 The remote signer would provide a connection token in the form:
 
 ```
-bunker://<remote-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
+bunker://<remote-user-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
 ```
 
 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).
@@ -120,7 +120,7 @@ Each of the following are methods that the client sends to the remote signer.
 
 | Command                  | Params                                            | Result                                                                 |
 | ------------------------ | ------------------------------------------------- | ---------------------------------------------------------------------- |
-| `connect`                | `[<remote_user_pubkey>, <optional_secret>]`       | "ack"                                                                  |
+| `connect`                | `[<remote_user_pubkey>, <optional_secret>, <optional_requested_permissions>]`       | "ack"                                                                  |
 | `sign_event`             | `[<json_stringified_event_to_sign>]`              | `json_stringified(<signed_event>)`                                     |
 | `ping`                   | `[]`                                              | "pong"                                                                 |
 | `get_relays`             | `[]`                                              | `json_stringified({<relay_url>: {read: <boolean>, write: <boolean>}})` |
@@ -130,6 +130,10 @@ Each of the following are methods that the client sends to the remote signer.
 | `nip44_encrypt`          | `[<third_party_pubkey>, <plaintext_to_encrypt>]`  | `<nip44_ciphertext>`                                                   |
 | `nip44_decrypt`          | `[<third_party_pubkey>, <nip44_ciphertext_to_decrypt>]` | `<plaintext>`                                                    |
 
+### 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. 
+
 ## Response Events `kind:24133`
 
 ```json
@@ -185,7 +189,7 @@ Each of the following are methods that the client sends to the remote signer.
 
 | Command          | Params                                     | Result                               |
 | ---------------- | ------------------------------------------ | ------------------------------------ |
-| `create_account` | `[<username>, <domain>, <optional_email>]` | `<newly_created_remote_user_pubkey>` |
+| `create_account` | `[<username>, <domain>, <optional_email>, <optional_requested_permissions>]` | `<newly_created_remote_user_pubkey>` |
 
 ## Appendix
 

50.md

@@ -47,3 +47,7 @@ Relays SHOULD exclude spam from search results by default if they support some f
 
 Relay MAY support these extensions:
 - `include:spam` - turn off spam filtering, if it was enabled by default
+- `domain:<domain>` - include only events from users whose valid nip05 domain matches the domain
+- `language:<two letter ISO 639-1 language code>` - include only events of a specified language
+- `sentiment:<negative/neutral/positive>` - include only events of a specific sentiment
+- `nsfw:<true/false>` - include or exclude nsfw events (default: true)

51.md

@@ -29,6 +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)                       |
 | 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)                  |
 

56.md

@@ -4,10 +4,12 @@ NIP-56
 Reporting
 ---------
 
-`draft` `optional`
+`optional`
 
-A report is a `kind 1984` note that is used to report other notes for spam,
-illegal and explicit content.
+A report is a `kind 1984` event that signals to users and relays that 
+some referenced content is objectionable. The definition of objectionable is
+obviously subjective and all agents on the network (users, apps, relays, etc.) 
+may consume and take action on them as they see fit.
 
 The `content` MAY contain additional information submitted by the entity
 reporting the content.
@@ -28,6 +30,7 @@ being reported, which consists of the following report types:
 - `illegal` - something which may be illegal in some jurisdiction
 - `spam` - spam
 - `impersonation` - someone pretending to be someone else
+- `other` - for reports that don't fit in the above categories
 
 Some report tags only make sense for profile reports, such as `impersonation`
 

58.md

@@ -83,7 +83,7 @@ Clients SHOULD attempt to render the most appropriate badge thumbnail according
     ["name", "Medal of Bravery"],
     ["description", "Awarded to users demonstrating bravery"],
     ["image", "https://nostr.academy/awards/bravery.png", "1024x1024"],
-    ["thumb", "https://nostr.academy/awards/bravery_256x256.png", "256x256"],
+    ["thumb", "https://nostr.academy/awards/bravery_256x256.png", "256x256"]
   ],
   ...
 }
@@ -99,7 +99,7 @@ Clients SHOULD attempt to render the most appropriate badge thumbnail according
   "tags": [
     ["a", "30009:alice:bravery"],
     ["p", "bob", "wss://relay"],
-    ["p", "charlie", "wss://relay"],
+    ["p", "charlie", "wss://relay"]
   ],
   ...
 }
@@ -117,7 +117,7 @@ Honorable Bob The Brave:
     ["a", "30009:alice:bravery"],
     ["e", "<bravery badge award event id>", "wss://nostr.academy"],
     ["a", "30009:alice:honor"],
-    ["e", "<honor badge award event id>", "wss://nostr.academy"],
+    ["e", "<honor badge award event id>", "wss://nostr.academy"]
   ],
   ...
 }

96.md

@@ -82,14 +82,7 @@ it must use the "api_url" field instead.
 
 ### List of Supporting File Storage Servers
 
-| Name          | Domain                    |
-| ------------- | ------------------------- |
-| nostrcheck.me | https://nostrcheck.me     |
-| nostrage      | https://nostrage.com      |
-| sove          | https://sove.rent         |
-| nostr.build   | https://nostr.build       |
-| sovbit        | https://files.sovbit.host |
-| void.cat      | https://void.cat          |
+See https://github.com/aljazceru/awesome-nostr#nip-96-file-storage-servers.
 
 ## Upload
 

BREAKING.md

@@ -5,6 +5,8 @@ reverse chronological order.
 
 | Date        | Commit    | NIP      | Change |
 | ----------- | --------- | -------- | ------ |
+| 2024-02-25  | [4a171cb0](https://github.com/nostr-protocol/nips/commit/4a171cb0) | [NIP-18](18.md) | quote repost should use `q` tag |
+| 2024-02-10  | [c6cd655c](https://github.com/nostr-protocol/nips/commit/c6cd655c) | [NIP-46](46.md) | Params were stringified |
 | 2024-02-16  | [cbec02ab](https://github.com/nostr-protocol/nips/commit/cbec02ab) | [NIP-49](49.md) | Password first normalized to NFKC |
 | 2024-02-15  | [afbb8dd0](https://github.com/nostr-protocol/nips/commit/afbb8dd0) | [NIP-39](39.md) | PGP identity was removed |
 | 2024-02-07  | [d3dad114](https://github.com/nostr-protocol/nips/commit/d3dad114) | [NIP-46](46.md) | Connection token format was changed |

README.md

@@ -45,9 +45,11 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-26: Delegated Event Signing](26.md)
 - [NIP-27: Text Note References](27.md)
 - [NIP-28: Public Chat](28.md)
+- [NIP-29: Relay-based Groups](29.md)
 - [NIP-30: Custom Emoji](30.md)
 - [NIP-31: Dealing with Unknown Events](31.md)
 - [NIP-32: Labeling](32.md)
+- [NIP-34: `git` stuff](34.md)
 - [NIP-36: Sensitive Content](36.md)
 - [NIP-38: User Statuses](38.md)
 - [NIP-39: External Identities in Profiles](39.md)
@@ -92,6 +94,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)              |
 | `13`          | Seal                       | [59](59.md)              |
 | `16`          | Generic Repost             | [18](18.md)              |
 | `40`          | Channel Creation           | [28](28.md)              |
@@ -105,6 +111,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1059`        | Gift Wrap                  | [59](59.md)              |
 | `1063`        | File Metadata              | [94](94.md)              |
 | `1311`        | Live Chat Message          | [53](53.md)              |
+| `1617`        | Patches                    | [34](34.md)              |
+| `1621`        | Issues                     | [34](34.md)              |
+| `1622`        | Replies                    | [34](34.md)              |
 | `1971`        | Problem Tracker            | [nostrocket][nostrocket] |
 | `1984`        | Reporting                  | [56](56.md)              |
 | `1985`        | Label                      | [32](32.md)              |
@@ -112,6 +121,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `5000`-`5999` | Job Request                | [90](90.md)              |
 | `6000`-`6999` | Job Result                 | [90](90.md)              |
 | `7000`        | Job Feedback               | [90](90.md)              |
+| `9000`-`9030` | Group Control Events       | [29](29.md)              |
 | `9041`        | Zap Goal                   | [75](75.md)              |
 | `9734`        | Zap Request                | [57](57.md)              |
 | `9735`        | Zap                        | [57](57.md)              |
@@ -124,6 +134,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10005`       | Public chats list          | [51](51.md)              |
 | `10006`       | Blocked relays list        | [51](51.md)              |
 | `10007`       | Search relays list         | [51](51.md)              |
+| `10009`       | User groups                | [51](51.md), [29](29.md) |
 | `10015`       | Interests list             | [51](51.md)              |
 | `10030`       | User emoji list            | [51](51.md)              |
 | `10096`       | File storage server list   | [96](96.md)              |
@@ -155,6 +166,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30315`       | User Statuses              | [38](38.md)              |
 | `30402`       | Classified Listing         | [99](99.md)              |
 | `30403`       | Draft Classified Listing   | [99](99.md)              |
+| `30617`       | Repository announcements   | [34](34.md)              |
 | `31922`       | Date-Based Calendar Event  | [52](52.md)              |
 | `31923`       | Time-Based Calendar Event  | [52](52.md)              |
 | `31924`       | Calendar                   | [52](52.md)              |
@@ -162,6 +174,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `31989`       | Handler recommendation     | [89](89.md)              |
 | `31990`       | Handler information        | [89](89.md)              |
 | `34550`       | Community Definition       | [72](72.md)              |
+| `39000-9`     | Group metadata events      | [29](29.md)              |
 
 [nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
 [lnpub]: https://github.com/shocknet/Lightning.Pub/blob/master/proto/autogenerated/client.md
@@ -206,6 +219,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `l`               | label, label namespace               | annotations          | [32](32.md)                           |
 | `L`               | label namespace                      | --                   | [32](32.md)                           |
 | `m`               | MIME type                            | --                   | [94](94.md)                           |
+| `q`               | event id (hex)                       | relay URL    | [18](18.md)                           |
 | `r`               | a reference (URL, etc)               | petname              |                                       |
 | `r`               | relay url                            | marker               | [65](65.md)                           |
 | `t`               | hashtag                              | --                   |                                       |
@@ -214,9 +228,10 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `bolt11`          | `bolt11` invoice                     | --                   | [57](57.md)                           |
 | `challenge`       | challenge string                     | --                   | [42](42.md)                           |
 | `client`          | name, address                        | relay URL            | [89](89.md)                           |
+| `clone`           | git clone URL                        | --                   | [34](34.md)                           |
 | `content-warning` | reason                               | --                   | [36](36.md)                           |
 | `delegation`      | pubkey, conditions, delegation token | --                   | [26](26.md)                           |
-| `description`     | invoice/badge description            | --                   | [57](57.md), [58](58.md)              |
+| `description`     | description                          | --                   | [34](34.md), [57](57.md), [58](58.md) |
 | `emoji`           | shortcode, image URL                 | --                   | [30](30.md)                           |
 | `encrypted`       | --                                   | --                   | [90](90.md)                           |
 | `expiration`      | unix timestamp (string)              | --                   | [40](40.md)                           |
@@ -225,7 +240,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `imeta`           | inline metadata                      | --                   | [92](92.md)                           |
 | `lnurl`           | `bech32` encoded `lnurl`             | --                   | [57](57.md)                           |
 | `location`        | location string                      | --                   | [52](52.md), [99](99.md)              |
-| `name`            | badge name                           | --                   | [58](58.md)                           |
+| `name`            | name                                 | --                   | [34](34.md), [58](58.md)              |
 | `nonce`           | random                               | --                   | [13](13.md)                           |
 | `preimage`        | hash of `bolt11` invoice             | --                   | [57](57.md)                           |
 | `price`           | price                                | currency, frequency  | [99](99.md)                           |
@@ -238,6 +253,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `summary`         | article summary                      | --                   | [23](23.md)                           |
 | `thumb`           | badge thumbnail                      | dimensions in pixels | [58](58.md)                           |
 | `title`           | article title                        | --                   | [23](23.md)                           |
+| `web`             | webpage URL                          | --                   | [34](34.md)                           |
 | `zap`             | pubkey (hex), relay URL              | weight               | [57](57.md)                           |
 
 ## Criteria for acceptance of NIPs