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. On Monday, October 16, 2023 at 4:09:28 PM UTC-4 Jeffrey Yasskin wrote:
> 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/d0052682-63c2-422a-a041-368a76dd2577n%40chromium.org.
