Merge branch 'main' into nip-58

03.md

@@ -1,12 +1,12 @@
 NIP-03
 ======
 
-OpenTimestamps Attestations for Events
+イベントに対するOpenTimestamps認証
 --------------------------------------
 
 `draft` `optional` `author:fiatjaf` `author:constant`
 
-This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](https://opentimestamps.org/) proof for any other event:
+このNIPは`kind:1040`のイベントを定義します。これは他のイベントに対する[OpenTimestamps](https://opentimestamps.org/)証明を含むことができます。
 
 ```json
 {
@@ -19,12 +19,12 @@ This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](
 }
 ```
 
-- The OpenTimestamps proof MUST prove the referenced `e` event id as its digest.
-- The `content` MUST be the full content of an `.ots` file containing at least one Bitcoin attestation. This file SHOULD contain a **single** Bitcoin attestation and no reference to "pending" attestations since they are useless in this context.
+- OpenTimestamps証明は、`e`タグで参照されているイベントを、そのIDをダイジェストとして証明しなければなりません(MUST)。
+- `content`は、少なくとも1つのビットコイン認証を含む`.ots`ファイルの全内容でなければなりません(MUST)。このファイルは**単一の**ビットコイン認証のみを含み、かつ「未解決」の認証に対する参照を持たないべきです(SHOULD)。なぜなら、それらはこの状況では役に立たないからです。
 
-### Example OpenTimestamps proof verification flow
+### OpenTimestamps証明の検証フローの例
 
-Using [`nak`](https://github.com/fiatjaf/nak), [`jq`](https://jqlang.github.io/jq/) and [`ots`](https://github.com/fiatjaf/ots):
+[`nak`](https://github.com/fiatjaf/nak)、[`jq`](https://jqlang.github.io/jq/)、そして[`ots`](https://github.com/fiatjaf/ots)コマンドを用います。
 
 ```bash
 ~> nak req -i e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323 wss://nostr-pub.wellorder.net | jq -r .content | ots verify

65.md

@@ -1,16 +1,16 @@
 NIP-65
 ======
 
-Relay List Metadata
+リレーリストメタデータ
 -------------------
 
 `draft` `optional` `author:mikedilger` `author:vitorpamplona`
 
-Defines a replaceable event using `kind:10002` to advertise preferred relays for discovering a user's content and receiving fresh content from others.
+あるユーザのコンテンツを発見したり他人からの最新のコンテンツを受け取ったりするための推奨リレーの広告を目的とする、`kind:10002`を用いる上書き可能イベントを定義します。
 
-The event MUST include a list of `r` tags with relay URIs and a `read` or `write` marker. Relays marked as `read` / `write` are called READ / WRITE relays, respectively. If the marker is omitted, the relay is used for both purposes.
+このイベントには、リレーURIと`read`または`write`マーカーを持つ`r`タグのリストを含めなければなりません(MUST)。`read`・`write` とマークされたリレーをそれぞれ読み出し(READ)・書き込み(WRITE)リレーと呼びます。マーカーが省略された場合、そのリレーは両方の目的で利用されます。
 
-The `.content` is not used.
+`.content`は使用しません。
 
 ```json
 {
@@ -22,43 +22,43 @@ The `.content` is not used.
     ["r", "wss://nostr-relay.example.com", "read"],
   ],
   "content": "",
-  ...other fields
+  ...その他のフィールド
 }
 ```
 
-This NIP doesn't fully replace relay lists that are designed to configure a client's usage of relays (such as `kind:3` style relay lists). Clients MAY use other relay lists in situations where a `kind:10002` relay list cannot be found.
+このNIPは、(`kind:3`スタイルのリレーリストのような)クライアントによるリレーの使われ方を設定する目的で設計されたリレーリストを完全に置き換えるものではありません。クライアントは`kind:10002`のリレーリストを発見できない状況において、他のリレーリストを使用してもかまいません(MAY)。
 
-## When to Use Read and Write Relays
+## 読み出し・書き込みリレーをいつ使用すべきか
 
-When seeking events **from** a user, Clients SHOULD use the WRITE relays of the user's `kind:10002`.
+あるユーザ**から**発せられたイベントを探す際は、クライアントはそのユーザの`kind:10002`に含まれる書き込み(WRITE)リレーを使用すべきです(SHOULD)。
 
-When seeking events **about** a user, where the user was tagged, Clients SHOULD use the READ relays of the user's `kind:10002`.
+あるユーザ**に関する**イベント、すなわちそのユーザがタグ付けされているイベントを探す際は、クライアントはそのユーザの`kind:10002`に含まれる読み出し(READ)リレーを使用すべきです(SHOULD)。
 
-When broadcasting an event, Clients SHOULD:
+イベントを送信する際は、クライアントは以下のようにすべきです(SHOULD)。
 
-- Broadcast the event to the WRITE relays of the author
-- Broadcast the event all READ relays of each tagged user
+- イベント発行者の書き込み(WRITE)リレーにイベントを送信する
+- イベントにタグ付けされた各ユーザの読み出し(READ)リレーにイベントを送信する
 
-## Motivation
+## 動機
 
-The old model of using a fixed relay list per user centralizes in large relay operators: 
+ユーザごとに固定のリレーリストを用いる従来のモデルでは、有力なリレー運用者に権力が集中します。
 
-  - Most users submit their posts to the same highly popular relays, aiming to achieve greater visibility among a broader audience
-  - Many users are pulling events from a large number of relays in order to get more data at the expense of duplication
-  - Events are being copied between relays, oftentimes to many different relays
+  - ほとんどのユーザは自分の投稿を同一の非常に人気なリレーに送信する。これは投稿をより幅広い読者に届けるのが目的である
+  - 多くのユーザは、より多くのデータを得るためにたくさんのリレーからイベントを取得しているが、これはデータの重複という代償を伴う
+  - イベントはリレー間でコピーされている。多くの場合、たくさんの別々のリレーにコピーされる
 
-This NIP allows Clients to connect directly with the most up-to-date relay set from each individual user, eliminating the need of broadcasting events to popular relays. 
+このNIPにより、クライアントが各ユーザ個人の最新のリレーセットに対して直接接続できるようになり、人気のリレーにイベントを送信する必要がなくなります。
 
-## Final Considerations
+## 総論
 
-1. Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays). 
+1. クライアントは、`kind:10002`のリストを小さく(リレー2〜4個)保つようユーザに案内すべきである(SHOULD)。
 
-2. Clients SHOULD spread an author's `kind:10002` events to as many relays as viable. 
+2. クライアントは、可能な限りたくさんのリレーに`kind:10002`のイベントを拡散すべきである(SHOULD)。
 
-3. `kind:10002` events should primarily be used to advertise the user's preferred relays to others. A user's own client may use other heuristics for selecting relays for fetching data.
+3. `kind:10002`のイベントは、そのユーザが推奨するリレーを他人に広告することを主な目的として使用すべきである。そのユーザ自身のクライアントは、データの取得に用いるリレーを選択する際に他のヒューリスティクスを用いてもよい。
 
-4. DMs SHOULD only be broadcasted to the author's WRITE relays and to the receiver's READ relays to keep maximum privacy. 
+4. 最大限のプライバシーを保つために、ダイレクトメッセージは送信者の書き込み(WRITE)リレーと受信者の読み出し(READ)リレーのみに送信すべきである(SHOULD)。
 
-5. If a relay signals support for this NIP in their [NIP-11](11.md) document that means they're willing to accept kind 10002 events from a broad range of users, not only their paying customers or whitelisted group.
+5. リレーが[NIP-11](11.md)ドキュメントでこのNIPのサポートを告知しているならば、それはそのリレーが、料金を支払っている顧客やホワイトリストで許可されたグループに限らず、幅広いユーザからの`kind:10002`のイベントを受け入れる意思があることを意味する。
 
-6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
+6. クライアントは、[RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6)に従ったリレーURIの正規化によって、接続の重複を排除すべきである(SHOULD)。