Use IPFS to host a Blog (or similar type of website)

[daviddias]

I'm specially interested in figure out a way (or ways) that we can start hosting Blog type of webpages on IPFS, without having to create a new framework for blogging, meaning that I'm focusing on statically generated blogs or blogs that compiled to a static generated version.

Even though a statically generated blog is a static website, it has some extra challenges to the normal static webpage hosting, simply because of the expectations that we have from a blog nowadays, such as searching for post tags or blog posts by date.

I'm writing this issue to put the ideas and discussions we've been having about it in one place, so that it also easier to see the progress.

These statically generated blog should be accessible and correctly rendered if loaded from a ipfs.io/ipfs/hash, ipfs.io/ipns/hash or somedomain.com/. It is important to this in mind, because the the fact that we might have some basePath means that loading assets (css, fonts, images) on a webpage through root path ('/'), becomes impossible. What this means is that we need a way to make the urls of the assets of a web page to be loaded through a path that is relative to itself ('../css' or '../../img/collection1' for eg).

Some options:

• precompile the whole blog
  • use harp to compile the blog. Checking if it is possible if it can handle the resolving of the basePath basePath kennethormandy/hb-casper#3
• have a native web app to do the blog generation
  • make this native webapp be a IPFS hosted WebComponent that loads posts and styling from somewhere else
  • make harp to be a browser app?
• leverage the MerkleDAG to create a more interesting data structure for the blog
  • https://github.com/ipfs/starlog

Some more context:

• Handling multiple paths for the same content ipfs-inactive/starlog#31

[edrex]

The only way to allow serving the same site tree under each of ipfs.io/ipfs/hash, ipfs.io/ipns/hash, and somedomain.com/ is to teach the build tool to use relative URLs for all <a>, <link>, <style>, <script>, etc tags. This includes rewriting intralinks in the post text if the text could be viewed at some other path such as an index page.

Setting the base tag and using absolute paths each require knowing at publish time what the base path will be.

I use Harp and I hit this when I set up the IPNS gateway proxy thing a couple of months ago. I'll report here if I find a way to do relative paths nicely with Harp. There are a ton of issues about that on the Harp tracker.

[edrex]

Conversion of absolute paths (path-absolute in the URI RFC) to relative could be done as a post-processing step, provided as a subcommand or flag of some standard IPFS static site publishing tool (diasdavid/ipscend).

An optional list of prefix patterns (^\/ by default) would allow converting sites with interlinks

• including the host: https://mysite.net/style.css
• or with a non-root base URL: /mysite/style.css

A quick search, https://github.com/tactivos/grunt-cdn does something similar.

The gateway's directory index currently uses relative paths (it's all a bit hairy)

[jbshirk]

https://github.com/Jermolene/TiddlyWiki5 (built on Node.js) should work well. Here is the default (documentation) site:

http://127.0.0.1:8080/ipns/Qme67efGcE9iX6r8Wk6CrHUsmWckLbnMHQ19g5YK15doUY/tw5.htm

This of course is read-only now, but for a single user it should be straightforward to deploy and update on IPNS. For multiple users, people can fork the site from Github, staging edits to be pulled and merged by the owner.

Since TW5 can use subfolders (wiki folders) this would be a better way to organize as well as have multiple subsites with different themes, etc. Even with a single page app, merges should work fine, as "tiddlers" (pages) are stored as div elements). Tiddler edit versions remain in the html app. Of course there are also categories, tags, and all kinds of useful plugins.

In my first experiment, I forked the whole TW5 repository, which is everything needed to build from NPM, and this offers many other capabilities, such as loading individual tiddlers, html, .md, and JSON as separate files, as well as updating TW5 itself. I deleted that fork, as I am nowhere near ready to deal with all that; I just wanted to see the site load from IPFS, and it does!

On a related question, I was wondering if using FUSE (such as MacFUSE) would automate the process of
ipfs add -r <sitedir>
ipfs pin add -r <sitehash>
ipfs name publish <sitehash>

My understanding is that currently IPFS FUSE is read-only. But is this where it is going?

[RichardLitt]

The only way to allow serving the same site tree under each of ipfs.io/ipfs/hash, ipfs.io/ipns/hash, and somedomain.com/ is to teach the build tool to use relative URLs for all <a>, <link>, <style>, <script>, etc tags. This includes rewriting intralinks in the post text if the text could be viewed at some other path such as an index page.

Isn't this what Jekyll on GitHub Pages does? Would we be able to implement Jekyll static blog posts through an IPFS hash? I'm curious.

[edrex]

@jbshirk I'm definitely interested in an IPFS backend for TW5, especially one with one file per tiddler modeled after the NodeJS backend. There's also interest [1] [2] from the Smallest Federated Wiki community (TW5's architectural soul brother, CC @WardCunningham @jasonkgreen).

My personal focus will remain on ironing out the basic static site publishing workflow. Experiments at closing the editing loop in the browser are sure to be worthwhile, but with the Javascript IPFS implementation a relativistic moving target (out of hell) anything that gets out in front of it is likely to be crushed into a fine interstellar powder.

My understanding is that currently IPFS FUSE is read-only. But is this where it is going?

This works (ref ipfs-inactive/faq#64):

ipfs daemon  --writable --mount-ipfs ~/Store/ipfs  --mount-ipns ~/Store/ipns
vim ~/Store/ipns/current/index.html

In my very limited testing writing to the IPNS FUSE implementation results in system instability, at least on OS X.

[jbenet]

yeah fuse is annoyingly unstable in osx at the moment. if anyone out there wants to help on this it would be much appreciated, we dont have the bandwidth to fix that right now but it would be very useful.

much of all of this can be done through APIs btw-- whether the cli or using https://github.com/ipfs/js-ipfs-api -- and yes the end goal is to have a node in the browser itself. much progress is happening here, and if people want it to come faster, help out @diasdavid

[Kubuxu]

Hugo (https://gohugo.io) has RelativeURLs option to make all paths really relative.

[hackergrrl]

Tiny lightweight IPFS blog CLI tool: https://github.com/noffle/ipfs-blog