Because I was dumb.
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 why again do we need multiple filters per subscribe? Why not allow only one filter and register multiple subscriptions? #nip01
Discussion
But actually I don't see the problem with having multiple filters. You can just treat them as independent subscriptions on the relay side, no?
I don’t see the problem either. Prolly cause I AM CURRENTLY dumb.
Can’t a REQ simply have just one filter? So what if it can have more?
Please enlighten the problem…
I‘m trying to craft a filter using just Unix commands. Instead of
tac … | grep -e … -e … | grep -e … -e … | head -n 10
I need to somehow do a union of multiple of these. I can not think of another solution than cat and subprocesses.
you should start using https://github.com/jqlang/jq and https://github.com/fiatjaf/nak
How are those performance-wise on big files? I always heard that GNU grep is fastest.
I think it's unnecessary complexity and I wouldn't do it if I could go back in the past with what I know today.
But I would also have done a binary event format, a different relay query format and ed25519 signatures and then Nostr would never have any users to begin with.
But actually maybe I would never finish writing the protocol because I would be stuck forever thinking about all problems and incentives and how to prevent them from the genesis.
multiple filters per subscription are good; some filters are conceptually the same thing so packaging in the same sub makes a lot of sense
You were not. We‘re all on your side 😘