Contact emailsjo...@littlebearlabs.io (primary)
jfern...@igalia.comdiet...@protocol.aiExplainerhttps://github.com/little-bear-labs/ipfs-chromium/blob/main/doc/explainer.mdSpecificationMultiple specs are relevant. The most important is:
https://specs.ipfs.tech/http-gateways/trustless-gateway/Some others:
https://github.com/ipfs/specs/blob/main/UNIXFS.mdhttps://specs.ipfs.tech/ipns/ipns-record/https://specs.ipfs.tech/routing/http-routing-v1/https://specs.ipfs.tech/http-gateways/web-redirects-file/SummaryIPFS is content-addressed networking.
https://en.wikipedia.org/wiki/InterPlanetary_File_SystemThe goal of this effort is to add effective/useful support for 3 styles of URLs to Chromium:
ipfs://<CID>/path
ipns://<name/key>/path
ipns://<hostname with appropriate TXT record>/path
The plan is to use a multi-gateway trustless approach.
Blink componentBlink>NetworkMotivationWeb rendering engines today currently do not offer a way to retrieve and render content that is
1) verifiable at the data layer nor
2) available across origins.
Both of these features are aspects of a more resilient web than HTTP alone can provide - and which are both available in the Interplanetary FileSystem (IPFS) protocol.
However, as IPFS is not directly compatible with HTTP nor the origin security model, it must be implemented as a separate protocol in order to deliver these features, and also to communicate to the user this different model, and adequately manage user expectations.
This feature provides an HTTP-based approach to retrieving cryptographically verifiable content from an interchangeable pool of servers providing access to content over the IPFS public network.
Initial public proposalhttps://groups.google.com/a/chromium.org/g/chromium-dev/c/kmmrpDWfF90/m/96HvP5QUBwAJTAG reviewTAG review statusNone yet
RisksFor users not making use of IPFS, fairly minimal as most of the code would be inactive for them.
It may be difficult or even impossible to fully protect URL canonicalization changes with a feature flag.
This protocol changes how people think about origins, which may raise same-origin security concerns.
The model is near-identical to the one used on subdomain gateways, so some relevant discussion appears in these pages.
https://specs.ipfs.tech/http-gateways/subdomain-gateway/https://docs.ipfs.tech/how-to/address-ipfs-on-web/#subdomain-gatewayThere could be concerns around impact on caching, or misunderstandings of the gateway settings.
Interoperability and CompatibilityHere are some of the attempts at supporting IPFS in web browsers:
https://github.com/ipfs/in-web-browsers/blob/master/README.md#current-projectsSome support in other web-related tools (ffmpeg, curl):
https://github.com/ipfs/integrations/blob/main/README.md#completed-integrationsWebView application risksNo
DebuggabilityWe intend to add IPFS-specific functionality to DevTools.
The POC's current approach (adding headers to the aggregate internal response for debugging's sake) might raise concerns and may be dropped entirely.
Is this feature fully tested by web-platform-tests?Not yet.
Flag name"enable-ipfs" / url::kEnableIpfs (Chromium flag)
Build flagENABLE_IPFS
Requires code in //chrome?True (currently, discussion about other design options are on-going)
Estimated milestoneshttps://github.com/little-bear-labs/ipfs-chromium/milestonesLink to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5105580464668672Tracking issuehttps://bugs.chromium.org/p/chromium/issues/detail?id=1440503#c_ts1682598269