 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Most of the conversations I have about Interplanetary File System (IPFS) start and end with its relationship to blockchain technologies. While there is a great deal of utility in hosting media assets for blockchain-based games and NFTs leveraging the decentralized nature of the IPFS protocol, its utility extends beyond Web3 implementations. The decentralization built into IPFS is available to any application development and has the potential to change the way web applications are built and scaled.
The grandly named “Interplanetary File System” was originally conceived by Protocol Labs founder Juan Benet, as an alternative approach to HTTP in addressing content. HTTP is based on routing to a file location. In theory, the file at that location could be different every time it loads in a browser. An IPFS address points to a specific cryptographically verifiable file, meaning that a modified version of the file would be referenced with a different address.
One of the ways this plays out is that the address never changes, even if the content is temporarily unavailable. Company A could host the contents of an IPFS address but later go out of business. If Company B comes along and hosts that same content, the address will return the same result. If there is a period of time where no node with the content is available, the content becomes unavailable until a node hosting the content comes online.
In an interview with The New Stack, Dietrich Ayala, Browsers and Platforms Ecosystem Lead for Protocol Labs, said, “One of the main differences between IPFS and HTTP is that when something goes 404 in HTTP, only one party can be serving that original URL. Changing file names breaks HTTP addresses. With HTTP, one party providing the data is the ceiling of availability for that data; but with IPFS, one party serving the data is just the starting point. Availability and resilience goes up as more nodes store the data.”
With all the challenges mentioned here, why would developers consider using IPFS instead of sticking with the HTTP stack? “The current end-to-end workflow for the full stack developer is incredibly complex,” said Ayala. “It requires a chain of services. There’s an opportunity for instant gratification in the workflow for publishing to IPFS. If everything works correctly and your node is available, you can add your application to your local node, give someone the address, and they can load it immediately. That’s very different than needing to register a domain name and update SSL certificates, or maybe an NPM module breaks on deployment and a week later your code works locally, but still can’t be distributed. The instant gratification you can have when you self-publish is really powerful.”
Protocol Labs provides some tools for you to get started with IPFS. You can run a node either via their desktop application or via a command line interface using the Go implementation of IPFS. Building with IPFS is possible using either js-ipfs in combination with Node.js, or via the Go implementation of IPFS known as Kubo. There’s also a sidecar IPFS Cluster distributed application that allows for easy deployment of files to multiple nodes, providing instant scale when deploying your app.
IPFS sounds like a great solution to many of the web’s fundamental limitations, but it also sounds a little too good to be true. I asked Ayala about the challenges of adoption. He highlighted a few core issues starting with the success of HTTP as a protocol.
“HTTP is the air we breathe. It’s everything we use to be able to talk to other computers at this point. AJAX and REST APIs really cemented the idea that computer-to-computer communication, not just person-to-person, is happening through HTTP APIs. When you are asking 28 million plus developers to reevaluate the entire OSI stack and how networked applications work, it’s a really interesting challenge.”
Cryptographic education is another challenge to adopting new protocols like IPFS. There are very few instances where developers and users are expected to use hashing as part of their daily lives. “If you download Linux distros,” Ayala explained, “you may be familiar with seeing the MD5 hash, and you may or may not actually verify that the hash matches. Outside of that scenario, do you ever need to deal with hashing at all? There’s maybe the bit of code you write to save passwords to a database where you aren’t storing clear text. Outside of those two instances, it’s not part of the daily developer experience. With IPFS, that’s at the core of how we address data everywhere.”
This verifiability has ramifications for both developers and users and is ultimately the reason why the location data being stored in the IPFS approach no longer matters. If someone starts with a photo, edits that photo, and reposts it in an HTTP world as if it were the original, depending on the number of pixels that are modified, a human eye might not differentiate that it is no longer looking at the same image. From a verification standpoint, IPFS would treat that modified image as something new.
“In the age of misinformation and disinformation, that matters” Ayala said. “There’s a large educational barrier we need to overcome in terms of how developers work with data, how they can cryptographically verify, and also end users thinking about what it means to own their own data.”
This brings us to a third hurdle to IPFS adoption, which is also another fundamental difference between the protocols.
Ayala said, “If you load a website through IPFS, it’s stored in your IPFS node. You have it until you decide you don’t want a copy anymore. The way the web works today, all the components of a website are stored in your browser cache, but browsers don’t treat the browser cache as something that belongs to you. A cookie set by the publisher dictates whether something is or isn’t deleted from your browser cache. That’s a pretty significant change in the model of how we think about application distribution.”
There are some potential challenges in developing for a model where the user decides whether they keep or purge website application data. As new features are rolled out or bugs are fixed, users should see significant benefit to adopting the new version, but IPFS allows the old version to persist. On the flip side of that equation, when a website removes content or makes portions unavailable, a user may not purge that data from their IPFS node in order to maintain access to something the developer no longer supports.
One additional challenge with adoption is the way web browsers are designed. A browser is fundamentally designed as a vehicle for the HTTP protocol and a request-response security model. Browser permissions and privacy are designed around HTTP. This is one of the core challenges of making adoption of a new protocol like IPFS simple.
Because of this limitation, Protocol Labs engaged Igalia, a web consultancy with experience in building browser technologies, including MathML and CSS Grid. Igalia spent the past year refactoring some parts of the Chromium code base to include support for protocols that are not HTTP. “We worked with Igalia to fix a number of web compatibility bugs across different browsers,” Ayala said, “so that the way the origin security model applies to localhost addresses is done consistently, so web developers can know that their code is browser compatible.”
The Brave browser, which is based on Chromium, was among the first browsers to directly integrate IPFS. Brave’s integration was primarily focused around the security model and how to communicate tradeoffs.
“The Brave security teams had previously evaluated and audited the integration,” Ayala told me. “They already support Tor. The IPFS model is very similar to the Tor integration in Brave. Brave downloads an IPFS node once the user enables that feature, spins that node up and runs it as a separate binary, sends messages back and forth over interprocess communication, and streams content back into the web rendering engine.”
As of this writing, this change to protocol support is not yet in the release builds of Chromium, but it is expected soon. The work done by Igalia to expand protocol support in browsers has benefits beyond IPFS. Addressing some of the challenges that faced IPFS integration into browsers fundamentally changes the way browsers interact with non-HTTP protocols, which theoretically means both existing protocols, as well as yet-to-be-invented ones, also benefit; and potentially have a faster path to adoption. In the meantime, IPFS offers extensions for Chrome and Firefox, with native support in Opera and Brave.
If you’ve been holding off on investigating the potential of Web3 technologies because you haven’t seen a use case for blockchain in your own work, I encourage you to take a look at IPFS. While it can be paired with blockchain technologies, it stands alone as a peer-to-peer protocol with the potential to address a number of real challenges.
Regions struggling with reliable connectivity to the broader internet could create localized redundancy by running IPFS nodes. It also makes a viable solution for improving resilience in the face of catastrophic outages, which is something that government and essential services could be better prepared for. As Ayala puts it, “We’re at a crossroads right now where we have some off-the-shelf technologies to allow developers to build applications that serve their users first over specific companies first in specific countries. That’s a huge opportunity for internet users to take advantage of things that meet their needs more than one-size-fits-all protocols or platforms.”
