if they want moar, then tough shit because the relay sed, what it sed, nip-11 bitch
Discussion
also you could easily perform a DoS attack on certain events by creating a lot of events with a higher event ID (or lower depending on the relay impl) and the same created at as the target event
you reach your limit before the target event gets returned and there is no way to find it except by id
this will also become a problem once nostr has a high event volume per second
the only way to fix this is to allow support for proper pagination
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
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