Expose IPFS API as window.ipfs

[lidel]

There is an area of interest that can be summarized as..

..exposing a subset of IPFS APIs as window.ipfs on every webpage ✨

tl;dr If we have it, websites could detect that window.ipfs already exists and use it instead of spawning own js-ipfs node (saves resources, battery etc).

We had discussions in ipfs-inactive/js-ipfs-http-client#387 and #37, ipfs/in-web-browsers#9, ipfs/in-web-browsers#35 but the consensus at the time was that it is not safe without some kind of access-control (eg. via proposed API Tokens: ipfs/kubo#1532).

@victorbjelkholm suggested a simple solution to the lack of access controls in the API itself:
On the first use of window.ipfs user could be prompted with something like "Do you want to allow scripts at <website> to access API of your IPFS node?". The choice would be remembered eg. for the page til the end of browsing session. There could also be an additional "remember for this site" checkbox to make UX better for users who wants to make permission persist between browser restarts.

Tasks

• Create a content script that creates a proxy object under window.ipfs of the page it is injected into
  • This object should expose a subset of IPFS APIs

    <victorbjelkholm> there is of course a lot more once there is a full ipfs node in the browser, but if we only have the simplest and most useful functions (add, cat, pubsub subscribe/publish, dag get/put), it suddenly becomes a lot simpler and useful quickly

  • Operations performed on window.ipfs should be proxied to the real IPFS API object present in webextension's Background page (requires robust (de)serialization, we don't want to mangle upload data etc)
  • First use of window.ipfs should trigger a dialog where user confirms that access to IPFS API is granted to requesting site (and decides if permission is for this session only or permanent)
• Add a checkbox under "Preferences/Experiments" to control if content script is injected to every visited page, make it disabled by default initially
• Write documentation, namely provide code snippet that enables apps to use the IPFS Companion IPFS node if it is available

Potential problems

• Something to investigate and solve before we make window.ipfs enabled by default: make sure it is not possible for a website to approve itself 🙃 This may mean we can't inject dialog to the tab itself and the dialog needs to be displayed in a new Tab or via other means.

[victorb]

I've made two PoCs on this concept. One was separate and you can see it here: https://github.com/victorbjelkholm/js-ipfs-in-the-browser

The other one was a recent try to integrate that work into ipfs-companion and fix the stream issue in .cat, but didn't get really far yet: 6b0ac8b

suggested a simple solution to the lack of access controls in the API itself:
On the first use of window.ipfs user could be prompted with something like

I don't think that's good enough. I think (judging only five different methods) that the functions themselves should trigger the permission dialog (all with a "remember for this site" checkbox)

• ipfs.id would trigger a "website would like to know your ID" prompt
• ipfs.cat would trigger a "website would like to get content from the IPFS network via you or content in your local node" prompt
• ipfs.pubsub.subscribe would trigger a "website would like to read messages from a pubsub channel via you"
• ipfs.pubsub.publish would trigger a "website would like to send messages as you"

[victorb]

make sure it is not possible for a website to approve itself

Should not be possible if we store the state in the extensions storage.

This may mean we can't inject dialog to the tab itself and the dialog needs to be displayed in a new Tab or via other means.

We absolutely should not inject the dialog into the page itself, or via a new tab but rather use the popup that ipfs-companion provides. Take a look at how MetaMask deals with confirmation when you do a transaction.

[lidel]

@victorbjelkholm thanks, great points!

For future reference, metamask webextension:
https://github.com/MetaMask/metamask-extension/tree/master/app

[daviddias]

@lidel can a quick experiment to let users access window.ipfs after enabling a flag on the settings pane? @joaosantos15 would really appreciate this.

@joaosantos15, perhaps you can grab @victorbjelkholm PoC and submit a PR to station?

[olizilla]

@diasdavid there is some very early wip for that here #333

It's building on the ideas in https://github.com/victorbjelkholm/js-ipfs-in-the-browser
adding window.ipfs as a proxy to a ipfs instance running in ipfs-companion. Only ipfs.id() implemented so far... there are a lot of hurdles to jump through to make it work.

[lidel]

Just like @diasdavid suggested, we can work on PR #333 as an experiment that is disabled by default (another checkbox in Preferences 🙃 ). I feel that as long it is an "opt-in experiment" we can ship it as a crude PoC, even without authorization GUI (although it may not be the hardest part, as noted in #333 (review)).

[daviddias]

Thanks @lidel @olizilla. Yes, shipping it as an opt-in would enable @joaosantos15 use case for now, that would help a ton :)

[olizilla]

@diasdavid @joaosantos15 out of interest, what is the use case?

[daviddias]

glad you asked :) it is for @joaosantos15 thesis -> ipfs/notes#268 & https://github.com/inesc-id/hypercerts