Because you are trying too hard to solve the wrong problems, sometimes. Y'all are having a dick-measuring contest about the speed and the size of your DB 🙄.
But I just want something that works with 1 bar or no bar, on the train. And that works with my e-paper reader and doesn't drain my battery. And that has an intuitive, uncluttered, feature-rich design.
So, that's what I'm building. And it's pretty cool. Land makes it cooler, but it's cool without, too.
Nostr, but 💗 pink and with ✨ sparkles.
Okay so excuse me, you are trying to put this on a server, someone’s desktop, a phone, or on an e-reader?
Server? NFDB obviously.
Browser? IndexedDB + https://git.v0l.io/Kieran/snort/src/branch/main/packages/worker-relay (which can store more)
Desktop app? NostrDB with calls from your favorite C or Rust binding. No IPC or websockets required. Could maybe use nostr-relay-tray as well.
Mobile app? NostrDB.
An e-reader? Just SQLite. Keep it simple, and have an *application focused cache*. You don't need to store every event raw.
But you can store what you know the latest version of a book is, download it, or whatever.
Best tool for the job.
"Y'all are having a dick-measuring contest about the speed and the size of your DB 🙄." I laughed there because that is mostly true. Many relay devs are focusing on who can do it faster or whatever. But also, if it can't store a TB of books, is it really going to be able to handle when Nostr actually becomes big?
With NFDB, one of the core focus has been usability. Many features on nostr.land are only possible because NFDB is easy to use and has a bunch of features most devs do not need but are absolutely required in large-scale relays.
The performance and reliability are just there so I can offer more without it costing as much as an AWS bill. :)
They all solve different problems. Realy/strfry are good for small-medium scale but are basically one-trick ponies and require a special proxy layer on top to do anything. (and then eventually that isn't enough either)
NFDB tries
NostrDB is good for small-scale local caches because it builds indexes of profiles and other "important" data.
Custom solutions can do a lot more with less though. Think for a day, what does my app need, and make a database schema. Cache what you actually care about that way and it'll do better than any cache relay.
None of this is for Alexandria. Different project, entirely. No large documents, at all.
Use custom DB schems
I am. 😂
You do realize that I test large database for a living, right?
Then why are you bothering about cache relays?
You'll see. 😁
I think it may be best to think about the cache relays once the app actually exists
All other apps have been built front-to-back, so I'm trying something different.
You can think whatever you want. It's a free protocol. 🤙🏻
You can, nothing wrong there.
Also, I’m planning on making a binary protocol for NFDB relays. Almost identical to JSON but with less data usage and may have some additional support for semantic search features
My personal opinion is leave it as a stub until you get there. Think about it a bit, design the code so it can be added, but until you get there don’t bother
