知らん間に NIP-11 からフィルタの最大数 max_filters が消された。リレーは自分で最大数を判断するか、無限に受け入れるしかなくなった。

https://github.com/nostr-protocol/nips/commit/611b6351863e128f470576586f0e2b9a75f19039

Reply to this note

Please Login to reply.

Discussion

なにかまずいの?

フィルタは SQL でいう所の UNION に相当するんですが、多くなるとリレーに負荷が掛かるんです。

で、リレーとしては「このリレーは最大でも 30 しか受け取らないよ」という情報を NIP-11 から返してあげる事で、クライアントが 30 個ずつ取り出す調整ができるんです。

これが無くなった事でクライアントはこの 30 という値を得られないので、無制限にフィルタが送られてくる事になります。

リレーサーバとしても「うーん、さすがに 30 超えたから駄目」というお手製チェックしかできなくなります。

この会話見る限りだと問題なさそうな感じだけど。何言ってるかはわかんないんですけぇど

https://github.com/nostr-protocol/nips/pull/1821

https://github.com/nostr-protocol/nips/pull/1645

max_filters はレコードを引く前にガードが掛けられるんですが、default_limit はフィルタから WHERE 句を作って実際にレコードを引いてからでないとガードが掛けられないんです。

リレーの負荷が増加することはわかった。geminiが嘘ついてないならネットワーク負荷が軽減されてモバイルユーザーにとっては良いことかも?しらんけど

問い合わせを複数個に区切ることで応答性は良くなると思います。