How Graphite Manages IPFS Content Availability
When I decided to start working on version two of Graphite (which was released last week!), I knew IPFS would play an important role in making sure everything worked and worked well. In another post, I’ll explain the exact architecture of V2 that allows for people to use different storage providers and different authentication providers but still work together. In this post, I want to walk through how Graphite manages content pinning with IPFS.
But, let’s take a step back first. What is IPFS? IPFS — Interplanetary File System — is a p2p network that allows people to share content without the use of traditional cloud storage systems. Think about the way you share files today. You might add a file to Dropbox then create a shared link then send that link to a friend. The friend, depending on your settings, may or may not be able to access the file from that link without a Dropbox account. So, the friend might have to go through the steps to create her own Dropbox account just to access this file you wanted to share with her. You never wanted to involve Dropbox. You never wanted your friend to have to create a Dropbox account. You just needed a quick way to share the file. IPFS solves this by making it possible for you to share that same file across a distributed network of nodes (connected devices). Your friend can simply plug in the identifier for the file you shared and access that file. No accounts. No passwords. No middlemen.
That all sounds great, right? It is, but there’s a catch. While content added to IPFS is permanent in the fact that the identifier for the file you added will always be the same unless that file is changed, the availability of content is not permanent. Files are available as long as at least one node in the network has the file. If no nodes have it, your friend can no longer access the file you wanted to share. Now, for popular files that are shared with many people and downloaded frequently, this is not a problem. But for obscure files, or files that are encrypted and designed to be decrypted by a single person, there needs to be some other way of keeping that content available.
Enter the concept of pinning.
IPFS says “you should pin any content you consider important, to ensure the content is retained long-term.” Essentially, a pinned file is one that a node has chosen to keep available in perpetuity. As long as the node is online, then the content is available.
While, long-term, the goal is for Graphite to run its own pinning service (work has already begun with the release of the Graphite public IPFS gateway), it was important to me that for this initial release of V2, I worked with people who already had a great solution. This is where Pinata comes in.
Pinata is purpose-built for IPFS pinning. In exchange for a reasonable fee, Pinata will pin content you ask it to pin. What was most attractive to me was their simple API documentation.
For anyone who has worked with IPFS in the browser, this will come as no shock, but running a browser-based IPFS node sucks up a lot of memory. I wanted to avoid that for Graphite, so using something like js-ipfs was a no-go. That meant, in addition to simple pinning, I needed a service that I could send content to and they could relay it onto the IPFS network AND pin it. Guess what? Pinata does exactly that.
Pinata was built by Matt Ober and Kyle Tut. They both know what they’re doing when it comes to IPFS, and they are passionate about p2p technology. Most importantly, they are fantastic to work with. It was a painless process to get Pinata integrated into Graphite, and I’d encourage anyone looking for a pinning service to explore Pinata.
All of this is a long-winded way of saying that even if you are storing content on IPFS through Graphite, you can rest assured that your content will always be available.
If you haven’t tried V2 of Graphite yet, please give it a whirl here.
