The gateway hosted at https://ipfs.io allows browsers and tools that speak http to access content from the IPFS network. It provides the canonical way to address IPFS content via http scheme urls.
A request for:
https://ipfs.io/ipfs/QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN
...will hit the gateway and get forwarded to an IPFS node, which fetches the block for the CID QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN and returns the content via http.
The gateway lets you to ask our servers to do an IPFS lookup for you. It provides an upgrade path towards full IPFS support; tools that speak http can fetch data via it's content-address via the gateway today.
When they are ready they can embed an IPFS node and fetch the same content directly from the network. Developers are encouraged to opportunistically upgrade http urls that point to the ipfs.io gateway to the equivalent ipfs request. The magic of content-addressing means you'll get exactly the same data whether you request it via http or via ipfs.
So, the gateway provides "IPFS as a service". We'd like everyone to run their own IPFS node, and fully decentralize the web, but until that time, we'll be running a large piece of critical network infrastructure, to help folks make the transition.
Any ipfs node can run a local http-to-ipfs gateway. Folks who run a local ipfs daemon can use their own gateway, at https://localhost:8080 by default, to allow their browser and other tools to fetch content-addressed data over http but using their ipfs node to find and fetch it. The ipfs-companion web extension can be used to automatically upgrade ipfs gateway http urls to be redirected to your local gateway.
When folks use their own local gateway, our gateway infrastructure plays no part in the request. We want everyone to be able to use ipfs in this manner.
Our gateway is made up of regular go-ipfs nodes. Again, due to the magic of content-addressing, the gateway nodes we run are fungible; you can swap the service provided by one gateway node for any other. Other orgs have stood up their own ipfs gateways; Cloudflare being a notable one, and the decentralizing principle behind all this is that you can get the same content-addressed data from any of them...
$ echo hello | ipfs add -q
QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN
$ ipfs cat QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN
hello
$ curl https://ipfs.io/ipfs/QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN
hello
$ curl https://cloudflare-ipfs.com/ipfs/QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN
helloYou can see the video version of this explanation over here https://www.youtube.com/watch?v=-cW7QCQkhKo
So, anyone can run a gateway, but we offer up https://ipfs.io as the canonical gateway, as a public service.
Most critically we want to normalise using and publishing https://ipfs.io/ipfs/<cid> style addresses, as it tools that understand ipfs to upgrade them to ipfs, while tools that don't can still fetch the content.
It is assumed that a proliferation of gateway providers and ipfs paths at many different domains would make it less clear to end users and developers what was going on (although ipfs-companion already does a great job of redirecting ipfs addresses from any valid domain).
We also offer it as a "trustable" ipfs gateway. We cannot automatically verify that another gateway is always serving the correct content for a given cid. Using a gateway means placing your trust in the service operator that they will not tamper with the response. Content that is fetched via an ipfs node is always cryptographically validated, but once we switch to using the http-to-ipfs gateway of another node, we lose the end-to-end validation. There is currently no automatic mechanism for validating that an http-to-ipfs gateway is serving the correct content for a given cid, so we provide ipfs.io as the reference gateway.