Merge branch 'main' into auto-sync

58.md

@@ -1,80 +1,80 @@
 NIP-58
 ======
 
-Badges
+バッジ
 ------
 
 `draft` `optional` `author:cameri`
 
-Three special events are used to define, award and display badges in
-user profiles:
+3つの特別なイベントがユーザープロフィール上のバッジを定義、授与、陳列するために
+用いられます。
 
-1. A "Badge Definition" event is defined as a parameterized replaceable event with kind `30009` having a `d` tag with a value that uniquely identifies the badge (e.g. `bravery`) published by the badge issuer. Badge definitions can be updated.
+1. 「バッジ定義」イベントはバッジ発行者によって発行されるバッジ (例えば`bravery`) を一意に特定する値を持つ`d`タグを持つ、kind `30009`のパラメータ付き上書き可能イベントとして定義されます。
 
-2. A "Badge Award" event is a kind `8` event with a single `a` tag referencing a "Badge Definition" event and one or more `p` tags, one for each pubkey the badge issuer wishes to award. Awarded badges are immutable and non-transferrable.
+2. 「バッジ授与」イベントは、それぞれバッジ発行者が授与したい公開鍵を指す1つ以上の`p`タグと、「バッジ定義」イベントを参照する1つの`a`タグを持つkind `8`イベントです。授与されたバッジは変更したり譲渡できません。
 
-3. A "Profile Badges" event is defined as a parameterized replaceable event
-with kind `30008` with a `d` tag with the value `profile_badges`.
-Profile badges contain an ordered list of pairs of `a` and `e` tags referencing a `Badge Definition` and a `Badge Award` for each badge to be displayed.
+3. 「プロフィールバッジ」イベントはパラメータ付きで上書き可能な、
+`profile_badges`値を持つ`d`タグを持つkind `30008`イベントです。
+プロフィールバッジはそれぞれ「バッジ定義」と陳列したいバッジのための「バッジ授与」を参照する`a`タグと`e`タグの組の順序付きリストを含みます。
 
-### Badge Definition event
+### バッジ定義イベント
 
-The following tags MUST be present:
+以下のタグが存在しなければなりません (MUST) 。
 
-- `d` tag with the unique name of the badge.
+- バッジの一意な名前を持つ`d`タグ。
 
-The following tags MAY be present:
+以下のタグが存在してもかまいません (MAY) 。
 
-- A `name` tag with a short name for the badge.
-- `image` tag whose value is the URL of a high-resolution image representing the badge. The second value optionally specifies the dimensions of the image as  `width`x`height` in pixels. Badge recommended dimensions is 1024x1024 pixels.
-- A `description` tag whose value MAY contain a textual representation of the
-image, the meaning behind the badge, or the reason of it's issuance.
-- One or more `thumb` tags whose first value is an URL pointing to a thumbnail version of the image referenced in the `image` tag. The second value optionally specifies the dimensions of the thumbnail as `width`x`height` in pixels.
+- バッジの短い名前を持つ`name`タグ。
+- バッジを表現する高解像度な画像のURLを値として持つ`image`タグ。2つ目の値は任意で、ピクセル単位で`width`x`height`のようにして画像の寸法を指定します。バッジの推奨寸法は1024x1024ピクセルです。
+- 画像のテキスト表現、バッジの意味、あるいは発行の理由を含む
+`description`タグ。 (MAY)
+- `image`タグが参照する画像のサムネイル版を指すURLを1つ目の値として持つ1つ以上の`thumb`タグ。2つ目の値は任意で、`width`x`height`ピクセルでサムネイル寸法を指定します。
 
-### Badge Award event
+### バッジ授与イベント
 
-The following tags MUST be present:
+以下のタグが存在しなければなりません (MUST) 。
 
-- An `a` tag referencing a kind `30009` Badge Definition event.
-- One or more `p` tags referencing each pubkey awarded.
+- kind `30009`のバッジ定義イベントを参照する`a`タグ。
+- それぞれが授与対象の公開鍵を参照する1つ以上の`p`タグ。
 
-### Profile Badges Event
+### プロフィールバッジイベント
 
-The number of badges a pubkey can be awarded is unbounded. The Profile Badge
-event allows individual users to accept or reject awarded badges, as well
-as choose the display order of badges on their profiles.
+1つの公開鍵に対して授与されるバッジの数は無制限です。プロフィールバッジイベントで
+個々のユーザーが授与されたバッジの受け入れ・拒否、
+プロフィールに陳列するバッジの順序を選択できます。
 
