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 <https://github.com/WICG/proposals> (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 <https://github.com/whatwg/meta/issues/290> 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 On Mon, Oct 16, 2023 at 12:39 PM John Turpish <[email protected]> wrote: > *Contact emails* > [email protected] (primary) > [email protected] > [email protected] > > *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 > <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork> > > *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 > [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/09c250f0-22aa-4528-b339-77a8eeedec5an%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- > 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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fd22f878-d233-4962-905e-ed13e159a765%40littlebearlabs.io?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXkpAwkFN%3DUrXtyk1PVrBDP%3D%2BfETi1-rre_igFSiOnu1kA%40mail.gmail.com.
