franzap on Nostr: Not being able to execute more complex queries on relays tips the balance in favor of ...

Not being able to execute more complex queries on relays tips the balance in favor of custom API servers.

Any service that values great UX (and no, we have awful UX on nostr so far) will end up choosing a custom server. This means users will lack the ability to manage servers like they do with relays, and therefore reduce user choice and decentralization.

Few.

quoting nevent1q…qsnk

"Relays should not be treated as databases" is silly and can kill nostr.

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.