-The following tags MUST be present:
+以下のタグが存在しなければなりません (MUST) 。
 
-- A `d` tag with the unique identifier `profile_badges`
+- 一意な識別子`profile_badges`を持つ`d`タグ。
 
-The following tags MAY be present:
+以下のタグが存在してもかまいません (MAY) 。
 
-- Zero or more ordered consecutive pairs of `a` and `e` tags referencing a kind `30009` Badge Definition and kind `8` Badge Award, respectively. Clients SHOULD
-ignore `a` without corresponding `e` tag and viceversa. Badge Awards referenced
-by the `e` tags should contain the same `a` tag.
+- それぞれkind `30009`のバッジ定義とkind `8`のバッジ授与を参照する、連続する0個以上の`a`タグと`e`タグの順序付きペア。クライアントは
+`e`タグを含まない`a`タグやその逆を無視しなければなりません (SHOULD)　。 `e`タグによって参照される
+バッジ授与イベントは同じ`a`タグを含むべきです。
 
-### Motivation
+### 動機
 
-Users MAY be awarded badges (but not limited to) in recognition, in gratitude, for participation, or in appreciation of a certain goal, task or cause.
+ユーザーは (これに限定されませんが) 特定の目標やタスク、または大義に対する認識、感謝、参加、または評価としてバッジを授与されてもかまいません (MAY) 。
 
-Users MAY choose to decorate their profiles with badges for fame, notoriety, recognition, support, etc., from badge issuers they deem reputable.
+ユーザーは、信頼できるバッジ発行者からの名声・悪名・認識・サポートなどを意味するバッジを選んで飾ってもかまいません (MAY) 。
 
-### Recommendations
+### 推奨事項
 
-Badge issuers MAY include some Proof of Work as per [NIP-13](13.md) when minting Badge Definitions or Badge Awards to embed them with a combined energy cost, arguably making them more special and valuable for users that wish to collect them.
+バッジ発行者はバッジ定義やバッジ授与をミントする際にこれらとエネルギーコストを紐づけるために[NIP-13](13.md)のようにProof of Workを含めてもかまいません (MAY) 。
 
-Clients MAY whitelist badge issuers (pubkeys) for the purpose of ensuring they retain a valuable/special factor for their users.
+クライアントはユーザーに対する価値/特別性を保っていることを保証する目的でバッジ発行者 (公開鍵) をホワイトリストに登録してもかまいません (MAY) 。
 
-Badge image recommended aspect ratio is 1:1 with a high-res size of 1024x1024 pixels.
+バッジ画像のアスペクト比は1:1で、1024x1024の高解像度画像であることが推奨されます。
 
-Badge thumbnail image recommended dimensions are: 512x512 (xl), 256x256 (l), 64x64 (m), 32x32 (s) and 16x16 (xs).
+バッジのサムネイル画像の推奨寸法は512x512 (xl) ・256x256 (l) ・64x64 (m) ・32x32 (s) ・16x16 (xs)です。
 
-Clients MAY choose to render less badges than those specified by users in the Profile Badges event or replace the badge image and thumbnails with ones that fits the theme of the client.
+クライアントはユーザーによってプロフィールバッジイベントで指定されたすべてのバッジを表示しなくてもかまいませんし、バッジ画像とサムネイルをクライアントのテーマに合うものへ置き換えてもかまいません (MAY) 。
 
-Clients SHOULD attempt to render the most appropriate badge thumbnail according to the number of badges chosen by the user and space available. Clients SHOULD attempt render the high-res version on user action (click, tap, hover).
+クライアントはユーザーが選択したバッジの数と使えるスペースに応じて最も適切なバッジのサムネイルを表示するべきです (SHOULD) 。クライアントはユーザーのアクション (クリック、タップ、ホバー) に応じてバッジの高解像度画像を表示するべきです (SHOULD) 。
 
-### Example of a Badge Definition event
+### バッジ定義イベントの例
 
 ```json
 {
@@ -91,7 +91,7 @@ Clients SHOULD attempt to render the most appropriate badge thumbnail according
 }
 ```
 
-### Example of Badge Award event
+### バッジ授与イベントの例
 
 ```json
 {
@@ -107,7 +107,7 @@ Clients SHOULD attempt to render the most appropriate badge thumbnail according
 }
 ```
 
-### Example of a Profile Badges event
+### プロフィールバッジイベントの例
 
 Honorable Bob The Brave:
 ```json

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)。