The Interplanetary File System (IPFS), developed by Protocol Labs, is a popular decentralized file storage protocol that takes care of content addressing. This means IPFS can help users store files, as well as provide a way to find and retrieve those files, in the decentralized IPFS network. In simple terms, IPFS can be thought of as a communication protocol between nodes in a decentralized network that facilitates storage-related operations. Networks such as Filecoin and Crust, and services such as Pinata all use IPFS.
While the above is an oversimplification, it helps to illustrate why IPFS-based storage solutions have emerged to begin with: IPFS does not have any incentive mechanisms built in for people to operate nodes or store your files. Node operators need to pay for storage space, computational power and bandwidth, and without an incentive system it becomes difficult for node operators to justify operating a node.
The Interplanetary File System
The IPFS protocol hashes data with metadata creating a unique identifier called a content ID (CID). Once that CID is created, the content in that CID is unique and becomes immutable: it cannot be changed. If a user would like to make changes to a file, they need to re-upload the file which will be hashed again and a new CID is created. So when you look for content hosted on IPFS, you are actually telling the IPFS network to retrieve a specific piece of content instead of retrieving the content at a specific location.
IPFS nodes thus need a way to know where the content that a CID references is located. For this IPFS uses distributed hash tables (DHTs) and the Kademlia algorithm to map the addresses of peer nodes that hold specific content. When a user asks an IPFS node to retrieve the content of a CID, the node will query the DHT to retrieve addresses of all peers that have that particular CID.
If content needs to be regularly refreshed (for example new versions of a dApp are released), instead of re-sharing a new CID, developers can use the Interplanetary Name System (IPNS) instead. In IPNS, a name is the hash of a public key. It is associated with a record containing information about the hash it links to that is signed by the corresponding private key. This way new records can be signed and published under one IPNS hash instead of sharing updated CIDs every time.
The key weakness of IPFS is that content is only available as a node is willing to store the data. During the duration that the data is stored it is indeed immutable, i.e., the content referenced by a CID will never change. However, without any incentive, a node can remove the data or go offline entirely, making the content unavailable. Furthermore, to access IPFS content you need to either run your own node (you don’t need to broadcast content, but you will have DHTs that are regularly updated) or you need to communicate with an IPFS gateway, which is a node hosted by a third party that helps transmit the data you want to retrieve.
Furthermore, IPFS automatically deletes files from a node after a specific period of time. To ensure nodes maintain copies of data stored on a node, those files need to be “pinned”. It is this pinning action that decentralized file storage providers use to store files for extended periods of time when using IPFS.
The Brave browser makes this process seamless, so much so that retrieving data from a CID feels no different than surfing the web. While interacting with a gateway is inherently considered no riskier than surfing the web, certain risks that you face when browsing the internet are also present when interacting with an IPFS gateway. For example, a malicious gateway could lie about the content it is serving you or track specific content retrievals.
The main strengths of IPFS are that the protocol is open source, enabling any project to use decentralized storage , and that it is easy to integrate into existing projects with a strong community that backs the technology.
We will take a closer look at Filecoin, Crust Network and Pinata below, who use IPFS to enable decentralized storage.
All references were accessed between May 5th and 31st, 2022.