NIP-65
Relay List Metadata
/icons/hr.icon
翻訳
リレーリストメタデータ
あるユーザからのコンテンツを発見したり他のユーザからの最新のコンテンツを受け取ったりするための推奨リレーを広告するために、kind:10002を用いる上書き可能イベントを定義する。
このイベントにはリレーURIとreadまたはwriteマーカーを持つrタグのリストを含めなければならない(MUST)。マーカーが省略された場合、そのリレーは両方の目的で用いられる。
contentは使わない。
code:10002.json
{
"kind": 10002,
"tags": [
],
"content": "",
...other fields
}
このNIPは、(kind:3スタイルのリレーリストのような)クライアントが使うリレーを設定する用途で設計されたリレーリストを完全に置き換えるものではない。クライアントは、kind:10002のリレーリストが見つからない状況で他のリレーリストを用いてもよい(MAY)。
Readリレー と Writeリレー をいつ使うか
あるユーザからのイベントを探す際は、クライアントはそのユーザのkind:10002に含まれる書き込み先(write)リレーを用いるべきである(SHOULD)。
あるユーザに関するイベントを探す際(そのユーザがタグ付けされているとき)は、クライアントはそのユーザのkind:10002に含まれる読み取り元(read)リレーを用いるべきである(SHOULD)。
イベントを配信する際は、クライアントは以下のようにすべきである(SHOULD):
イベント発行者の 書き込み先(write)リレーに配信する
そのイベントにタグ付けされている各ユーザの 読み込み元(read)リレーに配信する
動機
ユーザごとに固定のリレーを使うという従来のモデルでは、大規模なリレーの運用者に権力が集中する:
ほとんどの人は、投稿を多くの人に見てもらうために一部の人気の高いリレーに送信している
多くの人は、より多くのデータを得るためにたくさんのリレーに接続している(→大量のイベントが重複)
イベントはリレー間で(多くの場合、たくさんのリレーに)複製されている
このNIPにより、クライアントが各ユーザ個人の最新のリレーセットに直接接続できるようになり、人気の高いリレーにイベントをブロードキャストする必要がなくなる。
総論(Final Considerations)
1. クライアントは、kind:10002のリストを小さく(2~4個)保つよう案内すべき(SHOULD)
2. クライアントは、可能な限りたくさんのリレーにkind:10002のイベントを拡散すべき(SHOULD)
3. kind:10002のイベントは、ユーザがよく使うリレーを他人に広告することを主目的とすべき。クライアントは、データを取得するためのリレーを選択する際に他のヒューリスティクスを用いてもよい。
4. 最大限のプライバシーを保つため、DMは送信者の書き込み先リレーと受信者の読み取り元リレーのみに配信されるべき(SHOULD)
5. リレーが NIP-11 のドキュメントでこのNIPをサポートしていることを告知してきた場合、そのリレーは購入者やホワイトリストで許可したユーザに限らず、広範囲のユーザからのkind:10002のイベントを受け入れる意思があると考えてよい 関連記事