Change NIP-65 into だ・である

65.md

@@ -6,11 +6,11 @@ NIP-65
 
 `draft` `optional`
 
-あるユーザのコンテンツを発見したり他人からの最新のコンテンツを受け取ったりするための推奨リレーの広告を目的とする、`kind:10002`を用いる上書き可能イベントを定義します。
+あるユーザのコンテンツを発見したり他人からの最新のコンテンツを受け取ったりするための推奨リレーの広告を目的とする、`kind:10002`を用いる上書き可能イベントを定義する。
 
-このイベントには、リレーURIと`read`または`write`マーカーを持つ`r`タグのリストを含めなければなりません(MUST)。`read`・`write` とマークされたリレーをそれぞれ読み出し(READ)・書き込み(WRITE)リレーと呼びます。マーカーが省略された場合、そのリレーは両方の目的で利用されます。
+このイベントには、リレーURIと`read`または`write`マーカーを持つ`r`タグのリストを含めなければならない (MUST) 。`read`・`write` とマークされたリレーをそれぞれ読み出し (READ) ・書き込み (WRITE) リレーと呼ぶ。マーカーが省略された場合、そのリレーは両方の目的で利用される。
 
-`.content`は使用しません。
+`.content`は使用しない。
 
 ```json
 {
@@ -26,39 +26,39 @@ NIP-65
 }
 ```
 
-このNIPは、(`kind:3`スタイルのリレーリストのような)クライアントによるリレーの使われ方を設定する目的で設計されたリレーリストを完全に置き換えるものではありません。クライアントは`kind:10002`のリレーリストを発見できない状況において、他のリレーリストを使用してもかまいません(MAY)。
+このNIPは、 (`kind:3`スタイルのリレーリストのような) クライアントによるリレーの使われ方を設定する目的で設計されたリレーリストを完全に置き換えるものではない。クライアントは`kind:10002`のリレーリストを発見できない状況において、他のリレーリストを使用してもかまわない (MAY) 。
 
 ## 読み出し・書き込みリレーをいつ使用すべきか
 
-あるユーザ**から**発せられたイベントを探す際は、クライアントはそのユーザの`kind:10002`に含まれる書き込み(WRITE)リレーを使用すべきです(SHOULD)。
+あるユーザ**から**発せられたイベントを探す際は、クライアントはそのユーザの`kind:10002`に含まれる書き込み (WRITE) リレーを使用すべきである (SHOULD) 。
 
-あるユーザ**に関する**イベント、すなわちそのユーザがタグ付けされているイベントを探す際は、クライアントはそのユーザの`kind:10002`に含まれる読み出し(READ)リレーを使用すべきです(SHOULD)。
+あるユーザ**に関する**イベント、すなわちそのユーザがタグ付けされているイベントを探す際は、クライアントはそのユーザの`kind:10002`に含まれる読み出し (READ) リレーを使用すべきである (SHOULD) 。
 
-イベントを送信する際は、クライアントは以下のようにすべきです(SHOULD)。
+イベントを送信する際は、クライアントは以下のようにすべきである (SHOULD) 。
 
 - イベント発行者の書き込み(WRITE)リレーにイベントを送信する
 - イベントにタグ付けされた各ユーザの読み出し(READ)リレーにイベントを送信する
 
 ## 動機
 
-ユーザごとに固定のリレーリストを用いる従来のモデルでは、有力なリレー運用者に権力が集中します。
+ユーザごとに固定のリレーリストを用いる従来のモデルでは、有力なリレー運用者に権力が集中する。
 
-  - ほとんどのユーザは自分の投稿を同一の非常に人気なリレーに送信します。これは投稿をより幅広い読者に届けるのが目的です。
-  - 多くのユーザは、より多くのデータを得るためにたくさんのリレーからイベントを取得しているが、これはデータの重複という代償を伴います。
-  - イベントはリレー間でコピーされている。多くの場合、たくさんの別々のリレーにコピーされます。
+  - ほとんどのユーザは自分の投稿を同一の非常に人気なリレーに送信する。これは投稿をより幅広い読者に届けるのが目的である。
+  - 多くのユーザは、より多くのデータを得るためにたくさんのリレーからイベントを取得しているが、これはデータの重複という代償を伴う。
+  - イベントはリレー間でコピーされている。多くの場合、たくさんの別々のリレーにコピーされる。
 
-このNIPにより、クライアントが各ユーザ個人の最新のリレーセットに対して直接接続できるようになり、人気のリレーにイベントを送信する必要がなくなります。
+このNIPにより、クライアントが各ユーザ個人の最新のリレーセットに対して直接接続できるようになり、人気のリレーにイベントを送信する必要がなくなる。
 
 ## 総論
 
-1. クライアントは、`kind:10002`のリストを小さく(リレー2〜4個)保つようユーザに案内すべきです (SHOULD) 。
+1. クライアントは、`kind:10002`のリストを小さく (リレー2〜4個) 保つようユーザに案内すべきである (SHOULD) 。
 
-2. クライアントは、可能な限りたくさんのリレーに作者の`kind:10002`のイベントを拡散するべきです (SHOULD) 。
+2. クライアントは、可能な限りたくさんのリレーに作者の`kind:10002`のイベントを拡散するべきである (SHOULD) 。
 
-3. `kind:10002`のイベントは、そのユーザが推奨するリレーを他人に広告することを主な目的として使用すべきです。そのユーザ自身のクライアントは、データの取得に用いるリレーを選択する際に他のヒューリスティクスを用いてもかまいません。
+3. `kind:10002`のイベントは、そのユーザが推奨するリレーを他人に広告することを主な目的として使用すべきである。そのユーザ自身のクライアントは、データの取得に用いるリレーを選択する際に他のヒューリスティクスを用いてもかまわない。
 
-4. 最大限のプライバシーを保つために、ダイレクトメッセージは送信者の書き込み(WRITE)リレーと受信者の読み出し(READ)リレーのみに送信するべきです (SHOULD) 。
+4. 最大限のプライバシーを保つために、ダイレクトメッセージは送信者の書き込み (WRITE) リレーと受信者の読み出し (READ) リレーのみに送信するべきである (SHOULD) 。
 
 5. リレーが[NIP-11](11.md)ドキュメントでこのNIPのサポートを告知しているならば、それはそのリレーが、料金を支払っている顧客やホワイトリストで許可されたグループに限らず、幅広いユーザからの`kind:10002`のイベントを受け入れる意思があることを意味する。
 
-6. クライアントは、[RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6)に従ったリレーURIの正規化によって、接続の重複を排除するべきです (SHOULD) 。
+6. クライアントは、[RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6)に従ったリレーURIの正規化によって、接続の重複を排除するべきである (SHOULD) 。