From 9c54549f1842245b842d8a66f3bade744da24189 Mon Sep 17 00:00:00 2001 From: Alex Gleason Date: Thu, 18 Jul 2024 22:16:45 -0500 Subject: [PATCH] NIP-01: sort events by id after created_at --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index c7d7273f..1da6e837 100644 --- a/01.md +++ b/01.md @@ -143,7 +143,7 @@ All conditions of a filter that are specified must match for an event for it to A `REQ` message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions. -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`. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data. +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. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data. ### From relay to client: sending events and notices