NIP-91: reduce complaints

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
 

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
 

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
 ----------

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
 

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"]
   ],
   ...
 }

91.md

@@ -0,0 +1,52 @@
+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.

BREAKING.md

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

@@ -173,8 +173,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `31925`       | Calendar Event RSVP        | [52](52.md)              |
 | `31989`       | Handler recommendation     | [89](89.md)              |
 | `31990`       | Handler information        | [89](89.md)              |
-| `39000-9`     | Group metadata events      | [29](29.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