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 a LIMIT N, execute LIMIT N + 1. If N + 1 rows are returned, drop the last row and flag the result as completeness: "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
EOSE formatter to append {"completeness": "limit" | "full"}.
NIPs Involved: NIP-67
Context & Problem
When clients send a
REQsubscription, 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 internalLIMITthreshold?Proposed Solution
Implement NIP-67 by appending a completeness hint JSON object to the EOSE message.
Scope
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".streamMap,streamFilter,streamEnd).EOSEformatter to append{"completeness": "limit" | "full"}.NIPs Involved: NIP-67