
IPFS-Chromium updates: new release, IPFS-Electron, standardization
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:
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
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`:
- ipfs-ipfs-electron.linux.zip
- ipfs-ipfs-electron.win.zip
- ipfs-ipfs-electron.mac.zip
- ipfs-electron.framework.mac.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.