この仕様だと実用的な実装ができない、もしくはせっかくのフレキシブルな仕様なのに実用的な検索ができるのは特定のパターンのみになってしまうように思います。
これはリレーの実装依として片づけられるものではなくて、NIPの仕様が構造的にレコードの増大に対してスケールしにくいものでは・・・と考えていました。私の始点ではこれはNIPの仕様の問題に見えます。
この仕様だと実用的な実装ができない、もしくはせっかくのフレキシブルな仕様なのに実用的な検索ができるのは特定のパターンのみになってしまうように思います。
これはリレーの実装依として片づけられるものではなくて、NIPの仕様が構造的にレコードの増大に対してスケールしにくいものでは・・・と考えていました。私の始点ではこれはNIPの仕様の問題に見えます。
特定のリレーにユーザーが集中した場合には問題となるでしょう。
ユーザーが増えたらアウトボックスモデル等、複数リレーに分散する仕様が主流になるかもしれません。
そうなったらそうなったで集計はほぼ不可能になるでしょうけれども。
フォロワーの把握の精度と分散のトレードオフはあるんでしょうね。自分がポストしているリレーでフォロワーを取得して、その和集合とっていればとりあえず十分かな・・・くらいに考えててそこは何も考察無いです。
情報の整理も兼ねて私も考えてみました
いざ考えてみるとなかなか難しいものですね
nostr:naddr1qvzqqqr4gupzq6c2vr8l8m9952e9qhxt8acn8kzzypzuhm6q70fvvxylkzu49e75qq2kghm409xys46tddqhw42d295y5d29gayj6cr3gmk