From c3fd9af17939316bf6d0d83a5759100f8b0a1bdb Mon Sep 17 00:00:00 2001 From: mattn Date: Fri, 4 Sep 2026 04:19:51 +0000 Subject: [PATCH] Clarify zero limit behavior (#2460) --- 01.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/01.md b/01.md index 6f26a3a8..d88124e3 100644 --- a/01.md +++ b/01.md @@ -148,6 +148,8 @@ A `REQ` message may contain multiple filters. In this case, events that match an The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. Relays SHOULD use the `limit` value to guide how many events are returned in the initial response. Returning fewer events is acceptable, but returning (much) more should be avoided to prevent overwhelming clients. +When `limit` is zero, the relay MUST NOT return stored events for that filter. After the initial queries for all filters are complete, the relay MUST send `EOSE` and MUST keep the subscription active for newly received matching events. + ### From relay to client: sending events and notices Relays can send 5 types of messages, which must also be JSON arrays, according to the following patterns: