Logo
Back to perspectives
October 28, 2024From the dev desk 3 min

IPFS-Chromium updates: new release, IPFS-Electron, standardization

By John Turpish

Last year, we launched an IPFS multi-gateway experiment in Chromium, and we’ve made a lot of cool advancements since then. It’s high time for an update on how the project has evolved! 

IPFS-Chromium version 0.0.1.2 released

Recently we cut a new release of IPFS-Chromium, which has some more steps along the way to being a practical approach to native multi-trustless-gateway support for ipfs:// and ipns:// URLs.

Enhancements

Feature-control switches

For those who might consider dipping a toe rather than diving in head-first:

  • Chromium build flag ( ENABLE_IPFS ) so a codebase containing these changes can still be built without IPFS support, to ease adoption
  • A feature flag ("Enable IPFS") so Chromium built with this (and the build flag on) can still have IPFS turned off with about://flags if the user wishes

IPFS Features

There are features from some corners of the IPFS ecosystem not everyone needs, so naturally they did not get prioritized at first. Now we've implemented some more features, making things more complete:

  • Handling inline CIDs locally
  • DAG-JSON
  • DAG-CBOR
  • Support for base-16 URLs and a fix for dealing with unsupported bases (no longer crashes the process)
  • Handling of content root _redirects
  • Handling UnixFS symbolic links
  • Preview page for a sharded directory that contains no index.html. It's ugly, but usable. Here are screenshots of the top and bottom of such a page, before "Load more" is clicked:

IPFS-Chromium updates img 1.png

IPFS-Chromium updates img 2.png

Gateway interaction improvements

  • Using delegated routing gateway API to discover additional gateways
  • Partial (dag-scope=entity) CAR requests for fetching multiple blocks in one round trip
  • Support for the environment variable IPFS_GATEWAY, though this project supports a superset: it's a whitespace-delimited list of gateways instead of just one
  • Gateway rate (soft) limits persisted to user preferences
  • Option to fallback to gateway for DNSLink-like roots. Helps when there's a DNS problem or if you need a resolver your system doesn't use but the gateway does, like ENS

Browser features

  • Some response headers for use in devtools, including some Server-Timing keys
  • Cache entries for IPNS records expire based on the date contained in the record
  • Proper URL canonicalization for IPFS URLs (switching multibase) so that it survives lowercasing
  • Some user preferences where performance trades off against privacy concerns:
    • Controlling whether the Routing V1 API is used to discover additional gateways (and if so, whether http:// (insecure) gateways are included)
    • Whether DNSLink can fallback to gateway resolution when DNSClient is unavailable or unsuccessful (but requires trusting your gateways to resolve honestly)

Dev & maintenance updates

The basics. They always gotta get done.

  • Explicit licensing for ipfs-client (it's dual MIT/Apache)
  • Doxygen documentation
  • Various refactors in the ipfs-client library
  • Patches for new versions of Chromium
  • CI for library artifacts in releases (see ipfs-client* here)
  • A bug fix in default URL escaping of ipfs::Client (not in Chromium)

IPFS-Electron

IPFS-Chromium updates img 3.png

While it may be unlikely to get IPFS support in vanilla Electron by default, there are a number of use cases for slightly modified spins on Electron, and if we get those extension points, IPFS-enabled Electron could be one.

And with that in mind, this repo now builds an IPFS-enabled electron as well, if you're using this fork of Electron rather than the upstream where the extension points are not yet adopted.

You can find some build artifacts in the release if you'd like to give it a try without building it yourself. In particular, one could download the equivalent of `dist.zip`:

WICG discussion

The very beginning of a discussion about standardizing IPFS functionality in browsers, of which this would be one implementation, has been started over here.

Naturally, the suggestion isn't to adopt everything we've done here exactly as-is, but to look for a reasonable subset of functionality that would give a good level of interoperability. Feel free to read the explainer on what we arrived at and join in the discussion.

Next steps: share your thoughts!

The future is yet to be written. Where in the ecosystem would you like to see native support for multi-gateway IPFS clients?

Feel free to comment on the WICG ticket for comment on web standardization, the Chromium ticket, the Electron ticket, or open an issue on IPFS-Chromium for your own ideas & concerns.

John Turpish
John TurpishSenior Backend Engineer, Little Bear LabsLinkedIn

John's a dev who likes to build to last; most known for his work in native-compiling languages like Rust & C++. Dive deep or collaborate: why not both?


More perspectives