100 pubkeys in one filter i mean, since nostr revolted and only supports one filter per req supposedly. (strfry obvs can do more)
Discussion
NFDB supports multiple as well!
only exception is do not mix ids and not-ids
yea, i think it was one of those standards that never caught on except in the NIPs and possibly on newer relay implementations that paid attention to the new nip changes.
you can mix them but IDs are the narrowest filter and only the IDs search is done because it wouldn't even matter if any other criteria matched if the ID doesn't match. in processing you just shortcut and only process IDs and check that first so it precedes the rest.
logically any ID criteria supersedes any other because in a filter, each field, ids, authors, tags, etc, has to have one match, so if you have 3 different top level fields in the req, then every result matches all three tests. if there is any IDs in there, then a match on one is a match on the whole group. the general policy that relays have is they just ignore the other fields. you *could* not-ignore them but then you get the side effect that unless the specified events with those IDs also have match on the others then they would be excluded, and probably the dumb client dev is wondering why when they ask for IDs they don't get all of them.
so, yeah, fuck those stupid people. give them the IDs and make anything in IDs mean IDs only. the opposite arrangement is illogical.
No revolting with Nosflare. There are no restrictions on filters in REQs. If it detects a REQ with filters arrays of more than 50 values, it'll use chunking to better handle the querying to the D1 database. When results from different filter chunks are merged, events are automatically deduplicated by their ID. Probably less efficient, but I wanted to ensure there was complete dataset for REQs.