Right, that's a good question.
It's indeed correct that the gateways are (currently) centralized. It's a important step in our upgrade path of the web to be able to use existing technologies to access distributed content. The trade-off currently is that the HTTP part becomes centralized, as that's how HTTP works.
So in short without too many details, this is the flow from you adding content on your IPFS node to your browser showing the content from one of our gateways:
- You add the content on your local IPFS node, getting
$HASH for future use
- Your local IPFS advertises the content to all the nodes around it, effectively telling the world that you have
$HASH available in case anyone needs it
- You go to
https://ipfs.io/ipfs/$hash in your browser (or any other public gateway)
- The HTTP gateway receive a request for
/ipfs/$HASH and checks if that content is available locally
- If it's available locally, just serve the content directly
- If it's not available locally, ask the network for which peers the content is available at
- Once we know some peers that has the content, start downloading the parts of the content from the peers
- When chunks come in via IPFS, serve what we can via HTTP to the browser
- Now you can see the content you added at step #1! \o/
Basically the flow is the same within IPFS, but without outputting it via a HTTP endpoint.