NIP-67は、既存のEOSEメッセージを拡張し、relayがfilterに一致する保存済みイベントをすべて返し終えたかどうかを示す任意の3番目の要素を追加するオープン提案です。狙いは、subscriptionが尽きたのか、それともrelay側の上限で途中で切られたのかをclientが判断するために現在使っている信頼できないheuristicを置き換えることです。

問題

EOSEは保存済みイベントとリアルタイムイベントの境界を示しますが、完全性についての情報は含みません。実際には、relayはsubscriptionごとに上限を設けており、これはclientのlimitとは独立していて、一般に300から1000イベント程度です。relay側の上限が300なのに、clientが直近500件のノートを要求すると、300件のイベントとEOSEだけを受け取り、それが「全部」なのか「途中で止まった」のかを区別できません。現在の回避策は、イベント数をclientのlimitと比較して防御的にページ送りすることですが、上限が要求数より低いとイベントを取りこぼし、逆に上限が実際の一致件数の倍数だと余分な往復が発生します。

境界時刻の同着も問題を悪化させます。until = oldest_created_atでページ送りすると、relayの時刻比較方法次第で、そのbatch内の最古timestampを共有するイベントを取りこぼすか重複取得する危険があります。

変更内容

NIP-67はEOSEへ任意の3番目の要素を追加します。

["EOSE", "<subscription_id>", "finish"]   // 一致する保存済みイベントをすべて配信済み
["EOSE", "<subscription_id>"]             // 完全性の主張なし（従来形式）

仕様化されるのは肯定シグナルだけです。NIP-67対応をadvertiseしているrelayがhintを省略した場合、それはまだ続きがあることを意味します。対応をadvertiseしていないrelayは従来のheuristicへそのまま落ちるため、この変更は現在のすべてのclientとrelayに対して後方互換です。

relayがNIP-67をサポートしていると分かっているclientは、"finish"を見た時点でページ送りを止められ、結果件数がちょうどrelay上限に一致する場合でも余分な往復を避けられ、完全性をより正確にユーザーへ示せます。

ステータス

この提案は、NIPsリポジトリに対するPR #2317としてオープンです。

Primary sources:

Mentioned in:

See also: