I think the main points that nostr:nprofile1qqsdulkdrc5hdf4dktl6taxmsxnasykghdnf32sqmnc7w6km2hhav3gppemhxue69uhkummn9ekx7mp0qywhwumn8ghj7mn0wd68ytfsxyhxymmvwshx7cnnv4e8vetj9uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qmml2f somewhat missed is that there is no SQL for Nostr relays and there is, currently, no easy replication scheme to support load balancing, especially for geo-distributed semi-mirrored servers.  

Relays ARE databases in the sense they store stuff, but if you need advanced querying capability OR if your events are too big (binary or text) or has too many tags (too many indexes), the relay operator might not be able to support it and might either reject it or become super slow.

The lack of a query language is a limit we are forcing on ourselves. The rest is pretty much solvable with the usual enterprise stack without changing the protocol. 

 nostr:nevent1qvzqqqqqqypzqun2rcnpe3j8ge6ws2z789gm8wcnn056wu734n6fmjrgmwrp58q3qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgawaehxw309ahx7um5wghx6at5d9h8jampd3kx2apwvdhk6tcqyrfamps30qqu0c7kmkvj43ngkmkzqvm777l7qfm8e3dms8pxy77qu9sqsnk 

 This is something I'd love to **hear** a discussion about.
Just leaving that out here 😜  
@Thank God For Nostr Podcast @hodlbod 
 

 By "the rest" you mean the "other stuff"? I certainly do not want to fall on the usual enterprise stack to make my other stuff client work

The relay operator is free to reject a request or charge for it 

 I don't think this is optional for non-personal relays. They will have to grow up to use thousands of servers if they want to serve users globally.

The Client won't even know if it is an enterprise stack or not. It will just use the same interface we have today. 

 I can have a relay backed by a thousand servers, but that does not solve the issues of bandwidth and client-side processing 

 True, bandwidth will always be high on Nostr. But Negentropy can help. Clients most likely will have to have a local relay to sync to and work with directly. And some of the Client-side processing will never be possible to solve, like like a true WoT with graph analysis. 

 I need to find latest releases for apps given a set of app ids and this query is complex. Syncing hundreds of thousands of releases to a local relay is not viable.

We are going to end up with more custom query languages and ad-hoc external services just because we're stubborn to address the query language issue. I'm not saying massive processing like WoT - but stuff that is trivial for SQLite to handle 

 Sql works with indexes, without them it won't help. To add proper index you add single letter tag. If you want joins then all you are asking is for relay to bear the weight for you. Just denormalize your data, add a tag, and make life easy for both sides  

 Thanks. Data is denormalized already so no joins. That is not enough. Yes, I'm happy to ask the relay to bear the weight for me. 

 I need the latest of each. Limit obviously does not help as it applies to the whole result set. Not using any sort of limit is unviable as I would get too many events 

 Maybe each app can link to it's latest release? 

 Yes they are linked already.

My request is: Give me the latest release for each one of these app ids. In SQL that can be done with a self-join I think 

 So you load apps and then latest releases by id? 

 I need to check for updates: for (com.app1, com.app2, com.app3) give me the latest 1063 events for each.

I could use one query for each, but since a user might be checking for 50-100 apps I don't want to do that. 

 Is com1 linking to latest release? 

 Assume that appid is in a tag in the release itself.

But don't worry, I'll figure it out

Thank you! 🫂 

 So there's an index and no joins so what's complex there?