-
@ Don
2024-12-05 11:16:09フォロワーリストを低コストで取得する仕様を考える
Nostr リレーはフォロワー数をカウントしたほうが良いを受けて考えたことを雑多に書き留めておきます
単一リレーの場合
NIP-45 COUNT を使う
短所
- 単一リレーで数えた総数でしかない
- 現時点では数を返すのみ
- 複数リレーでマージできるようにidsを一緒に返そうという提案もある
{"#p": ＜pubkey＞, "kinds": [3]} でREQする
短所
- 単一リレーで数えた総数でしかない
- フォロワーの数だけクソデカイベントが返ってくるので時間がかかるしギガが減る
複数リレーの場合
{"#p": ＜pubkey＞, "kinds": [3]} でREQする
長所
- 複数リレーでマージできる
- そこそこもっともらしいフォロワーリストが取れる
短所
- 一度でもフォローをしたことがある人のリストでしかない(後にアンフォローしたかもしれない)
- nostr:nevent1qqs829n0s3qa3wegnhpf6haz3t87hn9huznldd4x2ld6c0d02uq09gsge47l7
- リストすべての公開鍵で接続リレーとkind3を調べ直してアンフォローされている場合を除く処理をすればそこそこ正確になる
- 大変すぎる
- 未調査のリレーにフォロワーがいるかもしれない
新しいkind(フォロワーを格納する)を新設する
仮にkind1003とする
kind3と同じ構造とする{ "kind": 1003, "pubkey": "＜Aさんの公開鍵＞", "tags": [ ["p", "＜Bさんの公開鍵＞"], ["p", "＜Cさんの公開鍵＞"], ["p", "＜Dさんの公開鍵＞"] ], // other fields... }で、これ誰が作るの？
リレーが作る
- pubkeyにはAさんの公開鍵を入れることになるけど、署名するにはAさんの秘密鍵が必要だよ？
- 無理
クライアントが作る
- Rabbitやnostter等のクライアントにはプロフィール画面でフォロワーのところをクリックするとフォロワーの取得が始まる
- その際、構築したフォロワーリストをkind1003イベントとしてリレーに送ってしまえば良い
- リレー毎でなく複数リレーのマージした結果であるが、その方が有用だろう
- でもkind1003を作成した時期はアカウント毎にバラバラになってしまうね
誰が嬉しいの？
- クライアントは恩恵を受けない
- 本来kind1003の恩恵を受けるべきクライアント自身がkind1003を作らなくてはならない
- 統計調査に興味がある人が満足する
- そのためだけに各クライアントを使用するユーザーの端末のリソースを使う価値があるかどうか
そもそもリレーである必要があるだろうか
- リレーはシンプルであるべきだが、リレーに高機能を求めること自体は否定されるべきことではない
- NIP-50のように検索に特化したリレーもある
でもこの統計情報ってWebSocketで送られてくるべきものだろうか？HTTPで良くない？
リレーである必要すらなくて、REST APIを提供するサービスがあれば十分だよね？
外部サービスとして独自にデータを集めているサービスは既にあるこれをNIPにする必要があるだろうか
- WebSocketやリレーが登場しないからといってNIPに定義してはいけないなんてことはない
- 例: NIP-96
- しかしNIPというのは仕様を共通化して共有するためのものであり、複数の実装を期待するものである
- 統計API提供サービスなど1つあれば十分で、耐検閲性を目的として10個も100個も存在を期待されるものではない