Addressing IPFS gateways through a common URL

Ecosystem
1

I wanted to discuss a small but important aspect of how IPFS uses gateways. In practice this is more of a call to browser developers for implementing such a feature, though the question may apply to applications other than web browsing. I’m sure something like this is planned or has been done already, but I wanted to ask how the problem will be handled exactly and your general thoughts on the matter.

Here’s my concern: Excluding a few services which spawn their own IPFS node, IPFS files accessed in a web browser must go through a gateway. This can be either your local gateway, spawned when you’re running go-ipfs or have js-ipfs in a browser extension… or an external gateway, such as the official one or the one Cloudflare is now offering. Every gateway has its own URL: If you’re using the local gateway this URL will be “http://127.0.0.1:8080/ipfs/”, while if you’re going with a public gateway it will be something like “https://gateway.ipfs.io/ipfs/”. The problem is this: How can I share a link to a website hosted on IPFS without having to tell people which gateway it goes through?

Let’s imagine I have a blog hosted on an IPNS domain. I want to share it on a chat, where I wish to be sure that anyone can see it. Clearly I cannot assume that everyone has go-ipfs installed so I can’t offer the local one. Right now I’d give them a link that goes through the official IPFS gateway… however that’s going to get more crowded and thus slow, may experience downtime at certain times, and may someday be required to censor content or risk being blocked. I could of course just give them the hash, but who’s going to be happy about being asked to search for a gateway and paste it into that? Ultimately it’s my responsibility to customize the URL to contain a gateway I trust and choose between various options such as:

http://127.0.0.1:8080/ipfs/1234567890
https://gateway.ipfs.io/ipfs/1234567890
https://cloudflare-ipfs.com/ipfs/1234567890

So how can this issue be solved? I was thinking of a convenient way, but it would require all major web browsers to agree on implementing support for the IPFS backend. It would be an extremely small and simple feature so I do see it happening. Basically I could just share the following URL with other people instead:

ipfs://1234567890

The browser then simply replaces “ipfs://” with “https://whatever-service.com/ipfs/”. The advantage is that browsers can contain a list of gateways, which they can attempt to parse the content through in a given order: When one is down it simply tries another! For example: First it would try 127.0.0.1:8080, if go-ipfs isn’t running then it will detect that nothing is there… so next it tries gateway.ipfs.io, if that’s up and not filtering the content then it uses that… but if this fails too it tries cloudflare-ipfs.com next… and so on until either one succeeds or the list reaches the end. Web browsers could contain default lists of IPFS gateways, which the user is of course allowed to customize and add their own entries to.

My question is how likely we are to see support for such a feature in web browsers. Mozilla recently added IPFS protocol support to Firefox, and I understand it was for URL interpretation… however I still can’t find a gateway customization setting on the about:config page. What about Chromium, is it likely to support ipfs:// addresses and offer customizable gateways? Or Microsoft with its Internet Explorer?

1 Like
2

good question . but it is a long long way to implment.

3

It is one of the simplest things a browser would need to implement, but I guess IPFS isn’t common enough just yet to warrant it. Hopefully we will be seeing this in at least the top web browsers by next year.

4

You might want to look at the Browser Companion:

3 Likes
5

I am somewhat familiar with the IPFS Companion extension. Does it address this proposal as well? If so it’s a good start… ideally though it’s something that can be built into most web browsers natively.

6

Drive-by:

Unfortunately the above URIs are not supported out-of-the box by web browsers and it won’t happen for some time. Even when we get native protocol handler API, you will still need to install extension that provides protocol handler implementation and you can’t assume all recipients of your message will have our browser extension installed.

For now, the only way to be sure your recipient is able to to access IPFS resource is to just point at any public gateway. If they have IPFS Companion installed, it will detect IPFS resources on ANY public gateway and redirect request to local IPFS node. If they don’t have it installed, then it will just load over HTTP, which is a nice fallback that works everywhere.

The way I understand your underlying question is: could we improve the “load over HTTP” fallback part, eg. by going over a list of known public gateways or picking one at random.

Short answer: yeah, check a PoC at GitHub - VanVan/ipfsProxyHTTP: InterPlanetary File System HTTP Proxy (simple proxy that redirects request to a random gateway)

The long answer: nah, not really. HTTP transport will always require working DNS and some HTTP server to handle initial request, which is a single point of failure. That is also a reason why we try to focus on adding native IPFS support instead of relying on HTTP Gateways, which are only a temporary measure on the migration path.

Hope this helps :slight_smile:

3 Likes
7

Fair enough, this does make a lot of sense. And it does help to know, thanks!

8

Could a browser not act as a node – or at least in the sense of utilizing the network while interacting with it. I have seen some interesting things using blockchains to do this like Nimiq.

Obviously setting up a node is different that mining but in terms of even transporting websites to IPFS using APIs & blockchain this could be a possibility.

Also – what if hardware was also adjusted to accommodate for PoC or to just somehow access the network direct – maybe I am not fully understanding how the gateway translates to the main IPFS network. Because to me this seems like a mixture of current hardware systems and browsers not being equipped which I could work more on.