tcyrus@tcyr.us ~ $

IPFS + Jekyll = Profit?

tags
#IPFS #Jekyll
published

Introduction

You may have heard of the push towards a decentralized and Peer-to-peer internet for the future at this point. This push has been supported by both individuals and companies alike.

I first heard about it a couple of years ago during a talk by Vint Cerf (one of the “fathers of the internet”) while working as a Guest Researcher at NIST. The specific protocol he was talking about was IPFS, the InterPlanetary File System. After looking into other decentralization attempts, I found IPFS to be the best suited for my needs.

Current Options

The primary concerns with the technology available is as follows:

  • Support

    How active is the community? Are there any companies adopting / backing the software?

  • Maintainability

    How much effort does it take to setup and update a site?

  • Visibility

    How fluid is the user experience? Does a regular user need to worry about P2P software when accessing my site?

Here are how the current options stand up:

  • Dat

    The Dat protocol seems interesting, but there are issues which I would like to see resolved before I use it. The versioning approach to updating sites fixes the main issue that I have with IPFS Maintainability. The only issues I have with it is the reliance on Node.js and Beaker Browser.

    The server end of Dat is reliant on Node.js (and a massive chain of custom packages). There is an unnoficial implementation in Rust currently in the works.

    Beaker Browser barely deserves to be called a web browser; it’s a bad Electron app pretending to be a web browser. Copy and paste functionality is broken and the browser crashes every 10 minutes for no reason. As of writing this, Beaker is the reccomended (and only) way to easily access a website hosted using Dat.

    I hope that either DatPart becomes fully flushed out local gateway (similar to ipfs-companion) or Brave finishes adding Dat support, because I currently don’t see any future for the Beaker Browser.

    EDIT - 8/7/2019: There’s an open issue for dat-desktop (see dat-land/dat-desktop#518) to implement a local gateway. Here’s to hoping it goes somewhere.

  • ZeroNet

    The depenency on Namecoin for DNS adds an economic barrier which I don’t feel like dealing with right now for experimentation. IPFS and Dat allows me to use my current domain using DNS entries; ZeroNet does not. If I had to use a cryptocurrency-based registrar, I would prefer to use ENS as I’ve read more about it than Namecoin.

  • Freenet

    Last updated March 2000

  • Solid

    Solid is way too new and relies on standards which are still under review. As of writing this, the primary (and only) server implementation at the time of writing this is the node-solid-server, which is a similar behemoth to the Dat implementation.

    The push towards using Linked Data is promising, but seems to have slow adoption due to low benefit of implementation. All that Solid needs to be the next big thing would be:

    • A new server implementation which is easier to use and has UI management tools
    • Some usefull example apps

    Another thing to note is that Solid is taking a different type of decentralization approach to the other solutions on this list; one that puts a higher emphasis on privacy than anonymity.

  • Blockstack

    If you get past the fact that their entire site (including docs) looks like it’s trying to get your money for some sort of “groundbreaking” ICO offering (which they did do at one point), the technology seems pretty interesting. The structure of how it all works still has too many smoke and mirrors for me to use it for a personal project. Also, the Dapps structure used by Blockstack is structured towards fully-fledged applications and leaves litte potential for integration for personal projects.

    I place Blockstack in a similar group as Solid, as they both are taking a data centric approach to decentralization rather than a content centric approach. Blockstack’s Gaia storage system looks neat and I hope to use it (preferrably without Blockstack) in the future.

  • IPFS

    IPFS has an active community and great server and client implementations. Cloudflare is currently hosting their own IPFS gateway which (if everything worked) is currently powering this site. The main issues I have with IPFS is versioning and anonymity.

    IPFS doesn’t handle versioning as well as something like Dat does. Here’s a brief explanation on how this works. You have a folder which contains your site; this folder (as well as everything in it) is given a IPLD hash. Each file in IPFS is individually adressable, so the only think linking them together is the folder. I want to change one file in the folder. Now the hash for both the folder and the modified file has changed. I need to update the hash in my DNS to point to the updated version, because they’re 2 different sites as far as IPFS is concerned. Some workarounds have been proposed using IPNS or Decentralized DNS. Theres a good HackerNoon article on how these attemps have panned out so far here.

Jekyll

Jekyll doesn’t like working with relative links by default, which makes it annoying to deal with when it comes to IPFS. The reason for this is the way that the IPFS Gateways are structured. Here’s a link to a Hello World plain text file using my local gateway:

http://127.0.0.1:8080/ipfs/Qmc5gCcjYypU7y28oCALwfSvxCBskLuPKWpK4qpterKC7z

We can break this down into 3 distict parts:

  • gateway: The Gateway URL (http://127.0.0.1:8080)
  • protocol: Currently limited to ipfs and ipns
  • cid: can also be a domain using DNSLink with ipns

The point is, we can’t use absolute links or relative links which reffer to the base URL. All links and assets should work the same whether the page looks like this:

http://127.0.0.1:8080/ipfs/<cid>/

or this

https://blog.tcyr.us/

After browsing around, I crafted a minimal solution to my very specific problem based on other hacks that I found online:

{% raw %}
{% comment %}
https://gist.github.com/Ketrel/1f36fca6b4148f7263b3ee8fdb0923e7
https://redd.it/3nzvct
{% endcomment %}

{% assign _lvl = page.url | append: 'X' | split: '/' | size %}
{% capture relBase %}{% for i in (3.._lvl) %}/..{% endfor %}{% endcapture %}
{% assign relBase = relBase | slice: 1, relBase.size %}
{% if relBase == '' %}{% assign relBase = '.' %}{% endif %}
{% assign _lvl = nil %}
{% endraw %}

With this, I change all links I have from this

{% raw %}
<link rel="stylesheet" href="{{ '/assets/css/main.css' | prepend: site.baseurl | prepend: site.url }}">
{% endraw %}

to this

{% raw %}
<link rel="stylesheet" href="{{ '/assets/css/main.css' | prepend: relBase }}">
{% endraw %}

This snippet needs a temporary variable which I named _lvl to work. If someone can come up with a clever solution to remove _lvl please let me know in the comments, since Liquid doesn’t exactly have variable scoping implemented.

Conclusion

Jekyll does not like relative links by default, but it can be forced to work with them.

After finangling Jekyll into doing what I want, I realized that Jekyll isn’t the best way to do publishing on IPFS. The display layer and the data layer works best when separated, so that way changing the view doesn’t change the hash of every rendered file.

CMS.js, despite being a bit rough around the edges (templating), seems like a better choice for IPFS. If I was making a new site for IPFS, I would use either CMS.js or a custom solution based on Vue or React combined with something like Marked. I’m also going to try to modify CMS.js to use the Handlebars.js for templating and CommonMark for building.