Good morning/afternoon/evening all!
My name is Duncan and I am in the process of building out a comprehensive “Foundations of Web 3.0” course. As part of this course I am featuring 3 use cases and I am focusing on IPFS as one of them.
I am hoping that some of you may have the time to review the use case below as well as the video explainer I have created.
For context, this course is aimed at non technical people really as a first foray into what Web 3.0 is and I want the use cases to be varied enough to not just look at cryptocurrencies. You will see at the end we answer 5 questions, which are the same framing questions we answer for each of the use cases.
Any feedback appreciated:
Video explainer is here: https://drive.google.com/file/d/1HM5B4AnjYeAVaubNdQAXCcQfPxqFgaBR/view?usp=sharing
Decentralised Storage and Content Addressing
Focus: IPFS (InterPlanetary File System) as shared, verifiable storage for Web 3.0
Every Web 3.0 application needs somewhere to keep its data: images, app code, documents and metadata. In Web 2.0 this normally lives on a single company’s server or in one cloud provider’s account. If that provider goes offline, changes its terms, or removes content, the data can simply disappear.
The InterPlanetary File System (IPFS) offers a different model. It is a peer-to-peer protocol for storing and sharing files in a decentralised way. Instead of asking a specific server for a file at a location such as link, IPFS asks the network for a file with a particular fingerprint, known as a content identifier (CID). Any node that has the file and can prove it matches that fingerprint is allowed to serve it.
This makes IPFS a useful backbone for Web 3.0. Blockchains focus on recording ownership and small, critical pieces of data. IPFS holds the larger, heavier files, while still allowing users to verify exactly what they are receiving. Importantly, IPFS itself does not require a cryptocurrency to function, so it is a clean example of decentralisation without speculation.
From location-based to content-based addressing
Traditional web addresses are location-based. A browser asks a particular server for a named file and relies on that server being online and honest. If the file moves or the server disappears, the result is an error page. Control is concentrated in whoever operates that domain and the underlying infrastructure.
IPFS flips this by making the content itself the reference point. A CID is created from the file’s contents. When you request that CID from the network, any node that stores matching data can respond. If several nodes have pinned the file, they can all help to serve it. As long as the file matches the CID, the user knows it is the correct content. If anything changes in the file, the CID changes as well, which provides a simple but powerful integrity check.
Most users do not run their own IPFS node. They reach content through gateways that bridge IPFS and the traditional web, or via pinning services that specialise in keeping specified files available. A Web 3.0 application can operate its own nodes, use a third-party service, or combine both approaches for redundancy.
IPFS as a storage layer for Web 3.0 apps
Blockchains and IPFS are often used together. An NFT contract might store the CID of its metadata and artwork on-chain, while the files themselves are distributed through IPFS. A product-passport system can place structured manufacturing data on IPFS, then anchor the CID on a ledger. Some dApps even host their front-end code on IPFS, allowing users to load the interface from multiple gateways instead of a single web host.
In these examples, the blockchain is the source of truth for who owns what and which CID is currently associated with a given asset or record. IPFS provides the actual content. This keeps the ledger lean while still giving strong guarantees about the underlying data. Because IPFS is open and permissionless, any compatible application can read the same content if it knows the CID. That supports the Web 3.0 ideas of portability and interoperability: if one marketplace or interface disappears, another can still display the same item by reading the same CIDs.
Practical flow: uploading and publishing content
A typical workflow might look like this. A creator uploads an image and a small JSON metadata file to IPFS. The system generates CIDs for each file based on their contents. When the project mints an NFT or issues a certificate, the relevant CID is stored on a blockchain. Later, when a wallet or application wants to display the item, it reads the CID from the ledger, requests that content from IPFS, and verifies that the file received matches the CID. To the end user, it simply looks like their image or document loads, but behind the scenes a decentralised storage network is doing the work.
Limits and design considerations
IPFS does not magically guarantee permanence by itself. Someone has to decide which files to “pin” and keep available. If no node chooses to retain a particular file, it can eventually disappear from the network. Access control is also not built in. By default, IPFS content is public. Applications that need privacy usually encrypt files and then manage keys separately. Even gateways can become partial bottlenecks if users rely on just one; good designs encourage multiple access paths and redundancy.
What lives on the ledger?
The ledger usually stores references to IPFS content rather than the content itself. These references are the CIDs embedded in smart contracts, NFTs or other records.
Who holds the keys?
Keys control the on-chain records that point to CIDs. A project team, DAO or individual user manages wallets that can update which CID is used or can mint new tokens that reference IPFS data.
How is access controlled?
Reading public IPFS content is open to anyone who knows the CID. Restrictions are implemented at the application layer, often through encryption and key sharing, and through rules about who is authorised to update on-chain references.
Where is value created for the user?
Users gain resilience, because their data does not depend on a single server, and verifiable integrity, because they can trust that content matching a CID has not been altered. Portability follows naturally, as multiple apps can work with the same content.
What happens if the vendor disappears?
If a gateway, marketplace or application shuts down, content remains accessible as long as some node continues to pin it. Other interfaces can still read the same on-chain CIDs and fetch the files from IPFS, supporting the Web 3.0 goal that important records should outlive any single vendor or interface.