## まえおき

私の記事、文章がいまいちすぎて、言いたいことが伝わらないですね。すみません。

補足の意味を込めて以下書きました。

##

とりあえず単一のリレーでの話とさせてください。複数リレーの話はおいておきます。

単一リレーの場合としても、記事の趣旨説明に問題ないと思っています。

REQ と filters の組み合わせで自分をフォローしている npub を取得できるのは理解できます。

ですけど、私は、 REQ と filter による検索は実用的ではないのではないかと考えます。

事例頂いたコマンド試してみたのですが、速度が出ていないように思います。

恐らくなのですが、この REQ に対応するクエリに対して、適切なインデックスが存在しないからなのではないかと考えます。

REQ と filter を用いた問い合わせはシンプルで一貫してて、応用も効いて美しいと思います。

ですけど、ユーザーやレコードの増大に対して、負荷がスケールするような方法では無いと考えています。

多数存在しうる filter の組み合わせに全てに対して複合インデックスを付与することが、実質できないと考えるからです。

今はデータセットの規模が小さいので、なんとか検索できるように見えているだけで、ユーザー数の増大に伴い実用的に機能しなくなるのではないかと。

そういう懸念を思い浮かべて「逆引きする方法が必用」と言いました。

これはフォロワー取得だけじゃなくて、REQ で問い合わせ全体に関連することかと思います。

いずれ REQ による汎用的な問い合わせ機構は obsolete になり、単機能かつ必要最小限なAPIセットの様な仕組みにシフトしていくように思います。

## 2

REQ で帰ってきたレコード数をカウントできる機能があるのは知りませんでした。

そうすると、パフォーマンスの問題はさておけば、フォロワーのカウントは既にできるということですね。

失礼しました。

題名「Nostr リレーはフォロワー数をカウントしたほうが良い」は的を射たものではなかったですね。

フォロワー数のカウントするためには、フォロワーを効率的に検索できる必用があり、そのための機能を持ったほうがいい・・・と言いたかったのですが。

これら鑑みてタイトルを言い換えると「Nostr のリレーはフォロワーリストを効率的に取得できるようにしたほうが良い」になるかと思います。

## 3

これは記事とは直接関係ないですが、私は、フォロワーのリストを取得できることは、Twitterタイプのソーシャルメディアの本質的な機能であり、サービスの大きな付加価値じゃないかなと考えます。

自分自身はフォロワー数を気にしない使い方をしていますが、それとは別にものすごく大事なポイントだろう・・・と思っています。

なぜなら、情報を発信する際にファーストオーディエンスの規模や特徴が見えることに、すごく価値があると考えるからです。

受信者を把握することは情報発信時の大事なポイントで、それに基づいてどんな情報発信をするか決める必要があるからです。

Nostr でもフォロワー効率の良い、ユーザーの増大に耐えうる、フォロワーの把握の手段があってほしいな・・・と思います。

## さいご

今考えてみると、私のデータベースの知識が古すぎて、もしかしたら、上記の懸念は今では問題ないかもしれないです。

もしくは、私が複雑すぎてできない・・・と考えているものが、ITの現場では全然当たり前にしていることだったり。

そうだったらすみません。以上です。