Merge branch 'main' into nip-18

.textlintrc.json

@@ -5,7 +5,19 @@
     "textlint-rule-preset-ja-technical-writing": {
       "max-comma": false,
       "no-exclamation-question-mark": false,
-      "sentence-length": false
+      "sentence-length": false,
+      "ja-no-mixed-period": {
+        "allowPeriodMarks": [":"]
+      },
+      "no-mix-dearu-desumasu": {
+        "preferInHeader": "",
+        "preferInBody": "ですます",
+        "preferInList": "ですます",
+        "strict": true
+      }
+    },
+    "preset-ja-spacing": {
+      "ja-no-space-around-parentheses": false
     }
   }
 }

01.md

@@ -44,7 +44,7 @@ NIP-01
 
 ### タグ
 
-タグはそれぞれ任意長の文字列の配列であり、関連していくつかの慣例があります。以下の例を見てください。
+タグはそれぞれ任意長の文字列の配列で、関連していくつかの慣例があります。以下の例を見てください。
 
 ```json
 {
@@ -74,7 +74,7 @@ NIP-01
 
 ### Kinds
 
-Kindはクライアントがイベントやイベントのフィールドをどう解釈すべきかを決めます（たとえば、`"r"`タグの kind 1 における意味は、kind 10002 のイベントにおける意味と全く異なる可能性があります）。それぞれのNIPにおいて、他の場所で定義されていないkindの意味を定義する可能性があります。このNIPでは、以下のように2つの基本的なkindを定義します。
+Kindはクライアントがイベントやイベントのフィールドをどう解釈すべきかを決めます（たとえば、`"r"`タグのkind 1における意味は、kind 10002のイベントにおける意味と全く異なる可能性があります）。それぞれのNIPにおいて、他の場所で定義されていないkindの意味を定義する可能性があります。このNIPでは、以下のように2つの基本的なkindを定義します。
 
 - `0`: **メタデータ**: `content`は文字列化されたJSONオブジェクト`{name: <ユーザ名>, about: <文字列>, picture: <URL、文字列>}`で、イベントを作成したユーザのことを記述します。リレーは、同一のpubkeyから新しいイベントを受信した際、過去のイベントを削除できます。
 - `1`: **テキスト投稿**: `content`はノート（ユーザが発言したいこと）を**プレーンテキスト**で指定します。パースが必要なコンテンツ（マークダウンやHTMLなど）を使用すべきではありません。クライアントもコンテンツをそのようにパースをしてはいけません。
@@ -108,7 +108,7 @@ Kindはクライアントがイベントやイベントのフィールドをど
   * `["REQ", <購読ID>, <フィルタJSON>...]` イベントを要求し、更新を購読するために使います。
   * `["CLOSE", <購読ID>]` 既存の購読を中止するために使います。
 
-`<購読ID>` は任意の、空でない最大64文字の文字列で、購読を区別するために用います。リレーはWebSocket接続ごとに独立して`<購読ID>`を管理しなければなりません。同一文字列の`<購読ID>`であっても、コネクションごとに異なる購読として扱うべきです。
+`<購読ID>` は任意の、空でない最大64文字の文字列で、購読を区別するために用います。リレーはWebSocket接続ごとに独立して`<購読ID>`を管理しなければなりません。同一文字列の`<購読ID>`でも、コネクションごとに異なる購読として扱うべきです。
 
 `<フィルタ>` はJSONオブジェクトで、どんなイベントがその購読で転送されるかを決めます。以下の属性をもつ可能性があります。
 
@@ -150,7 +150,7 @@ Kindはクライアントがイベントやイベントのフィールドをど
 このNIPでは`NOTICE`メッセージをどのように送信し、またどのように扱うべきかについてのルールは定義しません。
 
 - `EVENT`メッセージは、クライアントが（前述の`REQ`メッセージを用いて）以前に開始した購読IDと紐付けられたものだけが送信されなければなりません（MUST）。
-- `OK`メッセージは、クライアントから受信した`EVENT`メッセージに対する返信として送信されなければなりません（MUST）。3番目のパラメータは、リレーがメッセージを受理する場合は`ture`を、そうでなければ`false`を指定しなければなりません。4番目のパラメータも必須で（MUST）、3番目が`true`である場合は空文字列でもかまいません（MAY）が、そうでなければ、機械可読な一語のプレフィクスに続けて`:`と人間可読なメッセージを含まなければなりません（MUST）。標準化されている機械可読なプレフィクスは、`duplicate`、`pow`、`blocked`、`rate-limited`、`invalid`と`error`（他のどれにも当てはまらない場合）です。例は以下の通りです。
+- `OK`メッセージは、クライアントから受信した`EVENT`メッセージに対する返信として送信されなければなりません（MUST）。3番目のパラメータは、リレーがメッセージを受理する場合は`ture`を、そうでなければ`false`を指定しなければなりません。4番目のパラメータも必須で（MUST）、3番目が`true`の場合は空文字列でもかまいません（MAY）が、そうでなければ、機械可読な一語のプレフィクスに続けて`:`と人間可読なメッセージを含まなければなりません（MUST）。標準化されている機械可読なプレフィクスは、`duplicate`、`pow`、`blocked`、`rate-limited`、`invalid`と`error`（他のどれにも当てはまらない場合）です。例は以下の通りです。
 
   * `["OK", "b1a649ebe8...", true, ""]`
   * `["OK", "b1a649ebe8...", true, "pow: difficulty 25>=24"]` pow: 難易度25は24以上

02.md

@@ -1,16 +1,16 @@
 NIP-02
 ======
 
-Contact List and Petnames
+連絡先リストと愛称
 -------------------------
 
 `final` `optional` `author:fiatjaf` `author:arcbtc`
 
-A special event with kind `3`, meaning "contact list" is defined as having a list of `p` tags, one for each of the followed/known profiles one is following.
+「連絡先リスト」を意味するkind `3`の特別なイベントは、フォローしている/既知のプロフィールごとの`p`タグのリストを持つものとして定義されます。
 
-Each tag entry should contain the key for the profile, a relay URL where events from that key can be found (can be set to an empty string if not needed), and a local name (or "petname") for that profile (can also be set to an empty string or not provided), i.e., `["p", <32-bytes hex key>, <main relay URL>, <petname>]`. The `content` can be anything and should be ignored.
+タグの個々の要素は、プロフィールの鍵・その鍵からのイベントを発見できるリレーのURL (必要なければ空文字列で設定可能です) ・そのプロフィールのローカル名 (あるいは「愛称」) (空文字列が設定されるか、提供されないようできます) を含むべきで、つまり`["p", <32-bytes hex key>, <main relay URL>, <petname>]`です。`content`は何でもかまいませんが、無視されるべきです。
 
-For example:
+例:
 
 ```json
 {
@@ -25,50 +25,50 @@ For example:
 }
 ```
 
-Every new contact list that gets published overwrites the past ones, so it should contain all entries. Relays and clients SHOULD delete past contact lists as soon as they receive a new one.
+新しい子連絡先リストが公開されるたびに過去のものは上書きされるので、すべての要素を含むべきです。リレーとクライアントは新しいものを受け取ったら速やかに過去の連絡先リストを削除すべきです (SHOULD) 。
 
-## Uses
+## 用途
 
-### Contact list backup
+### 連絡先リストのバックアップ
 
-If one believes a relay will store their events for sufficient time, they can use this kind-3 event to backup their following list and recover on a different device.
+リレーがイベントを十分な期間保存すると信じているなら、このkind 3イベントを使ってフォローリストをバックアップし、別のデバイスで復元できます。
 
-### Profile discovery and context augmentation
+### プロフィールの発見とコンテキストの拡張
 
-A client may rely on the kind-3 event to display a list of followed people by profiles one is browsing; make lists of suggestions on who to follow based on the contact lists of other people one might be following or browsing; or show the data in other contexts.
+クライアントは、ブラウジングしているプロフィールがフォローしている人のリストを表示したり、フォローまたはブラウジングしている人の連絡先リストに基づいて誰をフォローするかの提案リストを作成したり、他のコンテキストでデータを表示したりするためにkind 3イベントを頼りにしてもかまいません。
 
-### Relay sharing
+### リレーの共有
 
-A client may publish a full list of contacts with good relays for each of their contacts so other clients may use these to update their internal relay lists if needed, increasing censorship-resistance.
+クライアントは連絡先の完全なリストともにそれぞれの連絡先のために適したリレーを公開してもよく、これによりほかのクライアントは必要に応じてこれを内部のリレーリストの更新に使うことができ、検閲耐性が高まります。
 
-### Petname scheme
+### 愛称スキーム
 
-The data from these contact lists can be used by clients to construct local ["petname"](http://www.skyhunter.com/marcs/petnames/IntroPetNames.html) tables derived from other people's contact lists. This alleviates the need for global human-readable names. For example:
+連絡先リストからのデータは、クライアントによってほかの人々の連絡先リストから派生したローカルの["petname"](http://www.skyhunter.com/marcs/petnames/IntroPetNames.html)テーブルを構築するために用いることができます。これにより、グローバルな人間が読める名前の必要性が軽減されます。例えば:
 
-A user has an internal contact list that says
+ユーザーは次のような内部の連絡先リストを持っています。
 
 ```json
 [
   ["p", "21df6d143fb96c2ec9d63726bf9edc71", "", "erin"]
 ]
 ```
 
-And receives two contact lists, one from `21df6d143fb96c2ec9d63726bf9edc71` that says
+そして、次のように2つの連絡先リストを受け取り、1つは`21df6d143fb96c2ec9d63726bf9edc71`からです。
 
 ```json
 [
   ["p", "a8bb3d884d5d90b413d9891fe4c4e46d", "", "david"]
 ]
 ```
 
-and another from `a8bb3d884d5d90b413d9891fe4c4e46d` that says
+もう1つは`a8bb3d884d5d90b413d9891fe4c4e46d`からです。
 
 ```json
 [
   ["p", "f57f54057d2a7af0efecc8b0b66f5708", "", "frank"]
 ]
 ```
 
-When the user sees `21df6d143fb96c2ec9d63726bf9edc71` the client can show _erin_ instead;
-When the user sees `a8bb3d884d5d90b413d9891fe4c4e46d` the client can show _david.erin_ instead;
-When the user sees `f57f54057d2a7af0efecc8b0b66f5708` the client can show _frank.david.erin_ instead.
+ユーザーが`21df6d143fb96c2ec9d63726bf9edc71`を見るとき、クライアントは代わりに _erin_ を表示できます。
+ユーザーが`a8bb3d884d5d90b413d9891fe4c4e46d`を見るとき、クライアントは代わりに _david.erin_ を表示できます。
+ユーザーが`f57f54057d2a7af0efecc8b0b66f5708`を見るとき、クライアントは代わりに _frank.david.erin_ を表示できます。

26.md

@@ -68,7 +68,7 @@ privkey: 777e4f60b4aa87937e13acc84f7abcc3c93cc035cb4c1e9f7a9086dd78fffce1
 pubkey:  477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396
 ```
 
-次に示す委任文字列は、現在のタイムスタンプが`1674834236`であるとき今から30日間、委任される鍵 (477318cf...) へノートの署名権限を付与するものです。
+次に示す委任文字列は、現在のタイムスタンプが`1674834236`のとき今から30日間、委任される鍵 (477318cf...) へノートの署名権限を付与するものです。
 ```json
 nostr:delegation:477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396:kind=1&created_at>1674834236&created_at<1677426236
 ```

58.md

@@ -66,7 +66,7 @@ NIP-58
 
 クライアントはユーザーに対する価値/特別性を保っていることを保証する目的でバッジ発行者 (公開鍵) をホワイトリストに登録してもかまいません (MAY) 。
 
-バッジ画像のアスペクト比は1:1で、1024x1024の高解像度画像であることが推奨されます。
+バッジ画像のアスペクト比は1:1で、1024x1024の高解像度画像が推奨されます。
 
 バッジのサムネイル画像の推奨寸法は512x512 (xl) ・256x256 (l) ・64x64 (m) ・32x32 (s) ・16x16 (xs)です。