fivebythree.net前置き
本記事は Nostr Advent Calendar 2024 12月2日分の記事として書きました。
Nostr リレーのフォロー・フォロワー数の取り扱いに関する小論です。
Nostrasia 逆アドベントカレンダーにて Nostr の方向付きクラスタリング係数をカウントしたときに、ちょっと気になっていた内容についてのごく短い考察です。考察内容はほぼ自明なことの羅列ではありますが・・・。
Nostr リレーにおける Follow/Follower 管理
Nostr で 各 npub の Follow/Follower 関係を調べるためには、各 npub の kind 3 (Follow List) を調べる必要があります。 リレーに kind 3 を問い合わせると、npub がフォローしている npub のリストを返します。
follow を増やしたり減らしたりする場合は、kind 3 で npub のリストを送信することで、フォローする npub を更新することができます。
今のところ(2024/11/30 段階では)、follower を問い合わせる kind は存在しません。
上記が Nips で定義されている follow/follower 管理の全てです。
現在の仕様の問題点と改善提案
フォロワーというのは結局、誰かがの自分をフォローした結果ですから、リレーから各 npub のフォローリストを引ければ十分な様に思えます。
しかしながら、ある npub の被フォローを調べるためには、リレーにある全 npub の kind 3 をクライアント側で調べる以外に方法がありません。 この方法は効率的でなく、ユーザー数の少ないでこそ可能な方法ではありますが、ユーザー数の増大に伴いスケールする方法では無いでしょう。
ではどうすれば良いか・・・というとリレー側で、全 npub の フォローリストを管理し、フォローリストから被フォローを逆引きできるようにすればよいだけです。
具体的には下記のテーブルのカラム “follow” から “npub” のリストを逆引きできるように、“follow” にインデックスを貼るだけです。
follow リスト
| npub(id)でソート | follower(indexed) |
|---|---|
| npub001 | npub002 |
| npub001 | npub003 |
| npub001 | npub004 |
| npub002 | npub001 |
| npub002 | npub004 |
| npub003 | npub001 |
| npub003 | npub002 |
| npub004 | npub003 |
follow リストの二列目でソート (二列目から１列目を引くことができれば、npub001 のフォロワーは npub002とnpub003であることを高速に調べること出来ます)
| npub(id) | follow(indexed) でソート |
|---|---|
| npub002 | npub001 |
| npub003 | npub001 |
| npub001 | npub002 |
| npub003 | npub002 |
| npub001 | npub003 |
| npub004 | npub003 |
| npub002 | npub004 |
| npub001 | npub004 |
これで被フォローのリストを効率的に取得することができます。 フォロワーリストの管理は結局全ての npub のフォローを一つのテーブルで管理することに帰着します。
follower 情報の有用性
情報の参照頻度の指標になる
被フォローが多いということは、その npub の情報は頻繁に参照されるということです。npub や note の検索結果表示等に優先順位をつける場合、その指標として使える可能性があります。また、頻繁にアクセスされるデータを優先的にキャッシュしたりする場合の指標とする可能性があります。
このようにして、データやユーザを重みづけする事例は枚挙にいとまがないでしょう。
例えば Google が黎明期で使い始めた PageRank という概念は、ウェブページの被リンク情報に基づいて検索結果表示の重みづけを計算するものです（ランクの高いページにリンクされているページほどランクが大きい・・・という考えでランクを決める。このロジックはトートロジーではなく、多変数の連立方程式として解が一つに決まります）。
ネットワークシステム以外では、例えば、学術論文の評価を決める場合も被引用文献に基づいた方法があります。
以上から、情報源同士の関連から情報源の重要度を推定する場合、被引用・被リンク・被フォローに基づくことが肝要です。
ネットワークの統計調査をサンプリングに基づくことができる
ソーシャルメディアのネットワークが巨大になっていくと、何等かの統計調査を行う場合サンプリングに基づくことが現実的な選択となります。サンプリングしたユーザーを基点に、フォロー・被フォローの関係から近傍のユーザー情報をもとに何等かの統計調査をすることになるでしょう。
前述したとおり、サンプリングしたユーザーの被フォローは重要な情報であると考えられます。
ユーザーの被フォローを調べるのに、結局全ユーザーのフォローを調べる必用があるなら、サンプリングの意味を成しません。
被フォローを効率的に調べる機能は、巨大なネットワークの統計調査において本質的に重要なものであるといえるでしょう。
結論
- リレー単位のフォロワーの管理は将来（ネットワークが巨大になるに従い）有用である
- follower の管理は、全ての npub のフォローリストを一元管理することに帰着する
- follower 情報が有用である事例
- 情報の参照頻度の指標として、検索結果表示やデータ配送のキャッシングの優先度として使える可能性がある
- ネットワークの統計調査を行う際にサンプリングに基づくことができるようになる
上記の有用性から、近い将来、もしくは今でもリレー内部で各 npub のフォロワー管理がされる可能性が高いと考えています。
まだ、follower を検索するための仕様は nip に存在していないようなので、近いうちに何等かの提案を行おうと考えています。