add kind:10 threaded chat replies.

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
 

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 **recommended** `"relays"` attribute:
+or with the **optional** `"relays"` attribute:
 
 ```json
 {
@@ -50,7 +50,7 @@ or with the **recommended** `"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 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.
+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.
 
 ## Finding users from their NIP-05 identifier
 

18.md

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

24.md

@@ -16,7 +16,6 @@ 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` and `relays` as specified in kind 41).
+In the channel creation `content` field, Client SHOULD include basic channel metadata (`name`, `about`, `picture` as specified in kind 41).
 
 ```json
 {
-  "content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
+  "content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\"}",
   ...
 }
 ```
@@ -46,7 +46,6 @@ 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.
 
@@ -54,7 +53,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\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
+  "content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\"}",
   "tags": [["e", <channel_create_event_id>, <relay-url>]],
   ...
 }
@@ -133,11 +132,12 @@ Clients MAY hide event 42s for users other than the user who sent the event 44.
 }
 ```
 
-## Relay recommendations
+## NIP-10 relay recommendations
 
-Clients SHOULD use the relay URLs of the metadata events. 
+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 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
 ----------

34.md

@@ -1,102 +0,0 @@
-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-user-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
+bunker://<remote-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>, <optional_requested_permissions>]`       | "ack"                                                                  |
+| `connect`                | `[<remote_user_pubkey>, <optional_secret>]`       | "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,10 +130,6 @@ 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
@@ -189,7 +185,7 @@ 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>` |
+| `create_account` | `[<username>, <domain>, <optional_email>]` | `<newly_created_remote_user_pubkey>` |
 
 ## Appendix
 

50.md

@@ -47,7 +47,3 @@ 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)

56.md

@@ -4,12 +4,10 @@ NIP-56
 Reporting
 ---------
 
-`optional`
+`draft` `optional`
 
-A report is a `kind 1984` event that signals to users and relays that 
+A report is a `kind 1984` note that is used to report other notes for spam,
-some referenced content is objectionable. The definition of objectionable is
+illegal and explicit content.
-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.
@@ -30,7 +28,6 @@ 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"],
   ],
   ...
 }

91.md

@@ -1,52 +0,0 @@
-NIP-91
-======
-
-EOSE Extensions
----------------
-
-`draft` `optional`
-
-This NIP defines an extension to the EOSE message that allows relays to convey additional information to clients.
-
-## Extended EOSE
-
-An extended EOSE is an EOSE message, with the 2nd parameter being the "extensions object". For example: `["EOSE","example-sub",{"example_ext":"example value"}]`
-
-An EOSE extension is a field in the extensions object. This may contain any value.
-
-Clients MUST NOT rely on relays implementing any extensions.
-
-## Extensions
-
-This NIP defines a set of standard extensions.
-
-### `next_created_at`
-`recommended`
-
-The value of this extension MUST be an integer if present, and should specify the next `until` value the client should use for pagination.
-This MAY be higher or lower than the lowest `created_at`, and the clients SHOULD NOT perform any modifications to this value.
-
-### `cursor`
-
-The value of this extension MUST be a string or `null` if present, and represents a cursor the client can use to paginate this query.
-If the value is `null`, then it indicates that no more events are available for the given set of filters.
-To get more events, the client MUST send a `REQ` with the same filters (except limit, which can be changed), and the `cursor` string
-in the 1st filter with the key `cursor`. Example:
-```jsonc
-< ["REQ", "examplereq1", {"kinds": [1], "limit": 1}, {"authors": ["..."], "limit": 1}]
-> ["EVENT", "examplereq1", ...]
-> ["EOSE", "examplereq1", {"cursor": "example-cursor-string", ...}]
-< ["CLOSE", "examplereq1"]
-< ["REQ", "examplereq2", {"kinds": [1], "limit": 5, "cursor": "example-cursor-string"}, {"authors": ["..."], "limit": 5}]
-> ["EVENT", "examplereq2", ...]
-...
-```
-
-This cursor MUST be valid for the duration of the connection, and MAY be valid in a new connection. A relay may indicate a cursor is no longer valid
-by sending a CLOSED with the prefix `bad-cursor: `.
-
-### `auth_recommended`
-
-The value of this extension MUST be a boolean if present, and indicates if the client should `AUTH` to get more events that match this query.
-This is a less disruptive alternative to `CLOSED` with `auth-required:` for filters that don't explicitly ask for access controlled events,
-but may match them.

96.md

@@ -82,7 +82,14 @@ it must use the "api_url" field instead.
 
 ### List of Supporting File Storage Servers
 
-See https://github.com/aljazceru/awesome-nostr#nip-96-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          |
 
 ## Upload
 

BREAKING.md

@@ -5,8 +5,6 @@ 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

@@ -49,7 +49,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [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)
@@ -111,9 +110,6 @@ 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)              |
@@ -166,15 +162,14 @@ 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)              |
 | `31925`       | Calendar Event RSVP        | [52](52.md)              |
 | `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)              |
+| `34550`       | Community Definition       | [72](72.md)              |
 
 [nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
 [lnpub]: https://github.com/shocknet/Lightning.Pub/blob/master/proto/autogenerated/client.md
@@ -219,7 +214,6 @@ 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                              | --                   |                                       |
@@ -228,10 +222,9 @@ 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`     | description                          | --                   | [34](34.md), [57](57.md), [58](58.md) |
+| `description`     | invoice/badge description            | --                   | [57](57.md), [58](58.md)              |
 | `emoji`           | shortcode, image URL                 | --                   | [30](30.md)                           |
 | `encrypted`       | --                                   | --                   | [90](90.md)                           |
 | `expiration`      | unix timestamp (string)              | --                   | [40](40.md)                           |
@@ -240,7 +233,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`            | name                                 | --                   | [34](34.md), [58](58.md)              |
+| `name`            | badge name                           | --                   | [58](58.md)                           |
 | `nonce`           | random                               | --                   | [13](13.md)                           |
 | `preimage`        | hash of `bolt11` invoice             | --                   | [57](57.md)                           |
 | `price`           | price                                | currency, frequency  | [99](99.md)                           |
@@ -253,7 +246,6 @@ 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