- Denormalization, brugeman (npub1xdt…ntxy) 's favorite 😄. It does help and the route I'm opting to take, but just by pure chance as I'm still able to somewhat control the shape of kind 32267. For kinds out in the wild, this is impractical or impossible
- Proprietary backend that talks to the relay database. Throw the nostr towel, embrace speed/UX at the expense of backend replaceability/decentralization. Running it as DVM could be a marginal improvement if spec'd
- REQ filters improvement. Done well it could cover many more querying cases, improve speed/UX with little impact on relay operators. The conversation I'm trying to open but it ruffled some feathers
quoting"Relays should not be treated as databases" is silly and can kill nostr.
nevent1q…qsnk
The relay query language was designed around a social notes client use-case. The "other stuff" that we love to talk about, as much as it's part of the nostr acronym, is an afterthought.
Other stuff clients do not work like social clients. They have way more specific requirements and hence need to use relays more like databases.
Since the query language is terribly limiting, this results in:
- Higher amount of requests
- More bandwidth
- More client-side processing
Do we want nostr to compete in terms of UX with other platforms/protocols or be forever lagging behind?
Worst of all, this leads developers to implementing hacks to perform queries (custom languages via NIP-50, for instance) which entirely defeats the point of a relay: to be easily swappable.
If we can't easily swap relays, nostr is dead.
The rationale for not treating relays as databases is based on the fallacy of simplicity. Since we want anyone (yes including your grandma) to create a relay we must make it as simple as possible – so we should not force implementation details such as requiring a database.
But guess what is the simplest way to build a relay? Using a database.
If we want nostr to succeed we must grow up, assume that relays will have a database backend, and reach consensus on a better query language that we're confident can be implemented in most engines (SQL, noSQL, graph, and so on).
Not perfection, not a highly complex language, but something that allows more flexibility than the archaic filters we have right now.