IPFS
An IPFS gateway is an ordinary web server that fetches content out of IPFS on your behalf and hands it back over plain HTTP, so a browser that speaks nothing but the web can read a file that is addressed by what it is rather than by where it lives. IPFS itself, the InterPlanetary File System, is a peer to peer system for storing and retrieving files by a hash of their contents, and a gateway is how most people encounter it without running any of it. One point of vocabulary, since the abbreviation is shared: the same four letters are also the name of an unrelated insurance finance business, which is a different subject from anything on this page.
What content addressing means and why the address never changes
Content addressing means the name of a file is computed from the file itself. Adding a file to IPFS runs it through a hash function, in practice SHA-256, and produces a content identifier, the CID, which is the address. The same bytes added on any machine produce the same CID, and one changed byte produces a completely different one. That gives three properties at once: an address that proves what it points at, automatic deduplication of identical data, and immutability, because a CID can never point at anything other than the content that generated it. Where Napster's index, from 1999, named a file by a title typed on somebody's disk, a CID names it by the bytes, so a wrong file cannot hide behind a right name.
Immutability is also the awkward part. Publishing a correction produces a new CID, so anything that changes behind a stable name needs a second layer, and IPFS provides a mutable pointer signed by a key that can be aimed at successive CIDs. Files are not stored whole either: a file is split into hashed blocks assembled into a tree addressed by one root CID, which is what lets a large file be fetched in parts from several peers, exactly as pieces are in BitTorrent, where each piece is itself requested in 16 KiB blocks.
What a gateway actually does, and what it costs
A gateway does four things. It resolves the CID by asking the network which peers hold the blocks, fetches them, verifies them against their hashes, and serves the reassembled file to your browser as an ordinary web response. The project runs a public gateway, and various organizations run their own, some open and some restricted to their own content.
The cost is that a gateway puts a server back in the middle of a system designed not to have one. It sees what you requested, it decides what it will serve, and it can be slow, rate limited or unavailable. Verification moves as well: your browser trusts the gateway's word that the bytes matched the CID, because the browser never checked the hash. Running a local node and reading through its own gateway, which conventionally listens on port 8080, removes all of that, which is the difference between using IPFS and using a website backed by it.
What IPFS shares with BitTorrent and where the two part company
IPFS and BitTorrent share more machinery than most comparisons admit, and the differences are about scope rather than about technique.
| Aspect | BitTorrent | IPFS |
|---|---|---|
| Unit of distribution | A torrent, a fixed set of files with one info hash | A block, addressed by CID and shared across everything |
| How you name it | A torrent file or a magnet link | A CID, which is the hash itself |
| Finding who has it | Trackers, a distributed hash table, peer exchange | A distributed hash table for content routing |
| Verification | Per piece, against the 20 byte hashes in the metadata | Per block, against the CID itself |
| Keeping data alive | Seeding, per torrent | Pinning, per CID |
| Deduplication across items | None, each torrent stands alone | Automatic, identical blocks are one block |
The consequence worth remembering is that a torrent is a bounded thing you either have or do not have, while IPFS is one address space in which everything anybody has added coexists. A client such as qBittorrent shows a list of torrents with progress on each. An IPFS node shows a store of blocks, some pinned deliberately and some cached because they passed through, and it discards the unpinned ones when the store fills.
Why IPFS often feels slow
IPFS feels slow because of content routing, not because of transfer speed. Before a byte moves, the node must discover which peers hold the blocks for a CID, and that lookup walks a distributed hash table hop by hop across a network of strangers. Put a public gateway in front and the wait becomes the gateway's own lookup plus its queue. Three further causes account for the remainder.
- Few providers is the common case, because unpopular content is often held by one node, and if that node is offline the fetch waits rather than failing cleanly.
- Cold caches mean the first request for a CID through a gateway does the full lookup, while the same request minutes later is served from the gateway's store and appears instant.
- Connectivity matters as it does anywhere in peer to peer, because a node behind network address translation with no reachable port is limited to peers accepting incoming connections.
That is a different cause from a slow torrent, which is usually a shortage of seeds or a firewalled client rather than a routing delay, so the two do not share a checklist.
Where blockchain comes into it, and where it does not
Blockchain and IPFS are separate technologies frequently used together, and IPFS is not a blockchain. There is no chain, no consensus mechanism, no ledger and no token in IPFS itself: it stores and retrieves blocks, and nothing more. The two appear together so often because storing data directly on a blockchain is prohibitively expensive, so the common pattern puts the bytes in IPFS and records only the CID on the chain. That works precisely because the CID is a hash: recording it on an immutable ledger proves what the data was without the chain carrying it.
Availability is the gap that pattern leaves. A CID recorded on a chain forever does not mean the bytes exist forever, because somebody must still be pinning them, which is why pinning services and the incentive layer built by the related Filecoin project exist at all. IPFS Desktop packages a node with a file browser and a settings interface for people who would rather not use a command line, and the reference implementation underneath runs the local gateway. Take builds from the project itself. The Glossary defines hashes, blocks, distributed hash tables and pinning, and Syncthing is the better contrast for anyone whose real problem is keeping their own devices in agreement.