This is a quick update regarding the permanence of IPFS content.

A helpful Twitter user @_liooil mentioned that this A-Frame scene referenced in a previous post was no longer resolving for him on the IPFS HTTP proxy / CDN (the URL starting with ipfs.io/…). I verified his statement to be correct — the scene was not resolving using the ipfs.io address, instead saying:

Path Resolve Error: Failed to get block for [hash]: context deadline exceeded

To debug, I ran the local IPFS daemon and was able to get the original index.html on IPFS to resolve, but the .obj file no longer resolved even with the local client. Hmm, that is odd.

After a few minutes of trying to access the original IPFS URL (both on the ipfs.io CDN and through the local IPFS daemon), the original IPFS hash started working again.

Here’s what happened:

• The original content was purged from the IPFS HTTP proxy / CDN due to lack of access. (Note this happened in about 2 months after originally posting the content.)
• When @_liooil and I both tried to access the files, the IPFS proxy couldn’t fetch the asset from its cache and couldn’t find a node to serve the file for that hash before a timeout, hence the “context deadline exceeded” error.
• Once I ran my local machine with the “pinned” content that I added, and then tried to access the HTTP IPFS proxy again, the content was re-cached at the IPFS HTTP proxy level and the URL started resolving correctly again.

So here’s an important question about permanence with IPFS — if I hadn’t run my local IPFS daemon (for example, if my computer had crashed or I didn’t migrate my IPFS local storage during an upgrade) would the files have been lost forever?

Quick answer: Yes, your files might be lost if your machine crashed.

Some other smart people @alfredofrlp and Esteban Ordano helped me with these answers:

• IPFS is NOT a magical free cloud storage service. Although the ipfs.io proxy helps to make IPFS content available to the web, its cache is not long lived, we think the default time for a node to keep an object in storage is 14 days. (In this case the files lasted approximately 2 months — perhaps someone accessed the files at least once every 14 days.)
• The only thing that IPFS (attempts to) guarantee is that the same file should be represented by the same IPFS hash. In other words, the files aren’t permanent, but the hash is permanent. If no node is running that has “pinned” (or is hosting the files represented by that hash) then the files are not accessible by other nodes or by the IPFS proxy.
• If someone else hosts the files on their node (whether by creating an identical file or “pinning” a file that you uploaded) then the files will be available.

So how do you make sure your content will remain accessible after being added to IPFS?

• First off, you could keep running your own node and make sure you’ve pinned the files you’ve added. (Pinning is on by default if you follow the directions in my previous post to add a directory.)
• Or, you could pay someone else to keep a node running with your files pinned — search google for “ipfs pinning service”. Two services I found cost around $0.14–0.15 per gigabyte per month. (That is quite expensive compared to AWS S3 starting at $0.023 per gigabyte per month. On the other hand, there is no additional fee for bandwidth.)
• Or, you can wait for FileCoin to become a thing. The problem of permanent storage is being addressed with FileCoin.