Adding IPFS Protocol Support to Chromium

Adding IPFS Protocol Support to Chromium

Protocol Labs and Igalia are pleased to announce a major milestone in our efforts to bring more extensibility and user agency to the web and to browsers:

Support for pre-defined custom protocol handlers in Chromium!

... ummm, what does that even mean? And why should you care?

In short: You can now build Chromium - the open source browser code used for Chrome, Brave, Edge, Opera and more - with support for "ipfs://" addresses by changing only a couple of lines of code.

Read on to learn why this is a key step towards browsers that can meet a far more diverse set of user needs while maintaining an interoperable core.

# Igalia and Protocol Labs

Igalia (opens new window) has been working on improving the web for over 20 years. They're an open source consultancy who participate in web standards and work on Chromium, Webkit and Gecko - the three primary web platform rendering engines.

In 2019, we set up a contract with Igalia to work on web platform features and compatibility fixes to make life easier for decentralized web projects and deployment topologies where the browser interacted with services residing on the same computer.

This colloboration covered a lot of ground - from IANA to WHAT-WG to W3C to IETF to negotiation and coordination with Apple, Google and Mozilla... resulting in a slew of changes catalogued in this blog post (opens new window) in 2021.

Very few changes were specific to IPFS. A lot of the work was making browsers and the web platform more amenable to localhost-oriented application topologies and non-HTTP protocol work - fixing compat papercuts, aligning security models across engines, cleaning up dusty corners... making the web itself just a little bit better.

But our larger goal is to bring the web to places where it doesn't work well for people today, and enable experimentation in what a web with alternative protocols can look like. These are paradigmatic changes, so we needed to do more than just surface-level fixes.

# IPFS Browser Integrations So Far

IPFS has achieved a signficant amount of support in various ways across a number of browsers, from extensions to different levels of built-in support in Brave and Opera, to experiments with mobile operating systems. Looking back at the IPFS browser update from 2019 (opens new window), the world looks very different:

There's interest and opportunities and challenges in various browsers - lots of accomplishments, but lots still to figure out.

Table of browsers and levels of IPFS support

Some notes on the table above:

# Native Integration

Redirecting ipfs and ipns to an HTTP gateway is just a step along the road to a truly native integration of IPFS into the web platform. It's not ideal for a number of reasons, but does align with the HTTP-centric nature of the web today, which makes it a relatively simple integration. But without support for non-HTTP protocols in web browser cores, Opera and Brave both had to do custom work in their products to add even this level of integration - which is costly and complex.

If the underlying engine - Chromium - supported non-HTTP protocols better as a built-in feature, then embedders (Chromium lingo for products building on top of it) could more easily integrate and experiment, and we could spend more time working on what truly native IPFS support might look like in the web platform, instead of just redirecting to an HTTP gateway. Igalia agreed it was a worthy goal, and the feedback from the Chromium commmunity around the work was positive, so off we went.

A flow diagram of the refactored flow for addresses across process boundaries.

# Major Chromium Refactor

Javi Fernandez of Igalia spent most of the last year refactoring epically large and senstive parts of the Chromium codebase to support non-HTTP addresses across the multiprocess architecture of this massive application. After many stages of work involving code reviews from a huge number of engineers in the Chromium community, Javi made the pre-defined handler approach so simple that embedders now can add a simple redirect integration of IPFS in two lines of code added to the ChromeContentClient::AddAdditionalSchemes method (opens new window):

"ipfs", "");

"ipns", "");

He has detailed the new architecture in a couple of posts:

And recently at IPFS Camp in Lisbon Portugal, Javi gave a talk about this work - which you can watch here:

If you're interested in learning more, join the #browsers-and-platforms channel on the Filecoin Slack (opens new window), which is bridged also to #browsers-and-standards on Matrix (opens new window) and the IPFS Discord (opens new window).