ParanoidPenguin.net goes decentralized with IPFS

As a longtime believer in a decentralized web, I’m glad to finally have been able to put this blog on the InterPlanetary File System. It’s been a fun little side project, and it allowed me to cut my teeth on IPFS.

However, judging from my own experience, I’m not entirely sold on IPFS being the web of tomorrow. At least not today ;-)

What is IPFS

Wikipedia, as usual, has the gist of it:

The InterPlanetary File System (IPFS) is a protocol and peer-to-peer network for storing and sharing data in a distributed file system. IPFS uses content-addressing to uniquely identify each file in a global namespace connecting all computing devices. Source: Wikipedia.

This article does not aim to be a technical dive into IPFS, so I’ll leave it at that. To learn more about IPFS, I would encourage heading over to IPFS.io and explore their tutorials. I should also point out that I’ve only been using IPFS for a couple of weeks, and I am by no means an expert on the topic. This write-up is merely a summary of my thoughts and experiences on deploying my blog on IPFS.

Why host your blog IPFS?

That’s a hard question to answer. To be honest, I’ve found that most of the advertised benefits of IPFS are (currently) more theoretical than real. I’m also concerned that the entry-level is far too high for the average user to hold out any hope that IPFS will achieve mainstream adaptation.

In that regard, I would not be surprised if the majority of content on IPFS are consumed through public IPFS gateways.

So why did I decide to put this blog on IPFS? Because I’m a geek, and I could not resist going head-first down this rabbit hole. That being said, I do believe in the potential of IPFS.

Issues with hosting on IPFS

Just like the cloud is just someone else’s computer, so is IPFS. Or more accurately: IPFS is someone else’s computer in addition to yours.

When you publish to IPFS there is no guarantee that anyone will be interested in hosting your content. When another node (a node is both a client and server) requests your content, it will only be cached until the node runs its garbage collector to free up more storage.

To store content permanently on IPFS, you or somebody else needs to pin it. And even then, should the content only be pinned on your node, it’ll disappear when the node goes offline. For all practical purposes, you should consider your IPFS hosted content as a torrent nobody else in the P2P network is interested in seeding.

Issues with hosting a local IPFS node

Like I previously mentioned, when your node (computer) goes offline, there is a high probability that your content will disappear with it. There are also obvious privacy concerns with being connected to a P2P network.

Every peer sees your IP address and could potentially discover what content you’re sharing. Additionally, IPFS produces a high volume of network traffic and consumes quite a bit of bandwidth.

Issues with hosting a dedicated IPFS node

To better guard my privacy and provide reliable availability for my content, I decided to deploy a new VPS to host my IPFS node. Then I thought, why not configure and host my own public gateway as well?

I believe the majority of users are interacting with IPFS through public gateways, and in my experience, pulling my content from a public gateway was an abhorrently slow experience.

Sadly, I discovered the murkier side of dealing with (in theory) uncensorable content and pulled the plug on my public gateway project. For now, at least, the gateway is restricted to serving content from my local repository.

Beam me up, Mike Pence

Launching a decentralized website unexpectedly, and somewhat ironically, brought me back full circle. My decentralized blog runs on a cloud server and is addressable by a domain name. Content gets delivered by using Nginx as a reverse proxy in front of the IPFS gateway.

With that in mind, did I succeed in making my website futureproof, or have I just complicated everything by strapping on IPFS as a new backend?

I should also point out that the paranoidpenguin.net domain does not use IPFS. I’ve mirrored a downscaled version of my blog on IPFS and simultaneously made it available over HTTP using the domain paranoidpengu.in.

That’s not how you should use IPFS

Fair enough, I got just the thing for you. Please head over to my gateway for a list of resources enabling a native experience.

However, I tend to believe that most people won’t bother with installing additional software to gain access to IPFS. And even if they did, they might find the native experience to be as slow and unreliable as I did. That, unfortunately, is most certainly a dealbreaker.

These days everyone expects a website to load within a few seconds. What fool is gonna sit idle and wait a minute to find out if the requested content was discovered over IPFS.

To infinity and beyond

I’ll try to keep my IPFS node online and keep the “IPFS blog” in sync with my other editions (clearnet and hidden services). To be honest though, I really don’t see any advantage of hosting on IPFS at the moment.

Anyhow, I had a lot of fun trying to figure this thing out, and when it comes down to it, I just want to be entertained.

By the way, if you’re hosting your blog on IPFS then feel free to ask me for a pin.