window.ipfs loading script from external CDN

[victorb]

Currently, if window.ipfs can't be found, we load ipfs-api from unpkg (https://github.com/ipfs-shipyard/ipfs-companion/blob/50db9c08d5bf0e5297981ff474da07585aa8a8ce/docs/examples/window.ipfs-fallback.html#L21). Rather than trusting unpkg, we could bundle ipfs-api in the extension and serve it from the extension (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/web_accessible_resources)

This will enable ipfs-companion to load ipfs-api even if internet is not accessible and faster even if internet access is present.

[alanshaw]

I looked at this and thought the only reason window.ipfs wouldn't be available would be if the extension isn't installed (we still have to add window.ipfs even if the user has disabled all access to it due to us being unable to inject a content script programmatically before any other scripts run on the page).

In which case, there'd be no point doing this.

Looking at the code ipfs is not added to the window object if not in a secure context, so in this case it it could work.

It's tricky though because the page would have to somehow know ipfs-companion was installed (is there even a way?) and what the web extension URL was? I guess we could add a different property to the window with that URL?

Another idea - what if we intercept the unpkg URL and serve a local resource?

[lidel]

(Another use case: user explicitly disabled window.ipfs in Preferences.)

I agree, intercept&redirect is the way to do this.
I am not sure if we want to bundle a single version with Companion. Instead, we could keep a list of IPFS CIDs for multiple unkpkg URLs and redirect to IPFS versions on exact match.

Also, we should move away from things like unpkg and start including URLs to IPFS versions in release notes of js-ipfs and js-ipfs-api.

---

Update: created "Intercept URLs for JS libs at public CDNs": #674

[lidel]

Closing due to #589 (comment)