That could be a benefit if the client chooses to keep GBs of events in-memory. Blowater actually plans to "never" delete locally.

Many web clients still don't treat on-device storage the main storage and query from relays everytime.

I believe local-first approach is the only way to have decentralization product-wise and to have fast client tech-wise. Therefore, I like nostrdb's motivation a lot.

But what will be nostrdb's query interface? Function calls? Query languages? Can it answer questions such as what's all my notes which have been replied within 2 hours of creation? I would love to see a nostr "database" that provides graph algorithm queries.

Reply to this note

Please Login to reply.

Discussion

Right now it is just function calls (lookup profiles by pubkey, notes by id) but the plan is to full nostr query support.

Then i will eventually remove all my websocket code from damus and talk to nostrdb directly, it will become a caching/multiplexing relay of sorts. Any data it doesn’t have it can use negentropy to fetch from strfry relays. This will all be transparent under the hood so clients won’t have to deal with the complexity.

Yes! This is exactly the local-first vision. The database can synchronize with other databases and application always read/write from local.

nostrdb and nostrscript are very very powerful.

Turns the internet upside down / inside out and makes the edge some kind of exoskeleton.