Makes total sense.

What will you use for storage? IndexedDB?

Reply to this note

Please Login to reply.

Discussion

IndexedDB is the reason I'm looking to make multiple threads. getting sick of it freezing the main thread. but its built-in to all browsers so it makes sense to use it as a default

Then maybe have an option to detect and use the local nostr-relay-tray or a SQLite WASM database

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.

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?

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.