Support unix-like URI /ipfs/ in address bar

[lidel]

For lazy copy&paste ;-)
It should work the same way as currently exiting ipfs:

[lidel]

Actually, Firefox redirects /ipfs/<path> to file:///ipfs/<path> by default.
The file path will contain IPFS resources (provided via fuse after ipfs mount).
This feels much better than random hack of protocol handling in addressbar. Nevermind then :-)

[lidel]

On the second thought this only works on unix-like systems with arbitrary mount points.

In the light of #16 (comment) add-on should intercept requests to file:///ipfs/* and file:///ipns/*, check if file/directory actually exists, and if it does not (eg. Windows, or fuse not being mounted), redirect to currently active HTTP gateway.

[dylanPowers]

@lidel I'm not sure how Firefox works but Chrome got very cranky for me when web apps load from a file directory and try to load another file. You may want to check one of the markdown readers to be sure that isn't the case.
Check if this loads for instance /ipfs/QmSrCRJmzE4zE1nAfWPbzVfanKQNBhp7ZWmMnEdbiLvYNh/mdown#/ipfs/QmfQ75DjAxYzxMP2hdm6o4wFwZS5t7uorEZ2pX9AKXEg2u

[lidel]

Yes, I noticed this under Firefox too:

There are multiple issues with file:// and my current plan is to always redirect
file:///ipfs/.. to HTTP gateway (at least for now), as it will solve bulk of issues and give us single 'transport' to focus on in browser add-on.

Running JS from HTTP Gateway may leave us with some CORS limitations (eg. under Firefox when using custom protocol handler), but this will eventually be solved by adding HTTP headers described in ipfs/kubo#934 (comment).

[lidel]

Quick brain dump for my future self: standard addon SDK in Firefox does not provide good hook/event that could be used to replace file:/// requests that end with 404 (file not found, when fuse is not mounted, which is the case on MS Windows when running http gateway on a different machine). I don't want to listen for * events due to potential performance impact.

Replacing protocol handler for file:// seems to be very invasive and from what I've needs to be done before some XUL elements are initialized during browser startup. Not sure if it is possible to do it via Jetpack-based addon.

tl;dr: support for /ipfs/<hash> in Firefox (without fuse-based mountpoint in operating system) will require some additional tinkering with XUL internals, I'll try to work on this in spare time

[lidel]

As for CORS, seems that a fix landed this week: ipfs/kubo#1529

[lidel]

A lot changed since last year and this issue is bit outdated.
Closing as a duplicate, discussion is continued in #48