Submitted a PR to strfry to allow a new kind of query that I don't see people talk about much:
https://github.com/hoytech/strfry/pull/133
this will enable a simple "algo" feed on strfry that fetches the last note from each user in your contact list (or any list)
we need relays to support request that filter by any identified list, not just deprecated kind 3
queries don’t care about where the pubkeys come from
most queries are pushing the same pubkeys to the relays over and over
I've suggested this idea since day 1, just never took off
where's the PR for the NIP change? or is there none and we need to formally write it up?
maybe we just need to support it with a new or forked relay.
saving network and compute costs is worth it
"worth it" is subjective. it greatly complicates the query language
I can never remember the difference between a filter and a query. I thought strfry only had filters.
you query the database with filters
I thought you query the database and then run filters on the query?
Or are the terms used differently in different tools?
the filters are the query
Oh, guess that's different, than in a RDB, where filters are just the WHERE clauses and stuff.
Guess there are no real queries, in strfry, since it's all documents instead of tables, so you don't have to assemble a subset of table columns to filter (filters applying to the content of the rows), you just filter all of the documents.
Or something.
any rational developer can see the advantage of this to reduce excessive network traffic and begin more elaborate queries that can be more performant closer to the data source
I like that this doesn't go straight to protocol extension, but do you think relays are going to accept 1000 filters in a request?
this change has been rolled out to the nostr1.com fleet, with a setting of 1000 max filters. 👀
