NIP-45
Event Counts
リレーから条件に一致するイベントの数を取得するためのメッセージタイプ COUNT を定義するNIP。
数を数えるためだけにイベント全体を取得しなくてよくなるため通信量の削減が期待できるが、原理上単一リレー上のカウントしか取得できないので使いどころが限られる。
複数リレーから取得したカウントを合計しても意味がない。Nostrでは複数のリレーが同じイベントを重複して持つのが普通なので、ダブルカウントになってしまう。
/icons/hr.icon
リレーはメッセージタイプCOUNTをサポートしてもよい。これはイベント数を取得するための仕組みを提供するものである。
動機
クライアントが接続したリレーに対して実行しようとする問い合わせの一部は法外にコストが高い。例えばある公開鍵のフォロワー数を取得するには、クライアントは数えるためだけにその公開鍵を参照するすべてのkind 3のイベントを問い合わせなければならない。クライアント、または代わりに別個のインデクシングサーバで結果をキャッシュしてもいいが、どちらの選択肢もNostrの上に第2層のプロトコルを形成することにより、ネットワークの脱中央集権性を損なう。
フィルタと返り値
このNIPはメッセージタイプCOUNTを定義する。これはNIP-01でREQ用に規定されているのと同様の購読IDとフィルタを受けとる。複数のフィルタはORで結合され、単一のカウント結果に集約される。 code:count_req.json
カウントは{"count": <整数>}という形式でCOUNTレスポンスを用いて返却される。リレーは計算上の要求を軽減するために確率的なカウントを用いてもよい(訳注: 統計などに基づく近似値を返してもよい、ということだと思われる)。このとき、レスポンスにapproximateキーを含めて確率的カウントを行ったことを示してもよい(MAY)。
code:count_resp.json
例:
code:examples.json
# フォロワー数
["COUNT", <購読ID>, {"kinds": 3, "#p": <公開鍵>}] # 投稿とリアクションの数
["COUNT", <購読ID>, {"kinds": 1, 7, "authors": <公開鍵>}] # 投稿数の近似値
["COUNT", <購読ID>, {"kinds": 1}]