Given the folllowing structure: apps -> releases -> file metadatas

User searches are performed on apps, once an app is selected we fetch latest release, and from there grab file metadatas.

It's easy when the search is done on one event kind (apps) but now I need to also start filtering on file metadatas (for platform/os/architecture). You don't want to be presented search results for which there's no app for your operating system.

Theres no way of doing joins or more expressive querying in nostr - unless copying the data I need onto one single event kind, which is the workaround I did and I hate it. 

 Is it just that you want to search for "banana" and get back only the banana apps that have files available for your OS?

There is unlimited flexibility on the search handler side. NIP-50 even specifies a way to add custom filtering that you could use like "banana os:android-v15-x64". If the app-capable relays support this syntax they will take file metadata into consideration already when returning results. 

 From what I understood zap.store is already assuming there will be specialized relays for curated app directories, right? 

 Yes, you're right. I heavily rely on NIP-50. I just didn't want to keep going down the custom query syntax route to prevent too much specialization, so I opted for data duplication

But as you note below that might be the case anyway, having custom relays in these scenarios 

 I don't know if this is the solution, but the amount of query flexibility you would need in your case would be very very hard to achieve using native Nostr query language in a generic way. Even if you had one MongoDB with all the data I think you wouldn't be able to do the query you need. 

 App events should include OS tag. These complex queries seem to only be needed when data structure doesn't fit your use case 

 That's what I had to do but implies data duplication. The platform information (OS/architecture) is in the 1063 event where it should belong

Anyway I was bringing it up regardless of this particular case 

 That's what I am saying - the general solution is data duplication, not complex queries. We duplicate events across relays already, duplicating fields across related events makes as much sense. 

 I can partially agree, sometimes it's a good tradeoff.  Duplicating events is not at all the same as duplicating fields though 

 I agree with that too. 

 here are my suggestions for how search should work: 2 modes. strict string match: returns only exact string matches. vector search: return matches based on similarity.