Client: Cache app frontend using service workers to avoid loading from IPFS on every load

[luisivan]

Not sure how this would play out if using IPFS, but it'd be recomendable to use Service Workers to cache the dapp so it can work while fully offline

[harshjv]

Yep. Can be done using cache manifest file.

[izqui]

Are we doing this for v0.4? If so please label and milestone it :)

[commiteth]

Current balance: 0.00000000
Contract address: 0xd73982a5760f9e54b66506fb5b004cb7e93886a7

Network: Mainnet
To claim this bounty sign up at https://commiteth.com

[luisivan]

Let's postpone to 0.5 @izqui @harshjv. We should serve our own dapp as a code package using #19, so it's blocked until #19 is ready

[kdichev]

I can take this if still a viable issue?

[yjkimjunior]

Is this still blocked?

[sohkai]

Kind of—we haven't thought too hard on this and 0.5's frontend is still being finished. Pieces are moving around, but caching the entire dapp's frontend should be fairly trivial with service workers using normal resolving strategies.

However, it'd be great to report back any thoughts on doing this when a dapp is served via an IPFS gateway. I assume it's trivial since the cache will just hold hashes as its keys, but maybe there's some hidden complexity?

[sohkai]

Something really interesting that came out of a discussion: we could cache all asset requests made by apps if we could somehow register a top-level service worker that is inherited by the sandboxed iframe context. This top-level service worker would be able to sniff all network traffic coming from the iframe, as well its own context (the Aragon client). It would detect any IPFS content (which has the great cache property of never needing to be invalidated), and cache it.

Going by the selection algorithm of service workers, it looks like this would only be possible if we made blob URLs for the apps' start_url, rather than loading them through HTTP via a gateway (if it was through a gateway, there would be an origin mismatch). It does not look like the origin sandbox is considered in the algorithm, but this needs to be verified via testing.

We already load blob URLs for the apps' scripts, out of technical details, but I also originally chose to just load the apps' frontends through HTTP via a gateway because it would otherwise be impossible to load relative assets. However, this would also be nicely solved via a service worker, since we could reconstruct any relative asset with the IPFS context of its parent and fetch it through a gateway if it wasn't already cached.

The tricky part with reconstructing the relative asset's IPFS context is in getting enough information into the service worker to reliably tell from which app a relative request came from. A number of potential options, depending on the information we get on fetchEvent():

• Build the blob URL in the window context, and use the CacheStorage API, which is available to both the window and service worker contexts, to store the mapping between an app's IPFS context and its start_url blob (see inspiration)
• Build and return the blob URL in the service worker so it can create the mapping between an app's blog URL and its IPFS context itself

---

Assuming all the above works out, having caching of this level would mean you would really be "installing" these apps into your browser, and next loads would never even have to go to network for assets.

[sohkai]

Going to close this for now; we will not be focusing on performance improvements with service workers in the near term (especially given technical difficulties).