Point relative paths to documents in ipfs directory

[AlbertoElias]

For IPFS websites that have relative links such as /about, it'd be great if the extension modified the links to http://mygateway/ipfs/hash/about.html. Currently, clicking that link takes you to http://mygateway/about.

[lidel]

I think this is quite doable: we already normalize links (href and src) that use custom protocols into HTTP ones[1].

In this case we would inject a similar content script, but only into every page under root of IPFS CID. It would normalize paths in DOM + observe every DOM change (so that it works even with dynamic pages).

[1] contentScripts/normalizeLinksWithUnhandledProtocols.js

[olizilla]

I think it be surprising if we start rewriting valid, domain-relative links like /about.

It's super nice to be able to deploy an app to ipfs.io/QmHash/index.html and cool.website/index.html and have it all work under both root or an arbitrary mount path, but for that to work the author needs to build their site with location relative links.

If we rewrite them, then to the site author it will look like the site works correctly in both contexts, but it'll be broken for anyone not running the plugin.

It could be argued that lots of things will be published to ipfs with broken, root relative links, but I feel uneasy about companion papering over that issue.

[lidel]

I agree with Oli, we should not mutate paths used in attributes of DOM elements.
We now have public gateways that support cidv1b32-in-subdomain workaround (ipfs/in-web-browsers#89 (comment)), so I am closing this.