Nostr Web Client

I'd be curious to see performance benchmarks between IndexedDB and SQLite WASM.

You'll have to use shared workers pretty heavily, but that gives true parallel processing across tabs, rather than just concurrent work on a single OS thread.

hzrd149 3w ago 💬 1

The issue with IndexedDB is the indexes... Ironically when you insert data into stores with 5+ indexes it waits till the first read to compute the indexes, at which point it freezes the tab for 20+ seconds (on a good machine). Its usable with <5k rows but anything more than 10k rows and things start to really slow down

SQLite in WASM is much more reliable as long as you can handle the shutdown and parallel tabs correct so it does not corrupt the database. the biggest hurdle to get it running is enabling OPFS for the app and loading the 2Mb+ wasm file

And finally, the best way I've found to store events is to just use the users local relay (nostr-relay-tray) ws://localhost:4869 if it exists. usually so much faster and can hold 1 million+ events. I built https://github.com/hzrd149/window.nostrdb.js a while back so that smaller nostr apps could easily connect to the local relay without needing to think about it

Either way, if its possible to put the local event cache in a separate thread and reuse that thread between tabs then that really allows apps to play with new ways of loading and caching data. maybe even remote event cache on another machine?

Reply to this note

Please Login to reply.

Discussion

MichaelJ 3w ago

Yeah initial WASM downloads are a kicker; though once you cache the download (like with a Service Worker) it should be a one-and-done thing.

I've been seeing SQLite+WASM-powered web apps and web apps boosted by the local relay tray as two sides of the "edge".

Bring compute and storage down to the end-user's device either ad hoc with WASM in the browser or more intentionally by asking them to download an app. Either way it decentralizes compute almost as far as possible.