Nostr transmits notes and other stuff over relays. This is good. However developers are using nostr as a database. While, yes, you get a sugar-rush by doing so, this is non-optimal for several reasons:

- the content is only one field which is a text string, that is not easy to work with

- meta data is added to the content, but it is often misused

- the query languages is incredibly basic, worse that what existed in the 70s

- the database indexes are permissioned and centralized, it can take a year or to get approval to use an index

- a small number of developers get approval almost immediatly, the vast majority of innovation is kicked into the long grass

- the meta data violates basic computer science ideas of Entity-Attribute-value and has hard to work with array lists

- it is well-known for decades that connection-oriented networks dont scale

- the kinds (ie types) are rationed out by a central authority and no more than 100 are alloed

- entries such as profile are centralized, for example you are allowed one website, to do something like adding a 2nd website would be a multi-year project

- follower counts have to be added manually, so if you have a large number of follows then its impractical to make a query

This is not bad, because is shows that nostr can improve in many ways. But the first step is to acknowledge the limitations, before any of it can be fixed. Improving the devX would allow nostr to grow many OOMs.

Reply to this note

Please Login to reply.

Discussion

What a weird list of some inflammatory, some incorrect and some confusing takes to build an argument against devs using Nostr as a database.

What’s incorrect , inflammatory and confusing? This is a weird response

Some things are right, others debatable and others plain wrong

Lol, you and nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z are not making me learn much here 😜.

Would live to know what the limits are for nostr's database use case. If there are any.

*love

I think the main points that nostr:nprofile1qqsdulkdrc5hdf4dktl6taxmsxnasykghdnf32sqmnc7w6km2hhav3gppemhxue69uhkummn9ekx7mp0qywhwumn8ghj7mn0wd68ytfsxyhxymmvwshx7cnnv4e8vetj9uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qmml2f somewhat missed is that there is no SQL for Nostr relays and there is, currently, no easy replication scheme to support load balancing, especially for geo-distributed semi-mirrored servers.

Relays ARE databases in the sense they store stuff, but if you need advanced querying capability OR if your events are too big (binary or text) or has too many tags (too many indexes), the relay operator might not be able to support it and might either reject it or become super slow.

The lack of a query language is a limit we are forcing on ourselves. The rest is pretty much solvable with the usual enterprise stack without changing the protocol.

By "the rest" you mean the "other stuff"? I certainly do not want to fall on the usual enterprise stack to make my other stuff client work

The relay operator is free to reject a request or charge for it

I don't think this is optional for non-personal relays. They will have to grow up to use thousands of servers if they want to serve users globally.

The Client won't even know if it is an enterprise stack or not. It will just use the same interface we have today.

I can have a relay backed by a thousand servers, but that does not solve the issues of bandwidth and client-side processing

True, bandwidth will always be high on Nostr. But Negentropy can help. Clients most likely will have to have a local relay to sync to and work with directly. And some of the Client-side processing will never be possible to solve, like like a true WoT with graph analysis.

I need to find latest releases for apps given a set of app ids and this query is complex. Syncing hundreds of thousands of releases to a local relay is not viable.

We are going to end up with more custom query languages and ad-hoc external services just because we're stubborn to address the query language issue. I'm not saying massive processing like WoT - but stuff that is trivial for SQLite to handle

Sql works with indexes, without them it won't help. To add proper index you add single letter tag. If you want joins then all you are asking is for relay to bear the weight for you. Just denormalize your data, add a tag, and make life easy for both sides

Thanks. Data is denormalized already so no joins. That is not enough. Yes, I'm happy to ask the relay to bear the weight for me.

I need the latest of each. Limit obviously does not help as it applies to the whole result set. Not using any sort of limit is unviable as I would get too many events

Maybe each app can link to it's latest release?

Yes they are linked already.

My request is: Give me the latest release for each one of these app ids. In SQL that can be done with a self-join I think

So you load apps and then latest releases by id?

I need to check for updates: for (com.app1, com.app2, com.app3) give me the latest 1063 events for each.

I could use one query for each, but since a user might be checking for 50-100 apps I don't want to do that.

Is com1 linking to latest release?

Assume that appid is in a tag in the release itself.

But don't worry, I'll figure it out

Thank you! πŸ«‚

So there's an index and no joins so what's complex there?

It's not really a database. Developers think it is, and that's the problem. Nostr is a relay system. If you let nostr be nostr, you have a very powerful tool. If you try and use nostr for things it wasnt designed to do, you will have an inferior solution. This is basic computer science.

Strawman alert. If some things are right, we have a problem. Fixing problems fixes nostr.

i can tell you really want nostr to succeed!!