How do I query a relay for multiple event IDs that are replaceable?
I need to query 50+ pairs (pubkey1, appid1), (pubkey2, appid2)... (pubkey50, appid50) for a fixed kind.
Do I need to make 50+ separate requests? One request with 50+ filters?
Or should we make {ids: ...} recognize replaceable IDs in relays?
#asknostr #devstr
why not
filter {
authors: [
kinds: [app kind]
}
And the app ID?
This is the correct answer
No, that is incorrect unfortunately. That will give me all the events by all those pubkeys, which is not what I want. It should match both (pubkey, appid).
This is the most pragmatic way I found to do this. Depnding on the usecsse you get ~50% more data than you need and filter it client side. If you control the events you can stuff them with indexable tags but that's less elegant and someone will probably start publishing events with them stripped out.
Thanks man. Honestly, why settle with such crappy fixes? I know we can't change relays tomorrow but no one seems to care
I ran into this problem also
Did you find a good workaround?
Nope. Only the solutions I could think of require a spec update, like yours on the relay side, or on the client side we need to start including an indexable tag with the address/aTag
how would this work? isn't the `#d` tag already indexable?
He means adding 'a' tags to the target events and querying them via '#a', that may work in some scenarios
Yes but thinking about it a bit more now, it wouldn't be a good solution because anyone could create the same 'a' tag and mess up your results on purpose.
My use case was the same as a few other feeds I have, where I fetch reactions from my follows, then do a single query with 50-100 ids to build feed based on those reactions.
I wanted to do the same for Articles (kind 30023), almost had it ready until I realized I can't query 50-100 article aTags in one go.
Agree. And there is zero clarity on limits really, so 50-100 is just kinda shooting in the dark and hope relays return enough and keep iterating.
Just wrote this, and actually would be great if relays could via NIP-11 inform what's a maximum amount of accepted ids in the req.
nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug any thoughts on this one?
One filter for each, rotating very fast.
Hmm. What is rotating?
I do not intend to hit the database 50 (100, 200+?) times, actually cross the whole stack, for just one query (that is very common)
Relays are databases, period
Was a joke, because, yes, they should be.
The protocol is just not there yet so all you can do for now is a shitload of requests and be a database, which in itself is funny.
Rest assured, as more use cases that make this kind of filter needed arise, the protocol will have to adapt to it.
There is some motivation behind the current limitations tho. In my opinion, useless efforts of premature optimization that resulted in limited database querying capabilities, which in turn limits possible use cases which ultimately limits growth.
No biggie, this journey is just starting. We'll get there. Keep building 💪
Most relays don't take 50 filters or 50 subs at the same time, so you need to split it, resolve some npubs, mark the EOSE, move to the next group and so on. Then use the eose cache for each sub to avoid downloading the same event many times.
My usecase is a bit different probably but appreciate the explanation
For replacables you can query for a-tags in the filter, or am I missing sth?
'#a': [
No yeah, I see your problem
you need to request each one separately, which is a pain. default query for addressable events is very much needed not on the "ids" field though.. better to use a new one like "addressable" or just "addr" that takes "a" tag values `
Maybe not a new one, but either way I'll take that
if you search for the list of authors and identifiers?
There are no decent solutions to this problem so I am proposing a NIP to fix it:
One thing is clear from this discussion, clients will do crazy workarounds to acommodate relays.
On average relays have way more powerful hardware, yet we are okay with shifting all the work to clients.
And I don't feel much desire to improve the situation, even slightly, just pure resignation? Or what am I missing?
I heard efficiency being cited many times, not to overload relays, when all these workarounds are wasteful.
I really want nostr relays to remain interoperable, but this is pushing me. If the situation does not improve in a few months I'll be forced to start coding custom extensions to my relays.
