{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigw2kykrny77wcnfezib4eylhjkm3g4xofkwe5ezs6ybticliehfm",
    "uri": "at://did:plc:r6wd44ykivsom67rysktxcfb/app.bsky.feed.post/3mhsmxoi2yjr2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreias7qznxesi72xbpbiaoclziqir72rmwvsk7wqj3epkwrlrtkgxqu"
    },
    "mimeType": "image/jpeg",
    "size": 442484
  },
  "description": "IPFS is more than just a tool for NFTs. Discover how the InterPlanetary File System redefines how we share, store, and preserve data on a decentralized web.",
  "path": "/ipfs-explained/",
  "publishedAt": "2026-03-24T13:00:02.000Z",
  "site": "https://www.technodabbler.com",
  "tags": [
    "Distributed Wikipedia Mirror UpdateStatus update for 2021 Q2, usage instructions, current build process, and open problems.IPFS Blog & NewsMarcin Rataj",
    "What is IPFS? | IPFS DocsLearn what IPFS is and isn’t.IPFS Docs",
    "public CID inspection tool",
    "Pinata",
    "Filebase",
    "Learn more"
  ],
  "textContent": "Downloading data from the internet is a problem engineers have been refining for decades. Systems have been made faster through better protocols, more reliable through redundancy, and more efficient through caching and content delivery networks. If a file loads quickly and doesn’t fail halfway through, that is usually considered success. One aspect of downloading, however, has historically been treated as an afterthought: trust.\n\nOn today’s web, downloading a file means implicitly trusting that the server delivered what it claimed to deliver. Checksums and digital signatures exist, but they are typically bolted on as separate mechanisms, something verified manually, if at all. A file’s address describes where it came from, not what it is. If the content behind that address changes, most systems will not notice, and users rarely find out.\n\nIPFS approaches this problem from a different angle. Rather than focusing on speed or convenience, it focuses on immutability. Files are identified by their contents, not their location. If the data changes, its identity changes with it. This shift turns trust into a property of the data itself, instead of something borrowed from the infrastructure delivering it.\n\n## **What Is IPFS?**\n\nThe internet is built on a simple promise: when clicking a link, the content at the other end is expected to match what that link represents. Most of the time, this works well enough. Many links are meant to change over time. A blog post may be updated, a wiki page corrected, or a news article expanded as events unfold. In these cases, mutability is not only acceptable, it is necessary.\n\nThere are, however, situations where this promise needs to be stronger. Sometimes a link is expected to refer to a specific file, forever. A software release, a firmware image, or a security patch cannot silently change without consequences. To address this, checksums and signatures are often published alongside downloads. These tools allow verification, but only after the file has already been retrieved, and only if the verification step is performed correctly. The link itself still points to a location, not to the data it claims to represent.\n\nDistributed Wikipedia Mirror UpdateStatus update for 2021 Q2, usage instructions, current build process, and open problems.IPFS Blog & NewsMarcin Rataj\n\nBy putting Wikipedia on IPFS, it creates read-only snapshots of the encyclopedia that can ever be altered. Although impractical to use, it provided a protected archive as long as the files are available.\n\nIPFS addresses this by turning the link itself into a commitment. Instead of identifying a file by where it is hosted, IPFS identifies it by its contents. If the file changes, the identifier changes with it. This makes it impossible to substitute one file for another without detection, because the reference no longer matches. For systems built around explicit guarantees, this property is critical. NFTs rely on it because they function as contracts that bind a token to a specific piece of data. Firmware updates and security patches benefit for the same reason: devices can verify that what they received is exactly what was intended, regardless of where it was downloaded from. Even in environments where censorship is a concern, this approach ensures that once a reference is shared, it cannot be quietly altered without breaking the link itself.\n\n## **How IPFS Works**\n\nIPFS works by identifying files based on their contents rather than their location. When a file is added to IPFS, a cryptographic hash is computed from its data. This hash acts as a unique identifier for that exact file. Any change to the file, even a single byte, produces a different identifier. As a result, the identifier and the data it represents are inseparable.\n\nThe CID calculator determines the CID of a file, or a group of files.\n\nEach device running IPFS is called a node. When a node adds a file, it stores the data locally and advertises to the network that it can provide the file associated with that identifier. This information is recorded in a distributed lookup system, known as a Distributed Hash Table (DHT). The DHT does not store the file itself, nor does it track ownership. It only records which nodes have announced that they can provide a given identifier, and this information must be periodically refreshed to remain valid.\n\nTo retrieve a file, a node uses the identifier to query the DHT. The lookup process routes the request through the network until it reaches nodes responsible for that portion of the identifier space. These nodes return a list of peers that can provide the data. The file is then downloaded directly from one or more of those peers. Once received, the data is verified by recomputing its hash and comparing it to the identifier. If the values do not match, the data is rejected.\n\nWhat is IPFS? | IPFS DocsLearn what IPFS is and isn’t.IPFS Docs\n\nThe definite source of information for IPFS is the official documentation.\n\nIPFS deliberately separates verification from availability. The protocol guarantees that retrieved data can be verified, but it does not guarantee that the data will always be present. A file remains available only while at least one node continues to store and advertise it. Persistence therefore depends on intentional replication, either by running nodes or by using services that commit to hosting the data over time.\n\n## **Node IDs and How the Network Is Laid Out**\n\nEvery IPFS node has a unique node ID, which can be thought of as a very large number. File identifiers are also large numbers, derived from the file’s contents. Because both are numbers, IPFS can compare them mathematically.\n\n💡\n\nIPFS uses two versions of content identifiers. ****CIDv0**** is the original format and always starts with `Qm`. It is fixed to a single hashing method and encoding, which made it simple but inflexible. ****CIDv1**** is the newer format and typically starts with `bafy`. It is self-describing, meaning it includes information about how the data is encoded and hashed, making it more future-proof. Both formats can refer to IPFS content, and a CIDv0 value such as `QmTtrJuMuoAUfHpq3nEAtmU4QSLtFuUKH98XruaciBvWzd` can be converted into an equivalent CIDv1 representation `bafybeicsrirptuib6qliaesuqucbdbsjlu55sdsutzsgxf5yftjspuga5i ` . While both are valid, CIDv1 is now the preferred format because it supports more encodings and works more naturally with modern tools and gateways.\n\nNodes that have numbers closer to a file’s identifier are considered “closer” to that file. This idea of closeness has nothing to do with geography or network distance. It is purely a numerical comparison. IPFS uses this property to decide which nodes should be responsible for remembering who has which files.\n\n\n    /dnsaddr/bootstrap.libp2p.io/p2p/QmNnooDu7bfjPFoTZYxMNLWUQJyrVwtbZg5gBMjTezGAJN\n    /dnsaddr/bootstrap.libp2p.io/p2p/QmQCU2EcMqAqQPR2i9bChDtGNJchTbq5TbXJJ16u19uLTa\n    /dnsaddr/bootstrap.libp2p.io/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb\n    /dnsaddr/bootstrap.libp2p.io/p2p/QmcZf59bWwK5XFi76CZX8cbJ4BhTzzA3gU1ZjYZcYW3dwt\n    /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ\n\nExample of the bootstrap list used by IPFS node to find their first peers. By using a custom bootstrap, one could create a private IPFS network.\n\nA node does not start out knowing the network. When IPFS is first started, it connects to a small list of well-known**** bootstrap nodes. These nodes are not special authorities; they simply act as introductions. By connecting to them, a new node learns about other nodes, and those nodes introduce it to more peers. Over time, the node builds a small list of neighbors spread across different numerical ranges. This is enough information to move requests closer to where they need to go, without ever seeing the entire network.\n\n## **How Advertising Works in IPFS**\n\nAssume a node adds a file called `firmware.bin`. IPFS computes an identifier for the file based on its contents. The node now wants other nodes to be able to find it.\n\nIPFS defines that the nodes responsible for tracking providers of a file are the nodes whose IDs are numerically closest to the file’s identifier. The problem is that the node adding the file does not know whether those nodes exist, nor how to reach them directly.\n\nA simplified illustration of IPFS advertisement, each nodes will know the content of its neighbor and relevant \"mathematically nearby\" files.\n\nTo solve this, the node starts by asking its current neighbors for help. Each neighbor compares its own ID to the file’s identifier. If it knows of another node that is a closer numerical match, it returns that node’s information. The advertising node then contacts those closer matches and repeats the process. Each step moves the advertisement closer to where it belongs.\n\nEventually, the advertisement reaches a small group of nodes that are close enough to the file’s identifier to be responsible for it. These nodes record a simple statement: _this node can provide this file_. The file itself is never sent during advertising, only the provider information. Because nodes come and go, this information expires unless the advertising node periodically repeats the process.\n\n## **How Lookups Work in IPFS**\n\nLooking up a file uses the same mechanism in reverse.\n\nAssume another node wants `firmware.bin`. It has the file’s identifier, but no idea who has the data. The node begins by asking its neighbors if they know about providers for that identifier. If they are not close enough to be responsible, they return neighbors that are better numerical matches.\n\nEach hop moves the request closer to the same region of the network that received the original advertisements. After a small number of steps, the lookup reaches nodes that have stored provider records. These nodes return a list of node IDs that claim to have the file.\n\nA shorten version of IPFS lookup, a node searching for a file will eventually converge to the correct location.\n\nThe requesting node then connects directly to those providers and downloads the data. Once the transfer completes, the file is verified by recomputing its identifier and comparing it to the one requested. If the values do not match, the file is rejected.\n\nBecause advertising and lookup follow the same rules and converge on the same numerical neighborhood, discovery works without any node needing a global view of the network.\n\n### **Peers, Not Clients and Servers**\n\nIPFS does not define fixed client or server roles. Any node can request data, store data, and provide data to others, depending on whether it currently has the content being requested.\n\nIn practice, nodes differ in how suitable they are for hosting data. Short-lived nodes, such as web browsers or mobile devices, may connect briefly and then disappear. Long-running nodes, such as servers or dedicated hosts, stay online and continue advertising their content. While both participate in the same network, their effect on availability is very different.\n\nAdvertising content in IPFS takes time to propagate and must be refreshed to remain valid. If a node goes offline shortly after advertising, its provider information expires and the content becomes undiscoverable. For this reason, data meant to remain available is typically stored on stable nodes, while short-lived nodes are better suited for retrieving and caching content rather than hosting it long term.\n\n## **A Practical Example**\n\nTo make IPFS concrete, the same small text file was uploaded to two different IPFS providers: **Pinata** and **Filebase**. Both services successfully stored the file and returned an identifier, but the results were not identical.\n\nPinata returned the following CID, in the modern CIDv1 format: `bafkreifdcznhu7e5aozzumsfypyzs3coarxnecju5o2vvggtp727vp5odq`\n\nFilebase returned a different-looking identifier, in the older CIDv0 format: `QmTtrJuMuoAUfHpq3nEAtmU4QSLtFuUKH98XruaciBvWzd`\n\nAt first glance, this seems to undermine the idea that IPFS identifies content rather than location. To investigate further, the CIDv0 identifier was converted into CIDv1 format using a public CID inspection tool. The converted result did **not** match the CID returned by Pinata. This showed that the two identifiers refer to different IPFS objects, even though the uploads were intended to contain the same file.\n\nThe Filebase inteface, with the ipfs-demo.txt file uploaded to the technodabbler-demo bucket.\n\nThe next step was to verify whether the actual file contents differed. Both CIDs, the Pinata and Filebase, were retrieved through a public gateway and compared directly. The downloaded files were identical. The difference lies not in the visible content, but in how each provider imported and structured the data internally. IPFS identifiers are derived from the exact data structure being stored, including how files are chunked and encoded. Different defaults can therefore produce different CIDs, even when the resulting file appears the same to a user.\n\nThe Pinata inteface, with the ipfs-demo.txt file uploaded to the main folder.\n\nThis leads to the first important lesson: IPFS guarantees that the content behind a given CID will never change. It does not guarantee that two identical-looking files will always produce the same CID if they are imported differently. Each CID is a precise commitment to a specific data structure.\n\n\n    IPFS demo file\n    Created for Technodabbler\n    This file should always hash to the same CID.\n\nThe content of the test file, ipfs-demo.txt\n\nThe second lesson concerns redundancy. Uploading the same file to multiple providers creates multiple identifiers, not a single replicated object. If the goal is to add redundancy or migrate between providers, the correct approach is to pin an existing CID, not to re-upload the file. Pinning instructs another provider to store and advertise the exact same IPFS object, preserving its identity across infrastructures.\n\n## **Unmatched in Its Niche**\n\nIPFS is not an easy technology to understand, and it is not a general-purpose replacement for how most data is distributed on the web today. Its mental model runs counter to decades of location-based thinking, and many of its guarantees only make sense once the distinction between identity, availability, and hosting is clearly understood. For most everyday use cases, traditional downloads, CDNs, and centralized storage remain simpler and more practical choices.\n\nWhere IPFS stands apart is in the narrow set of problems it was designed to solve. In situations where a reference must remain stable over time, where changing the underlying data would break trust, IPFS offers guarantees that other systems cannot. NFTs rely on it because they are contractual by nature. Firmware and security updates benefit because devices must be able to verify exactly what they are installing. Archival data, research artifacts, and news records gain value when their contents can be independently verified long after publication. That makes IPFS a niche technology by design, but within that niche, it remains unmatched.\n\nIf you want to learn more about NFTs and digital ownership, Gods Unchained offers a practical, hands-on introduction. It demonstrates how blockchain-based assets can move beyond theory into real game economies, while still highlighting the challenges of balance and sustainability.\n\n\n                            Learn more\n                        ",
  "title": "IPFS Explained: A Protocol Built to Make Data Tamper-Proof",
  "updatedAt": "2026-03-24T13:00:02.000Z"
}