The IPFS Network
If You Don’t Know, Ask…
If you do know, ask anyways. Since August, Matt Ober and I have been asking as many Ethereum dapps and devs how they are using IPFS and what they expect out of the technology. Specifically, do they care about decentralization and what problems are they solving for by using IPFS in their dapp. Below, we layout four important factors to be considered when utilizing the IPFS network for your application. The following framework guides our IPFS strategy and conversations with dapps as we continue the development of Pinata.
Number of Nodes
This seems to be the easiest and most obvious place to start. One node is vulnerable to going down while many nodes are less so. Interestingly, the majority of dapps are only running one centralized IPFS node, which I’ve covered previously. No matter if dapps were running on the public IPFS network or running their own private IPFS network, they all wanted to run or have access to more nodes. This helps them in two areas. First, dapps using IPFS as immutable off-chain storage had one central point of failure while using a single IPFS node. This really stretches the meaning of “immutable” when a single node going down erases everything. Second, dapps using a single IPFS node have a very slow CDN experience which has been a common complaint of IPFS. The more nodes in the network, the faster and more powerful the network is as a CDN.
Number of Providers
Not surprisingly, the dapps we talked with use one provider…AWS. We believe IPFS provides an amazing opportunity to avoid such monopolistic vendor lock-in. Multi-cloud is becoming a strategy being implemented by many Web2 enterprises to hedge risk against traditional single-cloud architectures and should be implemented by Web3 dapps using IPFS as the first step to decentralization. Multi-cloud is an important strategy because it protects dapps from outages or data loss on one cloud by being available across other clouds. Additionally, increasing the number of providers that your nodes are running across increases the geographic availability your nodes could reach around the globe.
Geography
Many dapps don’t realize the power of IPFS as an on-demand CDN. With IPFS, setting up nodes geographically close to the user allows you to build a CDN with more precision than traditional CDN providers. With P2P capabilities, IPFS can be close to or at the device, speeding up content delivery and reducing the need to touch the internet backbone. Additionally, geographically disperse IPFS nodes protect you from things like power outages and natural disasters.
Variety of Devices
The most notable trend we saw interviewing dapps and developers was how they were putting nodes on the user’s device. This provides two advantages. First, this can put the user in control and is as decentralized as we can get. Second, it allows dapps to truly be P2P in nature while using IPFS nodes in the cloud as backup if necessary. A design that utilizes servers, desktops, mobile, and IoT really pushes the resiliency and availability of a dapp.
What’s Optimal?
Completely depends on what you are trying to build. However, the radar graph above illustrates ways in which you can build resiliency, redundancy, and decentralization into your dapp. On the left, we have the most common design currently utilized by dapps building with IPFS. A design centralized across all four factors identified in this post. In the middle, we have a design that can be built by spinning up nodes with current cloud infrastructure. And, on the right, we have the maximized design across all four factors that dapps should strive for. Hopefully, we will get there!
