Support for ipfs:// and ipns:// protocols

[fabricedesre]

ipfs:// and ipns:// provide access to content based addressed resources. They are agnostic to the payload so can be used to load web content. Because of content based addressing, content integrity is guaranteed independently of the transport layer used as long as you verify block hashes.

Broadly speaking there are 2 classes of implementations:

• redirecting ipfs:// urls to a http(s) gateway. This is what browser extensions do, but is not ideal since you delegate the integrity check to the gateway, hence the trust.
• using a local IPFS node so get local integrity check. Brave can do that by running a Kubo node, and Capyloon does that by running a Iroh node (https://github.com/n0-computer/iroh).

While running a full node works, it's also quite heavyweight. A better solution would be to extract the block verification and traversal from eg. iroh's code base and use it for a lightweight implementation. This component could be generic enough to be reused in multiple browsers and other runtimes.

Is there any appetite to get such support in Servo?

[RangerMauve]

This would be wonderful. I've been using Electron for their protocol handler APIs in Agregore but would love to switch to something a bit more rusty. 🥰

[jdm]

This is the kind of work that I'm a bit hesitant about for a couple reasons:

• I know nothing about ipfs or its use-cases. What kind of content is accessible this way that a rendering engine may need to access?
• I don't have a good sense for the maintenance burden of this over time

I'm not necessarily arguing against it, but I think I'd like to understand the value of it better.

[fabricedesre]

Yep, it would be better to have a new embedder trait (and move get_user_agent_string() to it). I tried to sketch something in https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9959176b2e2ba28afdd734753eb60213

Not super happy with how it looks, but I can't find a way to get rid of the Box in Box<dyn Future<Output = Response>>.

[jdm]

Yeah, until async traits are standardized we probably can't do better than that. That looks like a good place to start!

[RangerMauve]

If I may, from having tried to add custom protocols to a few different environments (chromium, webkit, android, iOS, electron) I've found some functionality that's been important:

• Streaming interface for request and response bodies
• Being able to register schemes as "standard" in the URL handling in the stack
• Being able to register schemes as "secure" so that they can serve the same purpose as HTTPS

This is stuff that has bit me in the rear before when it wasn't available either by making it harder to tightly integrate custom URLs in web apps or made things grossly inefficient or unable to handle large amounts of data.

Adding these in at the network layer so that higher layers (like web extensions) could intercept requests is also very useful.

[fabricedesre]

Yes, Gecko also has a bunch of flags you can set on protocol handlers to decide in which context you can load a resource, and if it should be considered a secure context. I'd also like to be able to set a default CSP for a given protocol.

What do you mean by "standard" urls?

[RangerMauve]

Not sure if Servo and Gecko have this distinction, but in Chromium, marking a URL as "standard" means that it has a "hostname" portion which gets parsed out to set the origin.

https://source.chromium.org/chromium/chromium/src/+/main:url/url_util.cc;l=594?q=AddStandardScheme&ss=chromium

This is where you can configure it to parse out the user/host/port bits from the origin.

Without it origin isolation doesn't work well and URL parsing adds the hostname portion to the path which can mess with application logic using relative URLs