nostr:nprofile1qy28wumn8ghj7un9d3shjctzd3jjummjvuhsz9nhwden5te0wfjkccte9ekk7um5wgh8qatz9uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgswaehxw309ahx7um5wghx6mmd9uqzq6xcz9jerqgqkldy8lpg7lglcyj4g3nwzy2cs6u70wejdaj7csnjkyfw8d I only took a quick look, but am I reading nostr-database correctly that it does its own in-memory indexing of all known events in memory, regardless of backend?
If yes, was that intentional, or just a first pass implementation? (Seems weird to not utilize DB-native indexes where available, unless they turned out to be too slow)
It's intentional. Using in-memory indexes remove some work to me. But in the long term it will probably be replaced with DB-native indexes.
I not done tests/benches with native indexes yet, but indexeddb (the db for the browser), in general, it's slow... so in-memory indexes help a bit.
Makes sense, I'm targeting native first so sqlite is what I'm interested in.
Right now my nostr app is a side-project-for-when-my-real-side-project-is-annoying-me so it'll probably be a long time before I get around to it, BUT if you don't beat me to it, I'll provide some benchmarks for sqlite at least.
