From f276b9b26bf4e19944d604e4ff5f2e809de3a084 Mon Sep 17 00:00:00 2001 From: s3-odara Date: Thu, 28 Nov 2024 02:25:18 +0900 Subject: [PATCH 1/9] =?UTF-8?q?NIP-04=E3=82=92=E7=BF=BB=E8=A8=B3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 04.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/04.md b/04.md index 3c22ba0a..c0570320 100644 --- a/04.md +++ b/04.md @@ -1,4 +1,4 @@ -> __Warning__ `unrecommended`: deprecated in favor of [NIP-17](17.md) +> __警告__ `非推奨`: [NIP-17](17.md) を支持して廃止された。 NIP-04 ====== From 558cdfe7d07d9b792807376e062e12b817160619 Mon Sep 17 00:00:00 2001 From: s3-odara Date: Fri, 29 Nov 2024 23:22:00 +0900 Subject: [PATCH 2/9] =?UTF-8?q?NIP-30:=20=E8=BF=BD=E5=8A=A0=E9=83=A8?= =?UTF-8?q?=E5=88=86=E3=82=92=E7=BF=BB=E8=A8=B3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 30.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/30.md b/30.md index 47b2478e..87fdcba4 100644 --- a/30.md +++ b/30.md @@ -55,9 +55,10 @@ kind 1のイベントにおいては、`content`フィールドにカスタム } ``` -### Kind 7 events +### Kind 7 イベント In kind 7 events, the `content` should be emojified. +kind 7のイベントにおいては、`content`フィールドにカスタム絵文字を使用してよく、クライアントはこれを「絵文字化」するべきである。 ```json { From ade69a40fd2cc5cf6d1d3496c640d14dd0e0e140 Mon Sep 17 00:00:00 2001 From: s3-odara Date: Fri, 29 Nov 2024 23:22:56 +0900 Subject: [PATCH 3/9] =?UTF-8?q?NIP-46:=20=E8=BF=BD=E5=8A=A0=E9=83=A8?= =?UTF-8?q?=E5=88=86=E3=81=AE=E7=BF=BB=E8=A8=B3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 46.md | 142 ++++++++++++++++++++++++++++++---------------------------- 1 file changed, 73 insertions(+), 69 deletions(-) diff --git a/46.md b/46.md index ae36706b..33b60bef 100644 --- a/46.md +++ b/46.md @@ -4,9 +4,9 @@ NIP-46 Nostr Remote Signing -------------------- -## Changes +## 変更点 -`remote-signer-key` is introduced, passed in bunker url, clients must differentiate between `remote-signer-pubkey` and `user-pubkey`, must call `get_public_key` after connect, nip05 login is removed, create_account moved to another NIP. +`リモート署名鍵`が導入され、バンカーurlで渡される。クライアントは`リモート署名器公開鍵`と`ユーザー公開鍵`を区別する必要があり、接続後に`get_public_key`メソッドを呼び出す必要がある。nip05ログインが削除され、create_accountメソッドは別のNIPに移動された。 ## 根拠 @@ -27,11 +27,11 @@ Nostr Remote Signing ## 概説 -1. _クライアント_が`client-keypair`を生成する。この鍵ペアは主に使い捨てであるため_ユーザー_に伝える必要はない。クライアントはそれをローカルに保存することを選択できるが、ログアウト時に削除するべきである。 -2. 接続が確立され、 (下記参照) _リモート署名器_は`client-pubkey`を得て、_クライアント_は`remote-signer-pubkey`を得る。 -3. _クライアント_は`client-keypair`を使用して`remote-signer-pubkey`へ`p`タグを付け、暗号化して_リモート署名器_にリクエストを送信する。 -4. _リモート署名器_は`client-pubkey`へ`p`タグを付け、暗号化して _クライアント_ に応答する。 -5. _クライアント_は`user-pubkey`を得るために`get_public_key`をリクエストする。 +1. _クライアント_が`クライアント鍵ペア`を生成する。この鍵ペアは主に使い捨てであるため_ユーザー_に伝える必要はない。クライアントはそれをローカルに保存することを選択できるが、ログアウト時に削除するべきである。 +2. 接続が確立され、 (下記参照) _リモート署名器_は`クライアント公開鍵`を得て、_クライアント_は`リモート署名器公開鍵`を得る。 +3. _クライアント_は`クライアント鍵ペア`を使用して`リモート署名器公開鍵`へ`p`タグを付け、暗号化して_リモート署名器_にリクエストを送信する。 +4. _リモート署名器_は`クライアント公開鍵`へ`p`タグを付け、暗号化して _クライアント_ に応答する。 +5. _クライアント_は`ユーザー公開鍵`を得るために`get_public_key`をリクエストする。 ## 接続の開始 @@ -42,7 +42,7 @@ Nostr Remote Signing _リモート署名器_は、接続トークンを以下の形式で提供する: ``` -bunker://?relay=&relay=&secret= +bunker://<リモート署名器公開鍵>?relay=&relay=&secret=<オプションのシークレット> ``` このトークンはユーザーによって_クライアント_に渡され、クライアントは指定されたリレーを介してリモート署名器に`connect`リクエストを送る。オプションのシークレットは、正常な1回の接続確立にのみ使用でき、_リモート署名者_は古いシークレットを用いて新たに接続を確立しようとする試みを無視するべきだ (SHOULD)。 @@ -52,97 +52,99 @@ bunker://?relay=&relay=?relay=&metadata=&secret= +nostrconnect://<クライアント公開鍵>?relay=&metadata=&secret=<必須のシークレット> ``` -このトークンはユーザーによって_リモート署名器_に渡され、リモート署名器は指定されたリレーを介して`client-pubkey`に`connect`*応答*イベントを送る。クライアントは接続応答の作成者から`remote-signer-pubkey`を探す。接続相手のなりすましを防ぐために`secret`値を指定する必要があり (MUST) _クライアント_は`connect`応答によって得られた`secret`を検証する必要がある (MUST)。 +このトークンはユーザーによって_リモート署名器_に渡され、リモート署名器は指定されたリレーを介して`クライアント公開鍵`に`connect`*応答*イベントを送る。クライアントは接続応答の作成者から`リモート署名器公開鍵`を探す。接続相手のなりすましを防ぐために`シークレット`値を指定する必要があり (MUST) _クライアント_は`connect`応答によって得られた`シークレット`を検証する必要がある (MUST)。 -## Request Events `kind: 24133` +## リクエストイベント `kind: 24133` ```jsonc { "kind": 24133, - "pubkey": , - "content": )>, - "tags": [["p", ]], + "pubkey": <ローカル鍵ペア公開鍵>, + "content": )>, + "tags": [["p", <リモート署名器公開鍵>]], } ``` -The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted and has the following structure: +`content`フィールドは以下のような構造を持つ[NIP-04](04.md)暗号化されたJSON-RPC風のメッセージである。 ```jsonc { - "id": , - "method": , - "params": [array_of_strings] + "id": <ランダム文字列>, + "method": <メソッド名>, + "params": [文字列の配列] } ``` -- `id` is a random string that is a request ID. This same ID will be sent back in the response payload. -- `method` is the name of the method/command (detailed below). -- `params` is a positional array of string parameters. +- `id`はリクエストIDであるランダムな文字列である。同じIDが応答ペイロードで返される。 +- `method`はメソッド/コマンドの名前である (詳細は下記参照)。 +- `params`はパラメータ文字列の位置配列である。 -### Methods/Commands +### メソッド/コマンド Each of the following are methods that the _client_ sends to the _remote-signer_. +以下はそれぞれ、 _クライアント_ が _リモート署名器_ に送信するメソッドである。 -| Command | Params | Result | +| コマンド | パラメータ | 結果 | | ------------------------ | ------------------------------------------------- | ---------------------------------------------------------------------- | -| `connect` | `[, , ]` | "ack" OR `` | -| `sign_event` | `[<{kind, content, tags, created_at}>]` | `json_stringified()` | +| `connect` | `[<リモート署名器公開鍵>, <オプションのシークレット>, <オプションの要求される権限>]` | "ack" または `<必須のシークレット値>` | +| `sign_event` | `[<{kind, content, tags, created_at}>]` | `json_stringified(<署名済イベント>)` | | `ping` | `[]` | "pong" | -| `get_relays` | `[]` | `json_stringified({: {read: , write: }})` | +| `get_relays` | `[]` | `json_stringified({<リレーURL>: {read: , write: }})` | | `get_public_key` | `[]` | `` | -| `nip04_encrypt` | `[, ]` | `` | -| `nip04_decrypt` | `[, ]` | `` | -| `nip44_encrypt` | `[<third_party_pubkey>, <plaintext_to_encrypt>]` | `<nip44_ciphertext>` | -| `nip44_decrypt` | `[<third_party_pubkey>, <nip44_ciphertext_to_decrypt>]` | `<plaintext>` | +| `nip04_encrypt` | `[<第三者の公開鍵>, <暗号化する平文>]` | `<nip04暗号文>` | +| `nip04_decrypt` | `[<第三者の公開鍵>, <復号するnip04暗号文>]` | `<平文>` | +| `nip44_encrypt` | `[<第三者の公開鍵>, <暗号化する平文>]` | `<nip44暗号文>` | +| `nip44_decrypt` | `[<第三者の公開鍵>, <複合するnip44暗号文>]` | `<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. Same permission format may be used for `perms` field of `metadata` in `nostrconnect://` string. +ユーザーの利便性のために、`connect`メソッドは`オプションの要求される権限`と一緒に提供されるかもしれない。権限はコンマで区切られた`メソッド[:パラメータ]のリストである。例えば、`nip04_encrypt,sign_event:4`は`nip04_encrypt`と`kind:4`の`sign_event`を呼び出す権限を意味する。`nostrconnect://`文字列内の`metadata`の`perms`フィールドにも同じ権限形式を利用できる。 -## Response Events `kind:24133` +## 応答イベント `kind:24133` ```json { "id": <id>, "kind": 24133, - "pubkey": <remote-signer-pubkey>, - "content": <nip04(<response>)>, - "tags": [["p", <client-pubkey>]], - "created_at": <unix timestamp in seconds> + "pubkey": <リモート署名器公開鍵> + "content": <nip04(<応答>)>, + "tags": [["p", <クライアント公開鍵>]], + "created_at": <秒単位のUNIXタイムスタンプ> } ``` The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted and has the following structure: +`content`フィールドは以下のような構造を持つ[NIP-04](04.md)暗号化されたJSON-RPC風のメッセージである。 ```json { - "id": <request_id>, - "result": <results_string>, - "error": <optional_error_string> + "id": <リクエストID>, + "result": <結果文字列>, + "error": <オプションのエラー文字列> } ``` -- `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`, _optionally_, it is an error in string form, if any. Its presence indicates an error with the request. +- `id`は応答するリクエストIDである。 +- `results`は呼び出し結果の文字列である。(文字列またはJSON文字列化オブジェクトのいずれかになる。) +- `error`、文字列形式のエラーである ( _オプション_ )。存在する場合、リクエストのエラーを示す。 -## Example flow for signing an event +## イベントに署名する際のフロー -- `remote-signer-pubkey` is `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52` -- `user-pubkey` is also `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52` -- `client-pubkey` is `eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86` +- `リモート署名器公開鍵` は `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52` +- `ユーザー公開鍵` は `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52` +- ` クライアント公開鍵` は `eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86` -### Signature request +### 署名リクエスト ```jsonc { "kind": 24133, "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86", "content": nip04({ - "id": <random_string>, - "method": "sign_event", + "id": <ランダム文字列>, + "method": "sign_evet", "params": [json_stringified(<{ content: "Hello, I'm signing remotely", kind: 1, @@ -150,56 +152,57 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted created_at: 1714078911 }>)] }), - "tags": [["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]], // p-tags the remote-signer-pubkey + "tags": [["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]], // リモート署名器の公開鍵にpタグを付ける。 } ``` -### Response event +### 応答イベント ```jsonc { "kind": 24133, "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52", "content": nip04({ - "id": <random_string>, - "result": json_stringified(<signed-event>) + "id": <ランダム文字列>, + "result": json_stringified(<署名済イベント>) }), - "tags": [["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]], // p-tags the client-pubkey + "tags": [["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]], // クライアント公開鍵にpタグを付ける } ``` -### Diagram +### 表 ![signing-example](https://i.nostr.build/P3gW.png) -## Auth Challenges +## 認証チャレンジ -An Auth Challenge is a response that a _remote-signer_ can send back when it needs the _user_ to authenticate via other means. The response `content` object will take the following form: +認証チャレンジは _ユーザー_ に他の手段による認証が必要な場合に _リモート署名器_ が送り返せる応答である。応答の`content`は次のようになる ```json { - "id": <request_id>, - "result": "auth_url", - "error": <URL_to_display_to_end_user> + "id": <リクエストID>, + "result": "認証URL", + "error": <エンドユーザーに表示するURL> } ``` -_client_ should display (in a popup or new tab) the URL from the `error` field and then subscribe/listen for another response from the _remote-signer_ (reusing the same request ID). This event will be sent once the user authenticates in the other window (or will never arrive if the user doesn't authenticate). +_クライアント_ はポップアップまたは新しいタブで`error`フィールドのURLを表示し、リモート署名器からの別の応答を購読/待機する必要がある。(同じリクエストIDを再利用する。) -### Example event signing request with auth challenge +### 認証チャレンジを含むイベント署名リクエストの例 ![signing-example-with-auth-challenge](https://i.nostr.build/W3aj.png) -## Appendix +## 補遺 -### Announcing _remote-signer_ metadata +### _リモート署名器_ メタデータのアナウンス _remote-signer_ MAY publish it's metadata by using [NIP-05](05.md) and [NIP-89](89.md). With NIP-05, a request to `<remote-signer>/.well-known/nostr.json?name=_` MAY return this: +_リモート署名器_ は[NIP-05](05.md)および[NIP-89](89.md)を使用してメタデータを公開してもいい (MAY)。NIP-05では、`<リモート署名器>/.well-known/nostr.json?name=_` へのリクエストは以下の応答を返す場合がある。 ```jsonc { "names":{ - "_": <remote-signer-app-pubkey>, + "_": <リモート署名器アプリ公開鍵>, }, "nip46": { "relays": ["wss://relay1","wss://relay2"...], @@ -209,9 +212,10 @@ _remote-signer_ MAY publish it's metadata by using [NIP-05](05.md) and [NIP-89]( ``` The `<remote-signer-app-pubkey>` MAY be used to verify the domain from _remote-signer_'s NIP-89 event (see below). `relays` SHOULD be used to construct a more precise `nostrconnect://` string for the specific `remote-signer`. `nostrconnect_url` template MAY be used to redirect users to _remote-signer_'s connection flow by replacing `<nostrconnect>` placeholder with an actual `nostrconnect://` string. +`<リモート署名器アプリ公開鍵`はリモート署名器のNIP-89イベントからドメインを検証するために使用できる (MAY) (下記参照)。`relays`は特定の`リモート署名器`に対するより正確な`nostrconnect://`文字列を構築するために使用されるべきだ (SHOULD)。`nostrconnect_url`テンプレートは<nostrconnect>プレースホルダーを実際の`nostrconnect://`文字列に置き換えることにより、ユーザーをリモート署名器の接続フローにリダイレクトするために使用できる (MAY)。 -### Remote signer discovery via NIP-89 +### NIP-89によるリモート署名器発見 -_remote-signer_ MAY publish a NIP-89 `kind: 31990` event with `k` tag of `24133`, which MAY also include one or more `relay` tags and MAY include `nostrconnect_url` tag. The semantics of `relay` and `nostrconnect_url` tags are the same as in the section above. +_リモート署名器_ は`24133`の`k`タグを持つNIP-89`kind: 31990`イベントを発行しても良く (MAY)、これには1つ以上の`relay`タグが含まれていても良く (MAY)、`nostrconnect_url`タグが含まれていても良い (MAY)。`relay`タグと`nostrconnect_url`の意味論は上の節と同じである。 -_client_ MAY improve UX by discovering _remote-signers_ using their `kind: 31990` events. _client_ MAY then pre-generate `nostrconnect://` strings for the _remote-signers_, and SHOULD in that case verify that `kind: 31990` event's author is mentioned in signer's `nostr.json?name=_` file as `<remote-signer-app-pubkey>`. +_クライアント_ はその`kind: 31990`イベントを用いて _リモート署名器_ を発見することでユーザー体験を改善しても良い (MAY)。 _クライアント_ はリモート署名器用に`nostrconnect_url://`文字列を事前に生成していても良く (MAY)、その場合は`kind: 31990`イベントの作成者が署名者の`nostr.json?name=_`ファイルに`<リモート署名者アプリ公開鍵>`として記載されていることを検証する必要がある (SHOULD)。 From e50613b51154a6e62e49a89651ae0f66568eb149 Mon Sep 17 00:00:00 2001 From: s3-odara <haruta@s3-odara.net> Date: Fri, 29 Nov 2024 23:28:03 +0900 Subject: [PATCH 4/9] =?UTF-8?q?NIP-46:=20=5F=E3=81=AE=E4=B8=A1=E5=81=B4?= =?UTF-8?q?=E3=81=AB=E5=8D=8A=E8=A7=92=E3=82=B9=E3=83=9A=E3=83=BC=E3=82=B9?= =?UTF-8?q?=E3=82=92=E6=8C=BF=E5=85=A5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 46.md | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/46.md b/46.md index 33b60bef..f2c9a51c 100644 --- a/46.md +++ b/46.md @@ -17,21 +17,21 @@ Nostr Remote Signing ## 用語 - **ユーザー**: Nostrを使用しようとしている人。 -- **クライント**: _ユーザー_が見たりボタンをクリックしたりするユーザー向けアプリケーション。 -- **リモート署名器**: _クライアント_からのリクエストに応答するデーモンまたはサーバー。 -- **クライアント鍵ペア/公開鍵**: _client_によって生成された鍵。コンテンツを暗号化し、_リモート署名器_と通信するために使用される。 -- **リモート署名器鍵ペア/公開鍵**: _リモート署名器_がコンテンツを暗号化し、_クライアント_と通信するために使用される鍵。この鍵ペアは_ユーザー鍵ペア/公開鍵_と同じであっても良い (MAY) が、必ずしもそうである必要はない。 -- **ユーザー鍵ペア/公開鍵**: _ユーザー_を表す実際の鍵。(例えば、`sign_event`リクエストに応じてイベントへ署名するために使用される。) 通常、_リモート署名器_がこれらの鍵を管理する。 +- **クライント**: _ユーザー_ が見たりボタンをクリックしたりするユーザー向けアプリケーション。 +- **リモート署名器**: _クライアント_ からのリクエストに応答するデーモンまたはサーバー。 +- **クライアント鍵ペア/公開鍵**: _クライアント_ によって生成された鍵。コンテンツを暗号化し、_リモート署名器_と通信するために使用される。 +- **リモート署名器鍵ペア/公開鍵**: _リモート署名器_ がコンテンツを暗号化し、 _クライアント_ と通信するために使用される鍵。この鍵ペアは_ユーザー鍵ペア/公開鍵_と同じであっても良い (MAY) が、必ずしもそうである必要はない。 +- **ユーザー鍵ペア/公開鍵**: _ユーザー_を表す実際の鍵。(例えば、`sign_event`リクエストに応じてイベントへ署名するために使用される。) 通常、 _リモート署名器_ がこれらの鍵を管理する。 このNIPで指定されたすべての公開鍵は16進数形式である。 ## 概説 1. _クライアント_が`クライアント鍵ペア`を生成する。この鍵ペアは主に使い捨てであるため_ユーザー_に伝える必要はない。クライアントはそれをローカルに保存することを選択できるが、ログアウト時に削除するべきである。 -2. 接続が確立され、 (下記参照) _リモート署名器_は`クライアント公開鍵`を得て、_クライアント_は`リモート署名器公開鍵`を得る。 -3. _クライアント_は`クライアント鍵ペア`を使用して`リモート署名器公開鍵`へ`p`タグを付け、暗号化して_リモート署名器_にリクエストを送信する。 -4. _リモート署名器_は`クライアント公開鍵`へ`p`タグを付け、暗号化して _クライアント_ に応答する。 -5. _クライアント_は`ユーザー公開鍵`を得るために`get_public_key`をリクエストする。 +2. 接続が確立され、 (下記参照) _リモート署名器_ は`クライアント公開鍵`を得て、 _クライアント_ は`リモート署名器公開鍵`を得る。 +3. _クライアント_ は`クライアント鍵ペア`を使用して`リモート署名器公開鍵`へ`p`タグを付け、暗号化して _リモート署名器_ にリクエストを送信する。 +4. _リモート署名器_ は`クライアント公開鍵`へ`p`タグを付け、暗号化して _クライアント_ に応答する。 +5. _クライアント_ は`ユーザー公開鍵`を得るために`get_public_key`をリクエストする。 ## 接続の開始 @@ -39,22 +39,22 @@ Nostr Remote Signing ### リモート署名器によって直接接続が開始される場合 -_リモート署名器_は、接続トークンを以下の形式で提供する: +_リモート署名器_ は、接続トークンを以下の形式で提供する: ``` bunker://<リモート署名器公開鍵>?relay=<wss://接続するリレー>&relay=<wss://接続する別のリレー>&secret=<オプションのシークレット> ``` -このトークンはユーザーによって_クライアント_に渡され、クライアントは指定されたリレーを介してリモート署名器に`connect`リクエストを送る。オプションのシークレットは、正常な1回の接続確立にのみ使用でき、_リモート署名者_は古いシークレットを用いて新たに接続を確立しようとする試みを無視するべきだ (SHOULD)。 +このトークンはユーザーによって _クライアント_ に渡され、クライアントは指定されたリレーを介してリモート署名器に`connect`リクエストを送る。オプションのシークレットは、正常な1回の接続確立にのみ使用でき、 _リモート署名者_ は古いシークレットを用いて新たに接続を確立しようとする試みを無視するべきだ (SHOULD)。 ### クライアントによって直接接続が開始される場合 -_クライアント_は次のような接続トークンを提供する: +_クライアント_ は次のような接続トークンを提供する: ``` nostrconnect://<クライアント公開鍵>?relay=<wss://接続するリレー>&metadata=<json metadata: {"name":"...", "url": "...", "description": "...", "perms": "..."}>&secret=<必須のシークレット> ``` -このトークンはユーザーによって_リモート署名器_に渡され、リモート署名器は指定されたリレーを介して`クライアント公開鍵`に`connect`*応答*イベントを送る。クライアントは接続応答の作成者から`リモート署名器公開鍵`を探す。接続相手のなりすましを防ぐために`シークレット`値を指定する必要があり (MUST) _クライアント_は`connect`応答によって得られた`シークレット`を検証する必要がある (MUST)。 +このトークンはユーザーによって _リモート署名器_ に渡され、リモート署名器は指定されたリレーを介して`クライアント公開鍵`に`connect`*応答*イベントを送る。クライアントは接続応答の作成者から`リモート署名器公開鍵`を探す。接続相手のなりすましを防ぐために`シークレット`値を指定する必要があり (MUST) _クライアント_ は`connect`応答によって得られた`シークレット`を検証する必要がある (MUST)。 ## リクエストイベント `kind: 24133` @@ -83,7 +83,6 @@ nostrconnect://<クライアント公開鍵>?relay=<wss://接続するリレー> ### メソッド/コマンド -Each of the following are methods that the _client_ sends to the _remote-signer_. 以下はそれぞれ、 _クライアント_ が _リモート署名器_ に送信するメソッドである。 | コマンド | パラメータ | 結果 | From 8f2f6e16e44f861939c682d0e6ceca7ee2f469e6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B0=8F=E5=8E=9F=E6=99=B4=E5=A4=AA?= <haruta@s3-odara.net> Date: Fri, 29 Nov 2024 14:51:02 +0000 Subject: [PATCH 5/9] lint --- 46.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/46.md b/46.md index f2c9a51c..df0699ac 100644 --- a/46.md +++ b/46.md @@ -176,7 +176,7 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted ## 認証チャレンジ -認証チャレンジは _ユーザー_ に他の手段による認証が必要な場合に _リモート署名器_ が送り返せる応答である。応答の`content`は次のようになる +認証チャレンジは _ユーザー_ に他の手段による認証が必要な場合に _リモート署名器_ が送り返せる応答である。応答の`content`は以下のようになる。 ```json { @@ -211,7 +211,7 @@ _リモート署名器_ は[NIP-05](05.md)および[NIP-89](89.md)を使用し ``` The `<remote-signer-app-pubkey>` MAY be used to verify the domain from _remote-signer_'s NIP-89 event (see below). `relays` SHOULD be used to construct a more precise `nostrconnect://` string for the specific `remote-signer`. `nostrconnect_url` template MAY be used to redirect users to _remote-signer_'s connection flow by replacing `<nostrconnect>` placeholder with an actual `nostrconnect://` string. -`<リモート署名器アプリ公開鍵`はリモート署名器のNIP-89イベントからドメインを検証するために使用できる (MAY) (下記参照)。`relays`は特定の`リモート署名器`に対するより正確な`nostrconnect://`文字列を構築するために使用されるべきだ (SHOULD)。`nostrconnect_url`テンプレートは<nostrconnect>プレースホルダーを実際の`nostrconnect://`文字列に置き換えることにより、ユーザーをリモート署名器の接続フローにリダイレクトするために使用できる (MAY)。 +`<リモート署名器アプリ公開鍵`はリモート署名器のNIP-89イベントからドメインを検証するために使用できる (MAY) (下記参照)。`relays`は特定の`リモート署名器`のためのより正確な`nostrconnect://`文字列を構築するために使用されるべきだ (SHOULD)。`nostrconnect_url`テンプレートは<nostrconnect>プレースホルダーを実際の`nostrconnect://`文字列に置き換えることにより、ユーザーをリモート署名器の接続フローにリダイレクトするために使用できる (MAY)。 ### NIP-89によるリモート署名器発見 From 61a3dd3a2a64d9face37ae3467de0b5ed9178bc9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B0=8F=E5=8E=9F=E6=99=B4=E5=A4=AA?= <haruta@s3-odara.net> Date: Fri, 29 Nov 2024 14:53:28 +0000 Subject: [PATCH 6/9] lint --- 46.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/46.md b/46.md index df0699ac..21e20c5e 100644 --- a/46.md +++ b/46.md @@ -211,7 +211,7 @@ _リモート署名器_ は[NIP-05](05.md)および[NIP-89](89.md)を使用し ``` The `<remote-signer-app-pubkey>` MAY be used to verify the domain from _remote-signer_'s NIP-89 event (see below). `relays` SHOULD be used to construct a more precise `nostrconnect://` string for the specific `remote-signer`. `nostrconnect_url` template MAY be used to redirect users to _remote-signer_'s connection flow by replacing `<nostrconnect>` placeholder with an actual `nostrconnect://` string. -`<リモート署名器アプリ公開鍵`はリモート署名器のNIP-89イベントからドメインを検証するために使用できる (MAY) (下記参照)。`relays`は特定の`リモート署名器`のためのより正確な`nostrconnect://`文字列を構築するために使用されるべきだ (SHOULD)。`nostrconnect_url`テンプレートは<nostrconnect>プレースホルダーを実際の`nostrconnect://`文字列に置き換えることにより、ユーザーをリモート署名器の接続フローにリダイレクトするために使用できる (MAY)。 +`<リモート署名器アプリ公開鍵`はリモート署名器のNIP-89イベントからドメインを検証するために使用できる (MAY) (下記参照)。`relays`は特定の`リモート署名器`のためのより正確な`nostrconnect://`文字列を構築するために使用されるべきだ (SHOULD)。`nostrconnect_url`テンプレートは<nostrconnect>プレースホルダーを実際の`nostrconnect://`文字列へ置き換えることにより、ユーザーをリモート署名器の接続フローへリダイレクトするために使用できる (MAY)。 ### NIP-89によるリモート署名器発見 From 91d35a37eeb24753525c6589d9d8691564afd572 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B0=8F=E5=8E=9F=E6=99=B4=E5=A4=AA?= <haruta@s3-odara.net> Date: Fri, 29 Nov 2024 14:59:41 +0000 Subject: [PATCH 7/9] =?UTF-8?q?=E5=8D=8A=E8=A7=92=E3=82=B9=E3=83=9A?= =?UTF-8?q?=E3=83=BC=E3=82=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 46.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/46.md b/46.md index 21e20c5e..1fc06dd1 100644 --- a/46.md +++ b/46.md @@ -21,13 +21,13 @@ Nostr Remote Signing - **リモート署名器**: _クライアント_ からのリクエストに応答するデーモンまたはサーバー。 - **クライアント鍵ペア/公開鍵**: _クライアント_ によって生成された鍵。コンテンツを暗号化し、_リモート署名器_と通信するために使用される。 - **リモート署名器鍵ペア/公開鍵**: _リモート署名器_ がコンテンツを暗号化し、 _クライアント_ と通信するために使用される鍵。この鍵ペアは_ユーザー鍵ペア/公開鍵_と同じであっても良い (MAY) が、必ずしもそうである必要はない。 -- **ユーザー鍵ペア/公開鍵**: _ユーザー_を表す実際の鍵。(例えば、`sign_event`リクエストに応じてイベントへ署名するために使用される。) 通常、 _リモート署名器_ がこれらの鍵を管理する。 +- **ユーザー鍵ペア/公開鍵**: _ユーザー_ を表す実際の鍵。(例えば、`sign_event`リクエストに応じてイベントへ署名するために使用される。) 通常、 _リモート署名器_ がこれらの鍵を管理する。 このNIPで指定されたすべての公開鍵は16進数形式である。 ## 概説 -1. _クライアント_が`クライアント鍵ペア`を生成する。この鍵ペアは主に使い捨てであるため_ユーザー_に伝える必要はない。クライアントはそれをローカルに保存することを選択できるが、ログアウト時に削除するべきである。 +1. _クライアント_ が`クライアント鍵ペア`を生成する。この鍵ペアは主に使い捨てであるため _ユーザー_ に伝える必要はない。クライアントはそれをローカルに保存することを選択できるが、ログアウト時に削除するべきである。 2. 接続が確立され、 (下記参照) _リモート署名器_ は`クライアント公開鍵`を得て、 _クライアント_ は`リモート署名器公開鍵`を得る。 3. _クライアント_ は`クライアント鍵ペア`を使用して`リモート署名器公開鍵`へ`p`タグを付け、暗号化して _リモート署名器_ にリクエストを送信する。 4. _リモート署名器_ は`クライアント公開鍵`へ`p`タグを付け、暗号化して _クライアント_ に応答する。 From 168318e3d3830b8d1307b7b2d21b544aa4204894 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B0=8F=E5=8E=9F=E6=99=B4=E5=A4=AA?= <haruta@s3-odara.net> Date: Sun, 8 Dec 2024 19:22:26 +0000 Subject: [PATCH 8/9] Apply suggestions from code review Co-authored-by: Akiomi KAMAKURA <akiomik@gmail.com> --- 46.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/46.md b/46.md index f3927b1f..2de07856 100644 --- a/46.md +++ b/46.md @@ -19,7 +19,7 @@ Nostr Remote Signing - **ユーザー**: Nostrを使用しようとしている人。 - **クライント**: _ユーザー_ が見たりボタンをクリックしたりするユーザー向けアプリケーション。 - **リモート署名器**: _クライアント_ からのリクエストに応答するデーモンまたはサーバー。 -- **クライアント鍵ペア/公開鍵**: _クライアント_ によって生成された鍵。コンテンツを暗号化し、_リモート署名器_と通信するために使用される。 +- **クライアント鍵ペア/公開鍵**: _クライアント_ によって生成された鍵。コンテンツを暗号化し、_リモート署名器_　と通信するために使用される。 - **リモート署名器鍵ペア/公開鍵**: _リモート署名器_ がコンテンツを暗号化し、 _クライアント_ と通信するために使用される鍵。この鍵ペアは_ユーザー鍵ペア/公開鍵_と同じであっても良い (MAY) が、必ずしもそうである必要はない。 - **ユーザー鍵ペア/公開鍵**: _ユーザー_ を表す実際の鍵。(例えば、`sign_event`リクエストに応じてイベントへ署名するために使用される。) 通常、 _リモート署名器_ がこれらの鍵を管理する。 @@ -109,7 +109,7 @@ nostrconnect://83f3b2ae6aa368e8275397b9c26cf550101d63ebaab900d19dd4a4429f5ad8f5? ### 要求される権限 -ユーザーの利便性のために、`connect`メソッドは`オプションの要求される権限`と一緒に提供されるかもしれない。権限はコンマで区切られた`メソッド[:パラメータ]のリストである。例えば、`nip04_encrypt,sign_event:4`は`nip04_encrypt`と`kind:4`の`sign_event`を呼び出す権限を意味する。`nostrconnect://`文字列内の`metadata`の`perms`フィールドにも同じ権限形式を利用できる。 +ユーザーの利便性のために、`connect`メソッドは`オプションの要求される権限`と一緒に提供されるかもしれない。権限はコンマで区切られた`メソッド[:パラメータ]`のリストである。例えば、`nip04_encrypt,sign_event:4`は`nip04_encrypt`と`kind:4`の`sign_event`を呼び出す権限を意味する。`nostrconnect://`文字列内の`metadata`の`perms`フィールドにも同じ権限形式を利用できる。 ## 応答イベント `kind:24133` From 6147632b41d6fc2111a47db70b59994119c790f7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B0=8F=E5=8E=9F=E6=99=B4=E5=A4=AA?= <haruta@s3-odara.net> Date: Sun, 8 Dec 2024 19:26:00 +0000 Subject: [PATCH 9/9] remove original sentence --- 30.md | 1 - 1 file changed, 1 deletion(-) diff --git a/30.md b/30.md index 87fdcba4..b3df041e 100644 --- a/30.md +++ b/30.md @@ -57,7 +57,6 @@ kind 1のイベントにおいては、`content`フィールドにカスタム ### Kind 7 イベント -In kind 7 events, the `content` should be emojified. kind 7のイベントにおいては、`content`フィールドにカスタム絵文字を使用してよく、クライアントはこれを「絵文字化」するべきである。 ```json