Skip to content

02.md

Latest commit

 

History

History
78 lines (53 loc) · 3.82 KB

02.md

File metadata and controls

78 lines (53 loc) · 3.82 KB

NIP-02

フォローリスト

final optional

「フォローリスト」を意味するkind 3の特別なイベントは、フォローしている/既知のプロフィールごとのpタグのリストを持つものとして定義される。

タグの個々の要素は、プロフィールの鍵・その鍵からのイベントを発見できるリレーのURL (必要なければ空文字列で設定可能) ・そのプロフィールのローカル名 (あるいは「愛称」) (空文字列が設定されるか、提供されないようできる) を含むべきで、つまり["p", <32-bytes hex key>, <main relay URL>, <petname>]である。

.contentは使用されない。

例:

{
  "kind": 3,
  "tags": [
    ["p", "91cf9..4e5ca", "wss://alicerelay.com/", "alice"],
    ["p", "14aeb..8dad4", "wss://bobrelay.com/nostr", "bob"],
    ["p", "612ae..e610f", "ws://carolrelay.com/ws", "carol"]
  ],
  "content": "",
  // other fields...
}

新しいフォローリストが公開されるたびに過去のものは上書きされるので、すべての要素を含むべきである。リレーとクライアントは新しいものを受け取ったら速やかに過去のフォローリストを削除すべきである (SHOULD) 。

既存のリストに新しいフォローを追加する際は常に、クライアントはそのユーザをリストの末尾に追加し、フォローした順に保存すべきである (SHOULD) 。

用途

フォローリストのバックアップ

リレーがイベントを十分な期間保存すると信じているなら、このkind 3イベントを使ってフォローリストをバックアップし、別のデバイスで復元できる。

プロフィールの発見とコンテキストの拡張

クライアントは、ブラウジングしているプロフィールがフォローしている人のリストを表示したり、フォローまたはブラウジングしている人のフォローリストに基づいて誰をフォローするかの提案リストを作成したり、他のコンテキストでデータを表示したりするためにkind 3イベントを頼りにしてもかまわない。

リレーの共有

クライアントは連絡先の完全なリストともにそれぞれの連絡先のために適したリレーを公開してもよく、これによりほかのクライアントは必要に応じてこれを内部のリレーリストの更新に使うことができ、検閲耐性が高まる。

愛称スキーム

フォローリストからのデータは、クライアントによってほかの人々のフォローリストから派生したローカルの"petname"テーブルを構築するために用いることができる。これにより、グローバルな人間が読める名前の必要性が軽減される。例えば:

ユーザーは次のような内部のフォローリストを持っている。

[
  ["p", "21df6d143fb96c2ec9d63726bf9edc71", "", "erin"]
]

そして、次のように2つのフォローリストを受け取り、1つは21df6d143fb96c2ec9d63726bf9edc71からである。

[
  ["p", "a8bb3d884d5d90b413d9891fe4c4e46d", "", "david"]
]

もう1つはa8bb3d884d5d90b413d9891fe4c4e46dからである。

[
  ["p", "f57f54057d2a7af0efecc8b0b66f5708", "", "frank"]
]

ユーザーが21df6d143fb96c2ec9d63726bf9edc71を見るとき、クライアントは代わりに erin を表示できる。 ユーザーがa8bb3d884d5d90b413d9891fe4c4e46dを見るとき、クライアントは代わりに david.erin を表示できる。 ユーザーがf57f54057d2a7af0efecc8b0b66f5708を見るとき、クライアントは代わりに frank.david.erin を表示できる。