Merge pull request #2 from s3-odara/main

nip-26の翻訳

26.md

@@ -1,18 +1,18 @@
 NIP-26
 =======
 
-Delegated Event Signing
+イベント署名の委任
 -----
 
 `draft` `optional` `author:markharding` `author:minds`
 
-This NIP defines how events can be delegated so that they can be signed by other keypairs.
+このNIPは他の鍵ペアを使ってイベントを署名するための委任の方法を定義します。
 
-Another application of this proposal is to abstract away the use of the 'root' keypairs when interacting with clients. For example, a user could generate new keypairs for each client they wish to use and authorize those keypairs to generate events on behalf of their root pubkey, where the root keypair is stored in cold storage. 
+この提案の活用法として、クライアントと対話するときにルート鍵ペアの使用を回避できることが挙げられます。例えば、ユーザーは使用したいクライアント毎に新しい鍵ペアを作成し、コールドストレージに保存するルート鍵ペアに代えて新しい鍵ペアを使ってイベントに署名させることができます。
 
-#### Introducing the 'delegation' tag
+#### 'delegation'タグの紹介
 
-This NIP introduces a new tag: `delegation` which is formatted as follows:
+このNIPで導入される`delegation`タグは次のような書式で示されます。
 
 ```json
 [
@@ -23,62 +23,62 @@ This NIP introduces a new tag: `delegation` which is formatted as follows:
 ]
 ```
 
-##### Delegation Token
+##### 委任トークン
 
-The **delegation token** should be a 64-byte Schnorr signature of the sha256 hash of the following string:
+**委任トークン**は次の文字列のsha256ハッシュへの64バイトのシュノア署名でなければなりません。 (訳注: 以下に示される文字列は委任トークン**ではありません**。委任文字列です。)
 
 ```
 nostr:delegation:<pubkey of publisher (delegatee)>:<conditions query string>
 ```
 
-##### Conditions Query String
+##### クエリ文字列の条件句
 
-The following fields and operators are supported in the above query string:
+上記のクエリ文字列には、以下のフィールドと演算子が対応しています。
 
-*Fields*:
+*フィールド*:
 1. `kind`
-   -  *Operators*:
-      -  `=${KIND_NUMBER}` - delegatee may only sign events of this kind
+   -  *演算子*:
+      -  `=${KIND_NUMBER}` - 委任された鍵は、指定されたイベントkindのみに署名できます。
 2. `created_at`
-   -  *Operators*:
-      -  `<${TIMESTAMP}` - delegatee may only sign events created ***before*** the specified timestamp
-      -  `>${TIMESTAMP}` - delegatee may only sign events created ***after*** the specified timestamp
+   -  *演算子*:
+      -  `<${TIMESTAMP}` - 委任された鍵は、指定されたタイムスタンプより***過去***に作成されたイベントにのみ署名できます。
+      -  `>${TIMESTAMP}` - 委任された鍵は、指定されたタイムスタンプより***未来***に作成されたイベントにのみ署名できます。
 
-In order to create a single condition, you must use a supported field and operator. Multiple conditions can be used in a single query string, including on the same field. Conditions must be combined with `&`.
+単一の条件を指定するには、対応しているフィールドと演算子を使用する必要が有ります。複数の条件を1つのクエリ文字列で指定する場合、条件句は`&`で組み合わされる必要が有ります。
 
-For example, the following condition strings are valid:
+例えば、次に示される条件句の文字列は有効です。
 
 - `kind=1&created_at<1675721813`
 - `kind=0&kind=1&created_at>1675721813`
 - `kind=1&created_at>1674777689&created_at<1675721813`
 
