higher event ID? by timestamp? based on a filter?
that's a pretty narrow attack surface
clients can mitigate it by being more specific, things like authors are a huge limiter
Discussion
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
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