Native IPFS support in web browsers

Ecosystem
1

Last year I opened and since maintain an issue on the Mozilla bug tracker, requesting a native implementation of IPFS in Firefox. Being both an user of the browser and someone who wants to help mainstream the early adoption of IPFS, I wish to see it being supported natively by at least Firefox and Chrome for the time being. What my suggestion includes:

  • A builtin version of the IPFS daemon, for users who do not have IPFS installed system wide.
  • A console or special page (eg: about:ipfs) allowing IPFS commands to be input (eg: ipfs add filename).
  • Implementation for the js-ipfs interface, allowing IPFS specific JavaScript functions to execute from websites.

You can find the issue over here:

Iā€™m mentioning this in case other users want to follow or contribute to it. Perhaps someone here is familiar with Firefox and can help make it happen soonerā€¦ or has friends over at Mozilla and may let them know to keep a closer eye on it :wink:

Other than that, feel free to share your opinion on the matter. Personally I think web browsers should at least consider experimental support for a builtin portable IPFS daemon, allowing users who donā€™t have it installed system wide to use the network without requiring extra software: This would be a major step in making the network accessible to everyone, rather than leaving in the same situation as Tor where only tech savvy folks who download and install Tor Browser get access.

5 Likes
2

Native support is the ultimate goal :+1: but there is a long road ahead.

The gist is: Browser vendors wonā€™t invest time and resources unless we need to demonstrate added value and provide a mature spec. We are working on doing just that, on multiple fronts.

Simplified roadmap/strategy to reach that goal:

  1. browser extension supports locally running go-ipfs ā† [done]
  2. browser extension works without go-ipfs (runs js-ipfs internally),
    all roadblocks in WebExtension APIs are removed, specs are written
    [we are working on all these fronts]
  3. [browser vendor recognizes the value provided by IPFS,
    IPFS stack spec is complete and browser extension is effectively a prototype of expected UX,
    vendor decides to add native support]
  4. browser supports IPFS out of the box

Some resources for anyone interested in tracking/participating in work related to IPFS in Web Browsers:

I hope this provides some context about this endeavour :slight_smile:

5 Likes
3

That is correct. At the same time, one could argue that browser developers wonā€™t have to do much of the work: As long as IPFS offers a portable version of the daemon thatā€™s easy to integrate, the browser crews arenā€™t given a lot of work other than just accepting to integrate the embedded version.

I imagine the easiest solution is for IPFS to offer this portable daemon, in a way thatā€™s easy for all browsers to both integrate as well as update. Browser releases can be packaged with the latest version of IPFS published at the timeā€¦ so if Firefox 58 were released tomorrow, and the latest version of go-ipfs is currently 0.4.13, FF 58 would come with IPFS 0.4.13 embedded.

Is js-ipfs also a reimplementation of the daemon under JavaScript, while go-ipfs is the main branch coded in C? I thought js-ipfs was there to offer specific JS functions to browsers for web script functions, but if it also offers full IPFS functionality internally thatā€™s even better! I initially thought browsers would have to launch their own ipfs.exe process in the background, which is of course less clean and desirable.

I know IPFS is still early, and it kinda pains me to remember that itā€™s not truly ready yet. For this reason, I included in a comment on the bug report two suggestions: Adding it as an experimental feature for the time being (enabled by an option in about:config) and / or adding it to experimental builds rather than the main branch for now (such as developer nightly builds).

4

Ohā€¦ no. I am quite sure this dropping-go-ipfs-in approach is not feasible due to multiple reasons related to QA and security. On top of that there is a lot of hidden complexity on the browser side we donā€™t see (code, politics). For example, if Mozilla decides to implement native support for IPFS, it will be most likely in Rust. And that is a good thing: a healthy ecosystem needs multiple native implementations.

A realistic way to provide drop-in support is via browser extension running js-ipfs (when all roadblocks are removed). Native implementation in browsers wonā€™t happen without solving this first. And it is not all black and white: in JS-based browsers such as Brave, js-ipfs will be THE native implementation. :slight_smile:

I think you were thinking about js-ipfs-api:

  • go-ipfs ā€“ IPFS implementation in Go
  • js-ipfs ā€“ IPFS implementation in JavaScript
  • js-ipfs-api ā€“ a client library for the IPFS HTTP API, implemented in JavaScript (a js-ipfs-like facade that connects to go-ipfs or js-ipfs running in Node)

js-ipfs aims to provide a full node that can interop with go-ipfs. Runs under Node and there are browser bundles, but there are limitations to what it can do when run in web browser (eg. browser canā€™t open real sockets, so it canā€™t provide real HTTP Gateway etc). A lot is still experimental. :wrench:

