IPFS features in web browsers #143
Description
Introduction
The web today uses locations (URLs) almost exclusively as the resolver for content. This fails to meet user needs when content changes, websites are down, or companies close. While these constraints are features for many use cases, other use cases require content to be accessed independently of a single and/or original location. Examples are web archives for mitigating mis/disinformation, content shared across/between websites, and web applications which need to work on networks where DNS resolution is not possible.
The InterPlanetary File System (IPFS) meets these user needs in various ways depending on how and where it is implemented.
However, a common pattern is to access IPFS-addressed data via a single HTTP gateway, without verifying that the content is unmodified. This is problematic for many reasons, from privacy to data manipulation to scaling.
This is a proposal to discuss in the WICG how web browsers might integrate a subset of IPFS such that it is safe for users, aligns with the web's origin security model and does not require paradigmatic changes to browsers' HTTP-centric code base. Examples could be IPFS CIDs for SRI, Fetch integration, native addressing support, and verifiable retrieval of content-addressed resources from IPFS through multiple HTTP gateways as has been prototyped thus far, and detailed in this explainer.
The goals of incubation discussion at the WICG are:
- Identify and specify feature integration points
- Review privacy threats and solutions / mitigations
- Review security threats and solutions / mitigations
- Draft recommendations for user agent communication in user interfaces for end users
- Scope and prioritize how future IPFS features could work on the web, using more of its transport-agnostic nature for user benefit
IPFS Use Today
The IPFS DHT has ~200,000 unique peers on average at the time of this writing. There are many client-only IPFS implementations which are not represented in this number.
HTTP use of the IPFS network through gateways is not represented in the DHT. There are many IPFS gateways, large and small. Some are listed at the IPFS Public Gateway Checker. The ipfs.io and dweb.link gateways are operated by Protocol Labs, and are averaging ~1.25 million requests per day.
There are many implementations and integrations of IPFS in non-browser contexts, from support in tools like curl, ffmpeg and mpv to implementations in various programming languages and platforms.
The metrics above are all available on an ongoing basis at https://probelab.io.
Browsers and Extensions
- Chromium: Schemes are allow-listed. Deeper support in Chromium is an ongoing project by Protocol Labs, Little Bear Labs, and Igalia on everything from better non-HTTP address handling to experimental IPFS client support. Various issues filed for Chromium, blog post.
- Brave Browser: Brave has had IPFS features for many years, from bundling IPFS Companion to native address support to running a full Kubo node. See their product documentation for more on their IPFS features.
- Opera: Native IPFS address support in desktop, iOS and Android, redirected to an HTTP gateway as announced here.
- Firefox: Has allow-listed the protocol schemes for browser extensions.
- IPFS Companion: Browser extension available for Chrome (and Chromium based browsers) and Firefox, adds a suite of features to pair your browser with a locally-running IPFS node. Available in Chrome web store and Mozilla addons for Firefox.
Learn More
In the spirit of not megadumping the entire IPFS universe here, I've tried to keep this proposal concise until there's a decision about whether WICG is an appropriate venue for discussing IPFS features in web browsers or not.
If you'd like to read more about the Chromium multi-gateway verified client prototype, please read the explainer here.
If you'd like to learn more about IPFS generally, here are some places to start:
Feedback
Please provide all feedback below.