Skip to content

Latest commit

 

History

History
68 lines (44 loc) · 4.67 KB

65.md

File metadata and controls

68 lines (44 loc) · 4.67 KB
Raw

NIP-65

リレーリストメタデータ

draft optional

あるユーザのコンテンツを発見したり他人からの最新のコンテンツを受け取ったりするための推奨リレーの広告を目的とする、kind:10002を用いる上書き可能イベントを定義する。

このイベントには、リレーURIとreadまたはwriteマーカーを持つrタグのリストを含めなければならない (MUST) 。read・write とマークされたリレーをそれぞれ読み出し (READ) ・書き込み (WRITE) リレーと呼ぶ。マーカーが省略された場合、そのリレーは両方の目的で利用される。

.contentは使用しない。

{
  "kind": 10002,
  "tags": [
    ["r", "wss://alicerelay.example.com"],
    ["r", "wss://brando-relay.com"],
    ["r", "wss://expensive-relay.example2.com", "write"],
    ["r", "wss://nostr-relay.example.com", "read"]
  ],
  "content": "",
  // その他のフィールド...
}

このNIPは、 (kind:3スタイルのリレーリストのような) クライアントによるリレーの使われ方を設定する目的で設計されたリレーリストを完全に置き換えるものではない。クライアントはkind:10002のリレーリストを発見できない状況において、他のリレーリストを使用してもかまわない (MAY) 。

読み出し・書き込みリレーをいつ使用すべきか

あるユーザから発せられたイベントを探す際は、クライアントはそのユーザのkind:10002に含まれる書き込み (WRITE) リレーを使用すべきである (SHOULD) 。

あるユーザに関するイベント、すなわちそのユーザがタグ付けされているイベントを探す際は、クライアントはそのユーザのkind:10002に含まれる読み出し (READ) リレーを使用すべきである (SHOULD) 。

イベントを送信する際は、クライアントは以下のようにすべきである (SHOULD) 。

  • イベント発行者の書き込み(WRITE)リレーにイベントを送信する
  • イベントにタグ付けされた各ユーザの読み出し(READ)リレーにイベントを送信する

動機

ユーザごとに固定のリレーリストを用いる従来のモデルでは、有力なリレー運用者に権力が集中する。

  • ほとんどのユーザは自分の投稿を同一の非常に人気なリレーに送信する。これは投稿をより幅広い読者に届けるのが目的である。
  • 多くのユーザは、より多くのデータを得るためにたくさんのリレーからイベントを取得しているが、これはデータの重複という代償を伴う。
  • イベントはリレー間でコピーされている。多くの場合、たくさんの別々のリレーにコピーされる。

このNIPにより、クライアントが各ユーザ個人の最新のリレーセットに対して直接接続できるようになり、人気のリレーにイベントを送信する必要がなくなる。

総論

  1. クライアントは、kind:10002のリストを小さく (リレー2〜4個) 保つようユーザに案内すべきである (SHOULD) 。

  2. クライアントは、可能な限りたくさんのリレーに作者のkind:10002のイベントを拡散するべきである (SHOULD) 。

  3. kind:10002のイベントは、そのユーザが推奨するリレーを他人に広告することを主な目的として使用すべきである。そのユーザ自身のクライアントは、データの取得に用いるリレーを選択する際に他のヒューリスティクスを用いてもかまわない。

  4. 最大限のプライバシーを保つために、ダイレクトメッセージは送信者の書き込み (WRITE) リレーと受信者の読み出し (READ) リレーのみに送信するべきである (SHOULD) 。

  5. リレーがNIP-11ドキュメントでこのNIPのサポートを告知しているならば、それはそのリレーが、料金を支払っている顧客やホワイトリストで許可されたグループに限らず、幅広いユーザからのkind:10002のイベントを受け入れる意思があることを意味する。

  6. クライアントは、RFC 3986に従ったリレーURIの正規化によって、接続の重複を排除するべきである (SHOULD) 。

関連記事