What is IPFS?
IPFS stands for InterPlanetary File System: an open, decentralized protocol for storing and sharing files over a peer-to-peer network. It was developed in 2014 by Juan Benet at Protocol Labs and has since become a global open-source standard.
The core difference with the current web: IPFS addresses files based on content, not based on location. On the regular web you ask: “Give me the file located on server X, folder Y, file name Z.” With IPFS you ask: “Give me the file with this exact content” — regardless of where it is stored. That address is a cryptographic hash, a so-called CID (Content Identifier), and looks like this:
Every change to the file automatically produces a different CID — so you can always be sure that you receive exactly the right version.
How does it work?
IPFS combines four technical principles:
| Principle | What it does |
|---|---|
| Content Addressing | Each file is given a unique CID based on a cryptographic hash of the contents. The CID changes as soon as the content changes. |
| Merkle DAY | Files are split into blocks that are linked via a tree structure. Large files can thus be retrieved in parallel from multiple peers. |
| DHT (Distributed Hash Table) | A distributed routing table that allows nodes in the network to find each other. No central server is needed to determine which node has which file. |
| Bitswap | The exchange protocol through which nodes request and offer blocks. Similar to BitTorrent, but universally applicable to any type of content. |
When you add a file to IPFS, it is split into blocks, hashed, and stored locally by your own node. Your node announces via the DHT that you have that CID. Other users can request that CID; the network finds the nearest node(s) that have the file and delivers it. If you want to guarantee that a file remains permanently available, use pinning: you or a pinning service promise to store and serve the file.
Is it more secure than HTTP/HTTPS?
IPFS and HTTPS provide different forms of security — they complement each other rather than exclude each other.
| Aspect | HTTP/HTTPS | IPFS |
|---|---|---|
| Transport security | HTTPS encrypts the connection between browser and server (TLS). HTTP doesn’t do that. | IPFS does not encrypt the transport by default, but can be combined with TLS (via gateways or libp2p). |
| Content integrity | No guarantee: a server can change the content without the user noticing. | Guaranteed: the CID is a cryptographic hash. If the contents differ, the hash is incorrect and the node rejects the file. |
| Single point of failure | Yes — if the server or CDN goes down, the content will be unavailable. | No — the file can be retrieved from multiple nodes at the same time. |
| Censorship resistance | Low — a provider or government can block the server or have content removed. | High — content held by multiple nodes is difficult to censor without blocking all nodes at once. |
| Privacy of Requests | The server sees who requests what (log files). | CID requests are visible on the network. Complete privacy requires additional measures (e.g. Tor or encryption of the content itself). |
| Trust in source | You trust the server and the TLS certificate issued by a certificate authority. | You trust the hash. The mathematical verification is independent of any authority. |
Conclusion: IPFS offers superior content integrity and censorship resistance; HTTPS provides superior transport encryption. In practice they are combined: IPFS content via an HTTPS gateway gives you both benefits.
Difference between Web 2.0 and Web 3.0
The Web has gone through three generations, each with a different model for how information is stored and accessed:
| Web 1.0 (1990–2004) | Web 2.0 (2004–present) | Web 3.0 (emerging) | |
|---|---|---|---|
| Addressing | URL + DNS → server | URL + DNS → centralized platform | CID → distributed network |
| Storage | Own servers | Central cloud (AWS, Azure, GCP) | Spread across network nodes |
| Control | Server owner | Platform (may remove content) | No central administrator |
| Dependency | DNS + web server | DNS + CDN + platform API | Optional: DNSLink or ENS for readable names |
Independence from DNS and HTTPS
Today’s web is completely dependent on two systems: DNS (the address book that converts a domain name to an IP address) and HTTP/HTTPS (the protocol by which the browser communicates with the server). Both are centralized: DNS registries are managed by governments and companies; HTTPS certificates are issued by a limited number of certificate authorities. Whoever has control over those systems can determine what is accessible.
IPFS breaks that dependency: a CID is completely self-explanatory and refers to content, not to a location. You don’t need DNS to resolve a CID — every IPFS node knows how to find the right nodes via the DHT. This makes it possible to reach content even if a domain name is disabled or a certificate is revoked.
Integration with Web 2.0: maintaining user-friendliness
A fully IPFS-based web requires each user to run their own node — which is impractical for the average visitor. That’s why bridge technologies have been developed that make the benefits of IPFS available through the trusted Web 2.0 infrastructure:
| Technology | How it works | Advantage |
|---|---|---|
| IPFSGateway | A server that converts IPFS requests into regular HTTPS responses. Public gateways: ipfs.io, cloudflare-ipfs.com, or its own node. |
Any regular browser can reach IPFS content without any plugin or installation. |
| DNSLink | A DNS TXT record links a domain name to a CID: dnslink=/ipfs/bafyb…. The domain name continues to work, the content comes from IPFS. |
Users see a trusted URL; the content is decentralized and cryptographically verifiable. |
| Service Workers | JavaScript code in the browser intercepts network requests and routes them to a local IPFS node or gateway. | Full IPFS functionality in a regular browser, without a browser extension. |
| Pinning services | Services like Pinata or web3.storage keep a copy of your IPFS content and provide high availability, similar to a CDN. | Reliable uptime without your own server infrastructure; content integrity remains guaranteed by the CID. |
The ideal approach combines both worlds: content published on IPFS (decentralized, integer, censorship resistant), accessible via an HTTPS gateway with a trusted domain name (user-friendly, no installation required). Anyone who wants can connect directly via a IPFS node or Brave and is completely independent of the gateway.
Finally: our IPFS project
At Brainfusion we are proud of what we have been able to achieve. We showed that IPFS is not only a promising technology on paper, but also works in practice — with real applications, on its own node.
error.com — originally a fully dynamic PHP/MySQL platform — has been successfully migrated to a static IPFS version. The site is accessible via our own node and proves that a complex web environment can run without a central server, while maintaining speed and ease of use.
(Fake Money) — a peer-to-peer financial application that allows people to pay each other for services provided — also runs on our IPFS node. The app is fully functional and can be tested with only a valid email address.
Both projects can be viewed live on demand. This is not an end point for us, but proof that the direction is right: an open, decentralized web is not only possible — it already works.