Intent to Prototype: Verifying IPFS client

[John Turpish]

Contact emails

jo...@littlebearlabs.io (primary)
jfern...@igalia.com
diet...@protocol.ai

Explainer
https://github.com/little-bear-labs/ipfs-chromium/blob/main/doc/explainer.md

Specification
Multiple 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.md
https://specs.ipfs.tech/ipns/ipns-record/
https://specs.ipfs.tech/routing/http-routing-v1/
https://specs.ipfs.tech/http-gateways/web-redirects-file/

Summary

IPFS is content-addressed networking.
https://en.wikipedia.org/wiki/InterPlanetary_File_System

The 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 component
Blink>Network

Motivation
Web 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 proposal
https://groups.google.com/a/chromium.org/g/chromium-dev/c/kmmrpDWfF90/m/96HvP5QUBwAJ

TAG review

TAG review status
None yet

Risks
For 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-gateway

There could be concerns around impact on caching, or misunderstandings of the gateway settings.

Interoperability and Compatibility

Here are some of the attempts at supporting IPFS in web browsers:
https://github.com/ipfs/in-web-browsers/blob/master/README.md#current-projects

Some support in other web-related tools (ffmpeg, curl):
https://github.com/ipfs/integrations/blob/main/README.md#completed-integrations

WebView application risks
No

Debuggability
We 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 flag
ENABLE_IPFS

Requires code in //chrome?
True (currently, discussion about other design options are on-going)

Estimated milestones
https://github.com/little-bear-labs/ipfs-chromium/milestones

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5105580464668672

Tracking issue
https://bugs.chromium.org/p/chromium/issues/detail?id=1440503#c_ts1682598269
--
You received this message because you are subscribed to a topic in the Google Groups "blink-network-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-network-dev/o9asNNdx3Fk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-network-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/09c250f0-22aa-4528-b339-77a8eeedec5an%40chromium.org.

[Jeffrey Yasskin]

Thanks for posting this here. I have a couple questions/suggestions:

* In your explainer, I don't see a description of the use cases for each of the 3 URL forms you plan to implement. https://tag.w3.org/explainers/ has some guidance around doing that.

* The explainer says "Why HTTP(s)?", but nothing before that says that anything's using HTTP(s). What's going on here? :)

* Your "Initial public proposal" is a chromium-dev post, which isn't as public as this field really wants. I think you have multiple organizations interested, which means this is appropriate for a WICG proposal (unless there's another community group or other incubation venue that's more appropriate). This is probably eventually destined for Fetch, so the WHATWG Specification Acceptance Stages might be appropriate, but as that's new, you might also not want to risk getting bogged down in its growing pains.

* I don't see any Privacy Considerations in the explainer. My understanding is that IPFS exposes requests to a different set of actors than HTTPS does, and your explainer should discuss the differences, how they interact with the expectations of someone browsing the web, and how browsers should help people expect the right things. There may also be Security Considerations to point out.

Thanks,

Jeffrey

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fd22f878-d233-4962-905e-ed13e159a765%40littlebearlabs.io.

[John Turpish]

Thanks for your feedback! Sorry for the long delay in following up.

I did some updates to the explainer inspired by your comments, hopefully that helps.
There seems to be a consensus that a WICG proposal is a good approach, and I've been having some discussions about what that should look like.