2 Likes
5

Got it, thanks! At first I was thinking of browsers coming with a binary blob of go-ipfs which they would launch and maintain if they didnā€™t detect ipfs.exe already running on the systemā€¦ now I feel a little ashamed for even imagining something so dirty. The common solution now seems like a version of js-ipfs compatible with all browsers, granted that JavaScript is common across every web browser out there. I understand itā€™s not as easy as that either though due to browser differencesā€¦ and like you said the more different implementations there are the better it is, which is another point I didnā€™t initially consider.

Someone further clarified me on IRC yesterday: I understand that go-ipfs is the compiled version of the daemon which comes distributed as a binary. js-ipfs instead has two modes: Either it runs its own daemon (functions as a complete alternative to go-ipfs) or connects to an existing daemon running on the system (functions as a node connecting to a go-ipfs instance on the machine). This is a clever structure, and further makes js-ipfs seem like the ideal solution for browser implementations.

6

This reminds me of something else Iā€™d like to know more about: What are the plans and approach of the IPFS Companion extension? For Firefox it can be found here:

My specific questions for the time being are:

  • Is that an official extension developed by the IPFS team?
  • Is it going to offer builtin IPFS support (no external daemon needed) for Firefox?
  • Is it going to offer builtin IPFS support (no external daemon needed) for Chromium?
  • If so, will it be possible to easily convert its code into a native implementation for browsers?
  • Is it based on js-ipfs, or will it be using different implementations for each browser?
  • Does it also offer js-ipfs-api so the browser can understand IPFS commands in page scripts?

I was told by someone that the extension now allows an internal node ran by the browser, instead of only having the ability to connect to a go-ipfs daemon running separately on the system. However this is currently only true for the Brave versionā€¦ for Firefox and Chromium this ability is still in development, but itā€™s planned and will get there soon. Is this information correct?

7

Thank you for asking good questions. This thread will be a valuable resource for the community :+1:

Is that an official extension developed by the IPFS team?

Yes. Started as community effort that got promoted to official extension last year.

Is it going to offer builtin IPFS support (no external daemon needed) for Firefox/Chrome?

That is the goal we are working towards. Not possible yet. For now you need to pair it with go-ipfs to get full functionality (eg. uploads).

If so, will it be possible to easily convert its code into a native implementation for browsers?

It is bit hard to speculate, but Iā€™d say no, apart from Brave, most vendors will choose to provide own implementation in lower level language than JS. But if that happens, they will be heavily inspired by features provided by browser extension.

Is it based on js-ipfs, or will it be using different implementations for each browser?

The goal is to have a single codebase that uses js-ipfs-api (and in future js-ipfs) internally.

Does it also offer js-ipfs-api so the browser can understand IPFS commands in page scripts?

Working on it: ipfs-companion/issues/330 :slight_smile:
But if you are a website owner you can embed it yourself via <script>:

I was told by someone that the extension now allows an internal node ran by the browser, instead of only having the ability to connect to a go-ipfs daemon running separately on the system. However this is currently only true for the Brave versionā€¦ for Firefox and Chromium this ability is still in development, but itā€™s planned and will get there soon. Is this information correct?

Correct, but I would be cautious with ā€œsoonā€, as a lot is outside of our control.
(It is hard to provide specific timeline, as we discover and solve new roadblocks along the way, and each browser vendor has distinct processes for triaging new APIs.)

We do as much we can with APIs that are available right now, then push for more. :rocket:

2 Likes
8

Thank you as well for offering great answers! This is very good information. I believe that is all I wanted to know for the time being, Iā€™ll ask more if I run into any blockages and need help.

2 Likes
9

Iā€™m happy to announce that the IPFS Companion extension has finally added support for embedded IPFS nodes via js-ipfs to the Firefox version. It now provides builtin IPFS functionality directly within the browser, with no need to run go-ipfs system wide in order to access the network. You still need to use a public gateway for the time being (https://ipfs.io/ipfs/ rather than http://127.0.0.1:8080/ipfs/) but I understand this inconvenience will also be fixed later.

Iā€™m hoping this gets us closer to a native implementation of IPFS under Firefox and Chromium, once the code becomes ready for mainstream usage and can be implemented as a default browser feature. Very excited to see how it goes.

10

A huge thank you to Mozilla for adding native support for the ipfs:// protocol in Firefox 59! While this isnā€™t a native implementation, it definitely gets us closer to that point, while in the meantime the IPFS Companion extension will have an easier time offering important features to the browser.

4 Likes