A different approach to chromium accepting my responses

[John-LittleBearLabs]

I wonder if adding something into AddAddtionalSchemes in //chrome might be more palatable than the change I was making in navigation_request.cc down in render_host.

⬆️ this is very much the question I want to ask.

It is worth noting, some of the other things in AddAdditionalSchemes are behind build flags, which was something raised as a possibility for this project. So, if we wanted to go that way, it's nice to know there's precedent.

The biggest downside is that this does mean CIDs are getting lowercased again, as they were with the http redirect. So the CIDv0 style (Qm...) are a non-starter as they're case-sensitive. And now that I'm going block-by-block (for ipfs:// anyhow), this is an even bigger problem as, at least for the moment, I'm resolving the binary CIDs in the PB-DAG links as CIDv0. So, if we go this route that's something that must be addressed.

But before I do that, I want to get a consensus on whether this is a worthwhile and good approach.

[John-LittleBearLabs]

It could also be worth questioning how many of these categories IPFS/IPNS really need to be in.

For my purposes I'm pretty sure they need to be in standard_schemes at the very least.

If they're in secure_schemes, then perhaps we have to ban insecure http gateways (or maybe just non-localhost http?). FWIW, right now I don't believe I have any in the list anyhow.

[John-LittleBearLabs]

@javifernandez - I floated an idea in our Slack, and I'd like to get your take on it. The hope is to handle various CIDs (including those that can't be lowercased and/or include characters that would be illegal in a host), while also not conflicting on an existing scheme (like http, particularly for URLLoaderFactory maps), and not changing anything in render_host.

• Don't do this kind of registry for ipfs: or ipns schemes. Let them hit the interceptor just as they did (case in-tact).
• Do register some other scheme that's not already handled in chromium. Perhaps ipfs-http:// or something.
  • Assume its "host" will always be an all-lowercase (probably base32) CID that's the root of a pb-dag.
• When intercepting ipns, resolve the name, then
• When intercepting ipfs (or if you just resolved ipns to ipfs), convert whatever CID you have to bafy...
• Issue an HTTP redirect to ipfs-http

What do you think of this idea?

[javifernandez]

Hi, at a first shot, using the Content Public API for adding new schemes seems the right approach. When I started working on implementing support for IPFS and IPNS through the Custom Handlers API I've been told that this would be the preferred approach for Embedders.

It seems that Chrome already added the 'isolated-app' scheme to the standard_schemes set. This could be perhaps the model we could get some inspiration from to propose adding IPFS/IPNS as an standard scheme. I find the isolated-app scheme explainer quite interesting.

[John-LittleBearLabs]

Hi, at a first shot, using the Content Public API for adding new schemes seems the right approach. When I started working on implementing support for IPFS and IPNS through the Custom Handlers API I've been told that this would be the preferred approach for Embedders.

It seems that Chrome already added the 'isolated-app' scheme to the standard_schemes set. This could be perhaps the model we could get some inspiration from to propose adding IPFS/IPNS as an standard scheme. I find the isolated-app scheme explainer quite interesting.

@javifernandez - am I to understand you think this PR is a good change? But perhaps doesn't go far enough?

You bring up isolated-app, which is also added to various categories in ChromeContentClient::AddAdditionalSchemes, like my change here.
Whereas the Google Groups comment you link to reads:

ContentBrowserClient's HasCustomSchemeHandler and ContentBrowserClient's IsHandledURL, as well as AddAdditionalSchemes.

So maybe I should also modify chrome_content_browser_client.cc's HasCustomSchemeHandler and IsHandledURL?

[javifernandez]

am I to understand you think this PR is a good change? But perhaps doesn't go far enough?

I believe so. From the technical point of view it made sense to add IPFS / IPNS to some of the scheme lists handled by Chrome. Having said that, adding a Chrome specific scheme is not the same than adding an external one. Our acceptance bar will be much higher, so we must think it carefully. IMHO, it's a line of work worth prototyping, at least to figure out how far we would need to go.

So maybe I should also modify chrome_content_browser_client.cc's HasCustomSchemeHandler and IsHandledURL?

HasCustomSchemeHandler is intended to be used with the ProtocolHandlerRegistry, so unless we want to explore that path, it wouldn't be useful for the approach you are proposing now.

However, IsHandledURL is implemented by the ProfileIOData by checking a hardcoded list of "known schemes". The NavigationRequests uses this API to determine whether it's should be treated as an external protocol. It's also used by the Process Security Policies, but I don't have a clear idea of the implications of this logic for our use case.