Repository navigation
feat(nip67): support EOSE completeness hints #718
Description
Context & Problem
When clients send a REQ subscription, Nostream streams the matching events and closes with an ["EOSE", <sub_id>] message. However, the client has no way to know why the stream ended. Did it end because there are no more events in the database? Or did it end because Nostream hit its internal LIMIT threshold?
Proposed Solution
Implement NIP-67 by appending a completeness hint JSON object to the EOSE message.
Scope
- Database Layer: Modify the PostgreSQL query builder (
event-repository.ts). When applying aLIMIT N, executeLIMIT N + 1. IfN + 1rows are returned, drop the last row and flag the result ascompleteness: "limit". Otherwise, flag as"full". - Streaming Pipeline: Plumb this completeness metadata through Nostream’s reactive streaming pipeline (
streamMap,streamFilter,streamEnd). - WebSocket Handler: Modify the outgoing
EOSEformatter to append{"completeness": "limit" | "full"}.
NIPs Involved: NIP-67
Activity
chappie-daemon commentedon Oct 24, 2026
Decision (2026-10-24): folded into #870
Delivered inside #870's NIP-currency work rather than as its own issue, because every item in this issue's scope is relay-core work that #870 writes from scratch anyway:
LIMIT N + 1and drop-the-extra-row: in the rewrite this is the store trait's query path, which [Rewrite P2] NIP currency: implement audit-identified gaps in Rust #870 touches for its own NIP gaps.streamMap/streamFilter/streamEndplumbing: the TypeScript reactive pipeline's counterpart innostream-relayis the subscription stream [Rewrite P2] nostream-relay: wire handlers, strategies, rate limits #865/[Rewrite P2] NIP currency: implement audit-identified gaps in Rust #870 already own.{"completeness": "limit"|"full"}toEOSE: one formatter branch in the handler [Rewrite P2] NIP currency: implement audit-identified gaps in Rust #870 modifies.Filed on Phase 2 and
blocked_by #870— it lands with that job, not before it. Left open on purpose: closing it now would claim work nobody has done.The one design question it carries into #870: the hint must survive the store seam, so the query that counts
N + 1rows is a store-trait capability rather than a SQL detail — the LMDB backend (#864) has to answer it too.