The idea is the bulk of the apps nostr logic (connections, event storage, subscriptions) are handled in a service worker so that the main rendering thread in the tabs don't lock up so much. also in theory this should be more efferent since the service worker can handle the signature verification and duplicate events from multiple relays
Discussion
Makes total sense.
What will you use for storage? IndexedDB?
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.