While I admire the effort, I think it’s a mistake to build a custom db for nostr. Scuttlebuttl went down that path repeatedly and it never worked out. The reason strfry works so well is that it was the quadrable database first, then a Nostr relay second. Also nostr:npub1yxprsscnjw2e6myxz73mmzvnqw5kvzd5ffjya9ecjypc5l0gvgksh8qud4 is somebody who’s worked on databases for a long time.
Discussion
We devs like to build stuff that’s hard. The rest call it fucking around.
I think so too. Building a db is hard and I don't see the reason for such effort for something as generic as nostr.
Doug has already done all of the hard work! The design is genius and simple. The clustered key design combined with LMDB lexicographical key sorting means that pulling data out isn’t as hard as you might think.
Another benefit is compact event storage and 0 serialization overhead when getting data in and out. Damus has already switched to this flatbuffers-style format and it has fixed crashing when pulling my follower list.
The goal is that it will slowly become the engine to my native microapps, so i can have caching, querying, profile processing/lookups, negentropy syncing, parsing(?). All the stuff you need in nostr apps, but contained in a C lib i can use on desktop, android, etc.
So while its called nostrdb now, may expand into libnostr
The direction is worth exploring because current generic storage solutions are not very optimized for Nostr both in terms of performance and programming interface. Domain specific database is so underrated
we’ll see!
