i will likely just do something simpler, notedeck currently represents each column as a single filter, not sure what this spec would be for ?
Discussion
There are common use cases ( like relay-based feeds) that can't be represented with filters. The set operations are complex, but allow for feed composition. DVMs or relays make it open ended, which allows you to avoid unlimited complexity in the spec. Also, breaking each filter key into a separate element makes it easier to build a ui for editing feeds. It's live on dev.coracle.social if you want to play with it.
hmm i am leaning toward wasm filters/reducers for arbitrarily complex local queries:
That works well for local queries or for relays that support map/reduce (which is a good idea), but less well for generic remote relay access, at least in the short term. My approach is to generate efficient queries rather than post process, which is mostly doable.
It seems like regardless of fetching strategy nostrscript and my nip are representing basically the same stuff, so as long as they could be compiled into one another they could be considered equivalent.
Does nostrscript have a spec yet? Until it's more widely available to developers it sort of fails the interoperability test. It's not trivial to write an interpreter for custom feeds either, but it's more accessible since there's no parsing step required.
IMO filters need a negation operation, for at least IDs but authors is easy to see the use of it, and i think almost every other field could use a negation