Indeed. In fact the payload of nostr isnt even JSON, it's a string. With string meta data. If it were able to do JSON, as was done five years ago, it would be MUCH more powerful. Nostr has a basic database with one column of time string, some meta data, and a set of de-facto centrally controled indexes. As a relay system it's pretty good. As a database it's pretty bad. But developers are lazy and when they see a tool that they can use to do two things, they will jump on it. For nostr to be industrial scale, you can use those systems described, and couple it with a fully functioning database. But no one has done that yet.
Discussion
Well, doesn't Ditto do that, with Postgres?
Yes, you are absolutely right. That's why I like ditto. But I consider it to be next gen nostr.
Well, it's a particular use case.
#Alexandria will probably also have a database, for some premium services (self-hosted or rented), but I don't want someone needing a database to use the basic app functionality. That's sort of overengineering it.
Running a database uses more resources and is more complex than just running a relay with a stringent whitelist, or rolling events off according to a deletion-schedule, or something.
Npubs could simply download events to cache or have a SQlite or whatnot DB, or a relay on localhost.
I guess running a relay is a bit like running a Lightning node. Most people won't do it, but enough will, that everyone can use theirs and pay them (with love or money 😅 ).
A database is more like transacting on-chain. It's more persistent and secure, and allows for more complex data analysis, but costs more and is a higher hurdle because you're writing to/from the core data storage system.
I expect that there will be more LN nodes than Bitcoin nodes and more relays than Nostr-DBs, but I see viable uses cases for both.
It will be interesting to see how it plays out. I think the marginal cost of a database, or a web server, once you are running a relay, is close to zero. Like running the LAMP stack vs running plain old apache.
The difference being that the database is usually _in addition_ to a relay. It's like a relay backend. A backend to a backend, basically.
And it's another thing that could break. Adds complexity and maintenance costs, not necessarily storage costs. Also raises the cost of onboarding new maintainers, as it's one more thing they have to learn.
I do a lot of pipelining and chaining, and each little thing included drives up the chance of the whole thing breaking.
Yes I think that's why so few have done it yet. Convenience. But the power will increase 100x because cloud systems are 1000x bigger than relays systems and always will be. The main problem with the default database is that there's limited indexes which leads to centralzation of development, as developers have to ask permission to get a kind, or an index. Every other DB pushes that decision making to the developer.
Yeah, but that's why database integration and migration is a nightmare. Using a communications protocol to structure the core intra-db communication, so, that it can transit over common relays, is next-gen document db. Especially, as the protocol increasingly branches into subdomains, with their own specialty events.
Turns the Internet into a real Internet of Databases, rather than mere web pages.
So few have done it because most of the devs aren't DBMs. 😅
It's only really getting traction, now, because the relay devs and data analysts have started working on it, and their npubs are finally large enough for everyone interested to see what they're saying.
Team Backend has entered the chat.
I can see DBs for aggregators, for instance, so that you can version events without having to keep all revisions live, and do complex queries/computation on other hardware, and just serve up the results as vector embeddings.
Also allows you to store events off-relay and then pass them to the relay when only certain npubs send a request. Tighter access-control and a protective layer against hacking. You could also move the data one layer back and have multiple relays pulling from one source, and control what they are each allowed to pull and for whom. Then a relay is like a query server that only runs a subset of queries, which allows for query optimization.
It could get pretty wild 🤯 .
Or you could just say that relays are for relaying messages, and everything else goes in the DB. There is no serious site on the internet that operates on a one-table one-column string database, and with a limited query lanaguage, at that. It's quite amazing what has been done with such a primitive, toylike, tool. But ultimately anything serious will need proper infrastructure.
Well, yeah, but most Nostr stuff isn't serious. The Serious People have all at least looked into adding databases.
Scriptkiddies aren't going to bother worrying about query optimization, complex filters, persistent versioning, and etc.
They're just like:
1) Use AI and NDK to make a buggy javascript client
2) Post note to internet over domain only paid through for 3 months
3)
