You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, filter requests seem to be responded to in reverse chronological order - the other way around than in rnostr, which I used previously. Chronological order makes it easier to process reply chains, especially since in my use-case I request potentially thousands of events from a relay. How about a flag to reverse the ordering?
Btw, ordering is entirely unspecified in the official protocol, right? No defaults, no filter options for it.
The text was updated successfully, but these errors were encountered:
I haven't looked into rnostr, but I believe most relays work the same as strfry and return in reverse chronological. Usually this is what you want to build a "twitter-like" experience, although as you say, adds some challenges when you want to reconstruct an entire thread.
The NIP-01 spec only seems to mandate the order when limit is present, in which case it is assumed reverse chron:
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.
strfry always uses newest-first, even without limit. I tried to find a discussion in the NIP repo about this, since I'm sure it's been discussed before, but it's impossible to find anything in there. If you want to help get this clarified in the spec, please open a NIP.
strfry always uses newest-first, even without `limit`
This could lead to some unexpected errors in my product. Is there a way to reverse the query results?
In the application I'm developing, I hope to receive and process messages in chronological order, meaning that messages sent earlier are received first.
Currently, the result is the opposite. I am not setting a limit, only a since, because I need to process all messages.
As: wss://relay.damus.io
In this project https://github.com/scsibug/nostr-rs-relay, if no limit is set, messages are returned in ascending order by time, which meets expectations.
As: backup.keychat.io
Currently, filter requests seem to be responded to in reverse chronological order - the other way around than in rnostr, which I used previously. Chronological order makes it easier to process reply chains, especially since in my use-case I request potentially thousands of events from a relay. How about a flag to reverse the ordering?
Btw, ordering is entirely unspecified in the official protocol, right? No defaults, no filter options for it.
The text was updated successfully, but these errors were encountered: