also i don't think you really fully understand how you implement pagination

you have to generate a list of matching event ID to do it, then the relay has to store it on a space limited query cache that expires after a time or volume

the idea to make a new query type that just returns these came from me thinking about that fact

it's the first step towards it, but it probably eliminates the problem altogether, seriously, 14000-21000 event id matches for a query without busting the current typical max response sizes?

DoS attack mitigation would not be relevant, that's a network layer issue not an application layer issue, in as far as it is a per-query limit not in the context of total volume from a client, that's not the same thing

Reply to this note

Please Login to reply.

Discussion

pagination can be represented statelessly with an event ID and its timestamp

no, because what happens when a new event that matches the filter gets stored?

what happens if i ask for the most recent 50 events matching a filter

then ask for page one of a 10 page of that result after 5 more new events come in?

nope, definitely stateful

i don't know what you are saying

so i send a query again for "events since X" and it's been a minute and 5 more have been stored that match

how is that not stateful

the query is pinned to a time, yes, the results, not