The IPFS Cloud
When people first hear about the InterPlanetary File System (IPFS), it’s often described as a “decentralized cloud”. A decentralized cloud certainly sounds exciting, but what actually is a “decentralized cloud”? If you’re building a decentralized application, you’ll want to consider using IPFS in your stack. But, it might not be for the reasons you think.
The Main IPFS Misconception
While IPFS is an incredible technology, there’s a common misconception around the phrase “decentralized cloud”. With blockchains, we’ve been conditioned that once our data is put onto the blockchain, it will remain there forever (sort of).
A trap that many people fall into is thinking that IPFS behaves similarly. There’s a common belief that IPFS is a magic cloud that we can freely upload our files to forever.
Unfortunately, this isn’t true.
While it would be incredible to have a giant network of servers all storing our data for free, the economics don’t make sense. After all, storage isn’t free. All of this data needs to be stored somewhere and that costs money or tokens.
The current reality of how most data is stored on IPFS is actually pretty similar to modern cloud storage. When a user uploads a file, that file is sent to servers run by Example Company™ and those servers store that data on a company owned IPFS node.
Pretty similar right? In each example, the file is being stored on a machine run by a specific company. Similar to modern cloud infrastructure, some companies may run their own IPFS infrastructure, while others may opt to use a different company to host their content on IPFS for them.
The key to take away from this is that in order for content to be available on the IPFS network, at least one node has to be purposefully hosting the content.
In the majority of cases today, the company will be in charge of hosting that content. This will either be done through running their own node or paying somebody else to host one for them.
How’s it Different?
If IPFS is so similar to the modern cloud, why should we use it? To understand this, we need to understand the fundamental problems IPFS is attempting to solve. Juan Benet gave a great talk on this which you can watch here. To summarize, IPFS allows us to retrieve content based on what the content is, not where the content is.
This is a paradigm shift.
Imagine that you share a viral video with everybody in the office. The way the video would be retrieved today starts with everyone clicking on the link to the video. This then takes them to the website that the video is hosted on and every single one of your coworkers’ computers has to individually reach out to the website’s server to download the video. This situation puts enormous strain on our internet infrastructure and is why phrases like the “Reddit hug of death” exist today.
With IPFS, we can do things differently. Instead of a website’s server needing to send the video to every single person that’s trying to view it, IPFS can simply look for the video’s IPFS hash. Think of the IPFS hash as the id for the content. Again, this hash is based on what the content is, not where the content is. Instead of fetching that content from the website’s server, the browser will ask the IPFS network for the content that corresponds to the IPFS hash it was just given, regardless of where it is stored.
Keeping with the example above, if everybody is downloading the exact same video, they can now retrieve it from a peer within the office. Instead of each person retrieving that video from a server across the internet backbone, the first person to download the video could just share it with everybody else in the office. Because your peers in the same building are likely able to deliver the video faster than the website’s server, you’ll fetch it from them without touching the internet backbone.
What’s the Catch?
There is a catch to all of this. The good news is that this catch isn’t a technical one but simply one of industry adoption.
As IPFS is still a young technology, your fellow officemates likely won’t be running their own IPFS node on their computer. Browser extensions such as IPFS Companion allow users to connect their browser directly to IPFS, but this setup still requires some technical expertise.
User adoption will most likely take place behind the scenes as more applications start to integrate IPFS into their technical stacks and major browsers integrate the IPFS protocol into the browsers themselves.
You’re starting to see some behind the scenes work through the JS-IPFS project which allows developers to run an IPFS node as part of their javascript based web application. Such integrations will be critical to developer adoption of IPFS.
This is fairly similar to how the internet protocol HTTP gained adoption. Not through end users themselves, but by products figuring out how to utilize HTTP to deliver a product to those users. Similarly to HTTP, most users who use IPFS in the future won’t know or care that they’re using IPFS. They’ll just enjoy the benefits of a better / more stable web experience.
How Do We Get There?
More Applications Need to be Built
Great technical advancements have little impact unless they actually get incorporated into projects.
A few examples of projects that IPFS pairs well with are:
Infrastructure Needs to be Built
You’re starting to see this built out through a variety of projects like Pinata and a few bigger players like CloudFlare. As more IPFS nodes and supporting infrastructure comes online, the network will continue to grow stronger. Andrew Hill from Textile wrote a great piece on this topic: Adding the next million peers to IPFS
We Need Major Browser Support
Like I mentioned above, we need native browser support for IPFS. With major browser support comes a better developer experience. It will be easier for developers to develop applications with IPFS because they’ll have less hurdles to jump over. Node packages such as JS-IPFS are a great start but with browser support typically comes Web Standards that make the development ecosystem much more stable.
And, with a better developer experience comes a better user experience. We didn’t get to where we are overnight. It took years of developer tools that continually iterated on what had been learned from the previous generation of tools. The advanced developer frameworks we have today allow developers to build performant, user-friendly applications thanks to much of the heavy lifting being done by these tools.
Conclusion
IPFS is becoming more prevalent in decentralized applications for good reason. However, IPFS isn’t a magic cloud that we can freely upload all of our data to. In reality, data on IPFS is currently being managed by many applications in a way that’s quite similar to centralized server / database paradigms.
So, why should we use IPFS? In addition to the benefits provided to decentralized applications, IPFS helps solve some very real issues with our modern web infrastructure. These are issues that will need to be addressed as our society continues to consume data at a rapidly increasing rate.
However, for IPFS to truly be successful, we’ll need a few more things. Applications using IPFS need to be built, better supporting infrastructure needs to be built, and we need major browser adoption. These advancements won’t happen overnight, but they are happening and I’m excited for what the future will bring.