-For the vast majority of use-cases, it is advisable that:
-1. Query strings should include a `created_at` ***after*** condition reflecting the current time, to prevent the delegatee from publishing historic notes on the delegator's behalf.
-2. Query strings should include a `created_at` ***before*** condition that is not empty and is not some extremely distant time in the future. If delegations are not limited in time scope, they expose similar security risks to simply using the root key for authentication.
+大半のユースケースでは、以下の事が推奨されます。
+1. クエリ文字列には、現在の時刻を反映した`created_at`より***未来***のみの条件を含めるべきです。
+2. クエリ文字列には、空でなく、極端に遠い未来の時刻でない`created_at`より***過去***のみの条件を含めるべきです。もし、委任が時間的範囲に拘束されない場合、ルート鍵ペアを認証に利用するのと同様のセキュリティリスクが発生します。
 
-#### Example
+#### 例
 
 ```
-# Delegator:
+# 委任する鍵:
 privkey: ee35e8bb71131c02c1d7e73231daa48e9953d329a4b701f7133c8f46dd21139c
 pubkey:  8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd
 
-# Delegatee:
+# 委任される鍵:
 privkey: 777e4f60b4aa87937e13acc84f7abcc3c93cc035cb4c1e9f7a9086dd78fffce1
 pubkey:  477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396
 ```
 
-Delegation string to grant note publishing authorization to the delegatee (477318cf) from now, for the next 30 days, given the current timestamp is `1674834236`.
+次に示す委任文字列は、現在のタイムスタンプが`1674834236`であるとき今から30日間、委任される鍵 (477318cf...) へノートの署名権限を付与するものです。
 ```json
 nostr:delegation:477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396:kind=1&created_at>1674834236&created_at<1677426236
 ```
 
-The delegator (8e0d3d3e) then signs a SHA256 hash of the above delegation string, the result of which is the delegation token:
+次に示す委任トークンは、上記の委任文字列のSHA256ハッシュへの委任する鍵 (8e0d3d3e...) による署名です。
 ```
 6f44d7fe4f1c09f3954640fb58bd12bae8bb8ff4120853c4693106c82e920e2b898f1f9ba9bd65449a987c39c0423426ab7b53910c0c6abfb41b30bc16e5f524
 ```
 
-The delegatee (477318cf) can now construct an event on behalf of the delegator (8e0d3d3e). The delegatee then signs the event with its own private key and publishes.
+委任された鍵 (477318cf...) は委任する鍵 (8e0d3d3e...) に代わってイベントを構築できます。委任された鍵は自身の秘密鍵でイベントに署名して公開します。
 ```json
 {
   "id": "e93c6095c3db1c31d15ac771f8fc5fb672f6e52cd25505099f62cd055523224f",
@@ -98,13 +98,13 @@ The delegatee (477318cf) can now construct an event on behalf of the delegator (
 }
 ```
 
-The event should be considered a valid delegation if the conditions are satisfied (`kind=1`, `created_at>1674834236` and `created_at<1677426236` in this example) and, upon validation of the delegation token, are found to be unchanged from the conditions in the original delegation string.
+委任トークンの署名検証の結果が有効で、条件を満たしている (この例では`kind=1`、`created_at>1674834236`、`created_at<1677426236`) 場合、委任は有効だと見做されます。
 
-Clients should display the delegated note as if it was published directly by the delegator (8e0d3d3e).
+クライアントは、委任されたノートをあたかも委任した鍵 (8e0d3d3e...) によって直接発行されたかのように表示する必要が有ります。
 
 
-#### Relay & Client Support
+#### リレーとクライアントの対応
 
-Relays should answer requests such as `["REQ", "", {"authors": ["A"]}]` by querying both the `pubkey` and delegation tags `[1]` value.
+リレーは`["REQ", "", {"authors": ["A"]}]`のようなリクエストには`pubkey`とdelegationタグ`[1]` の値の両方を問い合わせることで答えるべきです。
 
-Relays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf).
+リレーは、委任される鍵 (477318cf...) によって公開されたイベントを委任する鍵 (8e0d3d3e...) が削除することを許可する必要があります。 (SHOULD)