field-manual
field-manual copied to clipboard
orbitdb
Service Worker
I'm interested in making OrbitDB work in a Web Service Worker. This way:
- It would be in a different thread than the UI.
- One instance serves multiple tabs.
- It could redirect HTTP traffic so that you can respond with content in the database.
When I tried it briefly, I found that localStorage is not defined in the scope of the a Service Worker. I tried a hack of defining it myself, but ran into other issues and haven't returned. Has anyone else looked into this?
I think the transition could be painless from an API perspective since most calls are asynchronous you could just make them RPC's to the Service Worker.
+1 to this. Apart from service worker, it's great to run IPFS in workers, and it'd be great to run OrbitDB in a worker as well
For now, Service Workers are not like this. They always stop and start, you can't rely on them for doing long tasks.
I recommend you to read the following (about ServiceWorkers lifecycle) https://developers.google.com/web/fundamentals/primers/service-workers/
I already tried putting an IPFS node on a service worker, it was very difficult and the result was a slowwwwww IPFS node always restarting, and rarely available to respond to requests or listen for PubSub messages.
Because they're not made for such kind of tasks.
You should rather open a popup window that runs an IPFS/OrbitDB node and tell the user to keep it open.
the js-ipfs site has an enable service worker function, so they are definitely pushing it.
But apart from that, making IPFS and OrbitDB run on a Web Worker will be extremely helpful for performance. OrbitDB is the blocker on this, and just by moving from localStorage to IndexedDB on the keychain should be enough to support this. Service Worker is just one kind of Worker
OrbitDB in a separate thread in a web worker is very compelling. You;d have to use messages heavily for computation but its certainly possible!
I'm currently working with AssemblyScript to use WebAssembly and atomic memories to have faster web worker communication.
I'lve also been working on OrbitFS, which uses a mutable filesystem from IPFS and then commits root hashes to orbitdb. So in that system you'd only need to use orbitdb with bigger updates.
@willemneal do you want to show this at the next community call on March 5?
@aphelionz I would like to, but it's not quite ready for demoing. But perhaps the next one. When is it?
They're every two weeks on Tuesday morning EST. Info is posted as issues in this repo. For example: https://github.com/orbitdb/welcome/issues/51
Hey, I'm using orbitDB inside an iframe with some strict sandbox security requirements https://github.com/aragon/aragon/issues/702
If we ran orbit in a service worker, do people think this would solve the above issue as well? If not, do people see any alternatives to getting orbit to work in an iframe besides loosening sandbox restrictions? Thanks for any help!
I'm running orbitDB in an iframe, but the storage is taken care of from the domain itself, not from the page that loads the iframe, so it stores it in the specific indexeddb instance for that domain.
Do you want all your aragon apps which are in different iframe to access the indexeddb storage of the domain that loads those iframes? Maybe you can set up some kind of post message communication for that, but using workers won't be an option as they're domain specific as well I believe