What are you talking about? Nostr has a query mechanism
Discussion
Nostr is a relay system. It's a simple point.
What does that even mean?
A relay system would mean just that, relaying messages. Relays do not do just that, as you can query them. You are telling me that you never queried a relay?
The " other stuff" in nostr are just different constructs of notes. If you're using nostr as simply a database for your app then you're just not aiming for real usage. But being able to interop through a common format in a well defined communication layer is the golden goose.
Do you mean people who use databases for their apps are not aiming for real usage? Why not?
Interop through a common format is exactly what is at stake when you have a query language so primitive that each client is forced to create its own.
The REQ specification is a query language, no words can hide this fact.
I'm not saying it isnt, it obviously is. But it's not going to be the next firebase/parsley database with the same performance profile that you can get for free with the extra open protocol magic. You should definitely build your own proprietary, optimized backend but the point is that the "less optimal" nostr req is still there to not gatekeep data flows
Yep I'm aware of the tradeoffs. Not everything should be free, and just like NIPs could be optional. Proprietary backends are not swappable, at least not as easily as a relay
As far as data flows its mostly clients querying relays for small subsets of data, effectively using them as open APIs anyway. For relay to relay negentropy is more efficient