quoting"Relays should not be treated as databases" is silly and can kill nostr.
nevent1q…waqv
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.
melvincarvalho on Nostr: Failure to understand the basics. Nostr is a RELAY system. The clue is in the name. ...
Failure to understand the basics. Nostr is a RELAY system. The clue is in the name. Notes and other stuff transmitted by relays. You could take 100 databases and nostr would be the worst-in-class. It's not a database. Realizing this is incredibly empowirng, because you can let nostr be nostr, and let it do one thing well, and then you have almost unlimited flexibility to build a system.