From 4b79bc67c471f77061d62704538e5fdd6ac28ae8 Mon Sep 17 00:00:00 2001 From: "Nostr.Band" <124499563+nostrband@users.noreply.github.com> Date: Fri, 22 Mar 2024 08:01:37 +0100 Subject: Add optional_requested_permissions This is implemented in nsec.app, nostr.band, Coracle and Nostrudel, so maybe it's time to update the NIP. --- 46.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to '46.md') diff --git a/46.md b/46.md index eb96494..8ba65d9 100644 --- a/46.md +++ b/46.md @@ -120,7 +120,7 @@ Each of the following are methods that the client sends to the remote signer. | Command | Params | Result | | ------------------------ | ------------------------------------------------- | ---------------------------------------------------------------------- | -| `connect` | `[, ]` | "ack" | +| `connect` | `[, , ]` | "ack" | | `sign_event` | `[]` | `json_stringified()` | | `ping` | `[]` | "pong" | | `get_relays` | `[]` | `json_stringified({: {read: , write: }})` | @@ -130,6 +130,10 @@ Each of the following are methods that the client sends to the remote signer. | `nip44_encrypt` | `[, ]` | `` | | `nip44_decrypt` | `[, ]` | `` | +### 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 -- cgit v1.2.3 From b765b3c0301958d46115b834872bbd0c8bac588c Mon Sep 17 00:00:00 2001 From: kuiperanon <164939804+kuiperanon@users.noreply.github.com> Date: Tue, 9 Apr 2024 11:25:05 -0500 Subject: Clarify use of ambiguous terminology in spec of bunker token 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". --- 46.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '46.md') diff --git a/46.md b/46.md index 8ba65d9..56b8402 100644 --- a/46.md +++ b/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). -- cgit v1.2.3 From 6071f3489eabe50eea748a2585a73c02a23d96cf Mon Sep 17 00:00:00 2001 From: Alex Gleason <alex@alexgleason.me> Date: Thu, 25 Apr 2024 06:38:36 -0500 Subject: NIP-46: "error" property of response is optional (#1195) * NIP-46: clarify "error" property of response * NIP-46: It's -> Its * optionally Co-authored-by: Asai Toshiya <to.asai.60@gmail.com> --------- Co-authored-by: fiatjaf_ <fiatjaf@gmail.com> Co-authored-by: Asai Toshiya <to.asai.60@gmail.com> --- 46.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to '46.md') diff --git a/46.md b/46.md index 56b8402..d4b5728 100644 --- a/46.md +++ b/46.md @@ -153,13 +153,13 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](https://github.c { "id": <request_id>, "result": <results_string>, - "error": <error_string> + "error": <optional_error_string> } ``` - `id` is the request ID that this response is for. - `results` is a string of the result of the call (this can be either a string or a JSON stringified object) -- `error` is an error in string form. +- `error`, _optionally_, it is an error in string form, if any. Its presence indicates an error with the request. ### Auth Challenges -- cgit v1.2.3 From 243b2865826edff22eebe5ec6e893c711802c7e5 Mon Sep 17 00:00:00 2001 From: fiatjaf <fiatjaf@gmail.com> Date: Thu, 25 Apr 2024 18:03:38 -0300 Subject: nip46: signer should fill in pubkey, id and sig on sign_event. --- 46.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) (limited to '46.md') diff --git a/46.md b/46.md index d4b5728..e0a5b2e 100644 --- a/46.md +++ b/46.md @@ -61,8 +61,9 @@ nostrconnect://<local-keypair-pubkey>?relay=<wss://relay-to-connect-on>&metadata "method": "sign_event", "params": [json_stringified(<{ content: "Hello, I'm signing remotely", - pubkey: "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52", - // ...the rest of the event data + kind: 1, + tags: [], + created_at: 1714078911 }>)] }), "tags": [["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]], // p-tags the remote user pubkey @@ -118,21 +119,21 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](https://github.c 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" | -| `sign_event` | `[<json_stringified_event_to_sign>]` | `json_stringified(<signed_event>)` | -| `ping` | `[]` | "pong" | -| `get_relays` | `[]` | `json_stringified({<relay_url>: {read: <boolean>, write: <boolean>}})` | -| `get_public_key` | `[]` | `<hex-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>` | -| `nip44_decrypt` | `[<third_party_pubkey>, <nip44_ciphertext_to_decrypt>]` | `<plaintext>` | +| Command | Params | Result | +| ------------------------ | ------------------------------------------------- | ---------------------------------------------------------------------- | +| `connect` | `[<remote_user_pubkey>, <optional_secret>, <optional_requested_permissions>]` | "ack" | +| `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>` | +| `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>` | +| `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. +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` -- cgit v1.2.3 From cb9bddb8dfd11972286215d9bdee7434764ccf7b Mon Sep 17 00:00:00 2001 From: Adam Shannon <adamkshannon@gmail.com> Date: Sat, 11 May 2024 11:52:32 -0500 Subject: all: minor spelling fixes --- 34.md | 2 +- 46.md | 2 +- 54.md | 2 +- 72.md | 2 +- 90.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) (limited to '46.md') diff --git a/34.md b/34.md index 03ee039..fcc2cec 100644 --- a/34.md +++ b/34.md @@ -125,7 +125,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by ["p", "<root-event-author>"], ["p", "<revision-author>"], - // optional for improved subscription filter efficency + // optional for improved subscription filter efficiency ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"], ["r", "<earliest-unique-commit-id-of-repo>"] diff --git a/46.md b/46.md index e0a5b2e..1528116 100644 --- a/46.md +++ b/46.md @@ -208,7 +208,7 @@ When the user types a NIP-05 the client: #### Remote signer discovery via NIP-89 -In this last case, most often used to fascilitate an OAuth-like signin flow, the client first looks for remote signers that have announced themselves via NIP-89 application handler events. +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. First the client will query for `kind: 31990` events that have a `k` tag of `24133`. diff --git a/54.md b/54.md index 2090182..8823af9 100644 --- a/54.md +++ b/54.md @@ -79,7 +79,7 @@ Wiki-events can tag other wiki-events with a `defer` marker to indicate that it This is a stronger signal of trust than a `+` reaction. -This marker is useful when a user edits someone else's entry; if the original author includes the editor's changes and the editor doesn't want to keep/maintain an indepedent version, the `link` tag could effectively be a considered a "deletion" of the editor's version and putting that pubkey's WoT weight behind the original author's version. +This marker is useful when a user edits someone else's entry; if the original author includes the editor's changes and the editor doesn't want to keep/maintain an independent version, the `link` tag could effectively be a considered a "deletion" of the editor's version and putting that pubkey's WoT weight behind the original author's version. Why Markdown? ------------- diff --git a/72.md b/72.md index 4bafce0..5a8be0a 100644 --- a/72.md +++ b/72.md @@ -76,7 +76,7 @@ The post-approval event MUST include `a` tags of the communities the moderator i It's recommended that multiple moderators approve posts to avoid deleting them from the community when a moderator is removed from the owner's list. In case the full list of moderators must be rotated, the new moderator set must sign new approvals for posts in the past or the community will restart. The owner can also periodically copy and re-sign of each moderator's approval events to make sure posts don't disappear with moderators. -Post Approvals of replaceable events can be created in three ways: (i) by tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the repleceable event; (ii) by tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and (iii) by tagging the replaceable event with both its `e` and `a` tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI. Since relays are instructed to delete old versions of a replaceable event, the `.content` of an `e`-approval MUST have the specific version of the event or Clients might not be able to find that version of the content anywhere. +Post Approvals of replaceable events can be created in three ways: (i) by tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the replaceable event; (ii) by tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and (iii) by tagging the replaceable event with both its `e` and `a` tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI. Since relays are instructed to delete old versions of a replaceable event, the `.content` of an `e`-approval MUST have the specific version of the event or Clients might not be able to find that version of the content anywhere. Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be included in all `34550:*` `a` tags. diff --git a/90.md b/90.md index 241eb38..2b499a8 100644 --- a/90.md +++ b/90.md @@ -199,7 +199,7 @@ Some service providers might choose to submit a `payment-required` as the first It's not up to this NIP to define how individual vending machines should choose to run their business. # Cancellation -A job request might be cancelled by publishing a `kind:5` delete request event tagging the job request event. +A job request might be canceled by publishing a `kind:5` delete request event tagging the job request event. # Appendix 1: Job chaining A Customer MAY request multiple jobs to be processed as a chain, where the output of a job is the input of another job. (e.g. podcast transcription -> summarization of the transcription). This is done by specifying as input an event id of a different job with the `job` type. -- cgit v1.2.3