Epic: WebExtension with pluggable IPFS nodes

[flyingzumwalt]

Break up the functionality that #12 is aiming for.

[flyingzumwalt]

How we're going to break it up (will make issues):

General notes:

• use web extension (works on chrome and firefox)
• There is already an ipfs-station chrome extension that does some of this: https://chrome.google.com/webstore/detail/ipfs-station/kckhgoigikkadogfdiojcblegfhdnjei?brand=CHBD&gclid=CIiYzM7SktICFZORGwodX8MKFw

Stories:

• A) Web Extension runs a local node and redirects IPFS urls to the gateway
  • A1) Web Extension runs a local go-IPFS node and redirects IPFS urls to the gateway #11:
    • downloads and installs go-ipfs
      • runs the go-ipfs daemon (given path to binary)
      • (Expands on the extensions that were already available by downloading the binary)
    • bundles js-ipfs by default
  • A2) IPFS node info and node controls #12 use station to show info on the IPFS icon in OS menu bar
    * requires re-packaging station as a web extension
  • A3) Web Extension allows choice of daemon: go-ipfs or js-ipfs #40 allow choice of daemon: go-ipfs or js-ipfs -- default to go-ipfs because js-ipfs doesn't support dht lookup yet
• B) WebExtension makes **go-ipfs** full ipfs core api (interface-core-api) available in the browser #41 WebExtension makes go-ipfs protocol (interface-core-api) available in the browser through window.ipfs
  • uses js-ipfs-api to talk with the node
• C) Expose IPFS Core API as window.ipfs #42 Web Extension makes js-ipfs protocol (interface-core-api) available in the browser through window.ipfs
  • creates an instance of js-ipfs inside the extension
  • exposes that instance directly in window.ipfs
  • this will expose the same API as b), since both implement interface-ipfs-core

If A is completely done, B and C can be activated with a toggle -- Redirect-URLs can be true or false

[flyingzumwalt]

See #43 for a discussion of the security implications of this web extension.

[victorb]

I've did some quick research after thinking that probably we can't expose anything on window from an web extension to a web page. And yeah, we can't just add whatever we want to a page's window object.

What we can do is to setup some message passing and provide a library for websites to use that.

But, we won't be able to have an extension that people can simply install and now window.ipfs exists everywhere as a full node... There will have to be things that the website authors needs to do.

[Kubuxu]

We for sure can add an element that could load a script and then use some sort of RPC (or ipfs api) to pass the messages.

Just an idea.

[victorb]

@Kubuxu you won't be able to load arbitrary scripts into the same context of a web page. CSP will deny that and it would be a security threat otherwise.

This RPC/ipfs-api you're talking about, is a possibility, but the website authors needs themselves to include this in their webpage. That's not what we're aiming for, but rather be able to provide everything so a user could simply do window.ipfs.swarm.peers(cb) without any further fuzz.

[Kubuxu]

Can't you modify the webpage as it is loaded to include inline script block that would contain the script necessary to expose the bindings?

[Kubuxu]

Also I have found this: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts

[victorb]

@Kubuxu as far as my testing went, no. The browser rejects to execute any code that has been injected into the page. I can successfully run a js-ipfs node in the background page, and communicate with it via a content script, but can't expose a API for the communication...

[Kubuxu]

I can successfully run a js-ipfs node in the background page, and communicate with it via a content script, but can't expose a API for the communication...

I don't understand the "but can't expose a API for the communication..." part.

[victorb]

Yeah, what I did was setting up a background page that has the daemon running and exposes a couple of methods via message passing.

In the content script, I can successfully add properties to the window object of a page. I can also talk with the background ipfs daemon without troubles.

Problems arise when I wanted to write a thin-layer of API methods that the users can use directly from their page. I'm adding functions to a IPFS object that acts kind of like js-ipfs-api, but the browser won't execute those functions, since they were added from the outside.

I've made the code public here: https://github.com/VictorBjelkholm/js-ipfs-in-the-browser

Content-Script: https://github.com/VictorBjelkholm/js-ipfs-in-the-browser/blob/master/page-script.js
Background-Script: https://github.com/VictorBjelkholm/js-ipfs-in-the-browser/blob/master/start-daemon.js

I don't understand the "but can't expose a API for the communication..." part.

We can't have window.ipfs that just works. Users are required to include something for the communication to the daemon...

[Kubuxu]

I think we need to use cloneInto as it is shown here: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#cloneInto

[flyingzumwalt]

Maybe it's a bad idea for the extension to initialize window.ipfs anyway. Wouldn't it be better if we allow web pages to initialize that with a very small amount of code -- so the browser extension provides the whole ipfs stack and a web developer just has to initialize the connection wherever they see fit?

Either way, any page that wants to use ipfs is going to have to run a script to check if the extension is installed, so we will need to provide an easy way to do the following (and should provide an npm module that does it for you):

1. Check if the ipfs web extension is installed
2. Initialize ipfs
   2a. If the web extension is installed, just initialize the connection
   2b. If the web extension is not installed, download ipfs and then initialize

Given that, is it really necessary for the web extension to initialize window.ipfs?

[victorb]

We wanted to simulate an environment which would be as similar as possible to when we actually have ipfs supported natively in the browsers. We could do bunch of guesses how that would look, but probably there would be an node of some sort exposed at window.ipfs. It's straight-forward to check if it exists.

if (window.ipfs === undefined) {
 // ipfs is not here, we need to have a polyfill
} else {
 // ipfs was on the page already!
}

This is also how new features are being detected in browsers, and polyfill if necessary...

I think something that is missed, is the performance gain of having an already initialized node as well. Currently, js-ipfs when starting up in the browser, locks my browser for half a second and takes a while to find peers.

If we could run the node always, and allow pages to directly connect to it, we'll have no startup time + already connected peers when the page first loads.

[flyingzumwalt]

Those are all good points. Thanks for clarifying.

[jmc265]

Potential solution for the issue around content scripts not being able to affect the page script's window object:

From the content script, inject a script ('js-ipfs-bridge.js') into the page (using the method detailed here: https://gist.github.com/nok/a98c7c5ce0d0803b42da50c4b901ef84).

'js-ipfs-bridge.js' can then define a window.ipfs shim which just uses window.postMessage to communicate back and forth between the page scripts and the content scripts.

This means that developers can just go ahead and use window.ipfs unaware that the extension has re-mapped that object to the extension's content and background scripts via postMessage.

[daviddias]

All the extension work is happening here https://github.com/ipfs/ipfs-companion