IPFS for your static site

Background

For this post, we will assume that the user has some familiarity with IPFS and the underlying idea behind it. For background information on this technology please check out the following link:

Prerequisites

Relative links

When using IPFS to host your website, you will need to use relative links versus absolute ones in order to facilitate correct addressing. Let us see an example of why this is so.

A user wishing to access /ipns/L6Q6m8NXRTmVMxkL5Rc77DvaaCA2QyQZ9iRyHjouRyjfaX/blog would result in the correct file being returned, however, should a link on the page back to the homepage use an absolute link such as <a href="/" title="homepage">Take me home</a>, this would resolve to / instead of /ipns/L6Q6m8NXRTmVMxkL5Rc77DvaaCA2QyQZ9iRyHjouRyjfaX which is what you would expect if you are used to hosting your website on a domain such as x82.io

Self-contained folder

All of your website content should be contained within a single folder with a standard index.html entry file.

Deployment

There are many ways to interact with IPFS, including using the built-in CLI, however, we endorse using ipfs-deploy which exposes ipd on your command line to handle the deployment. Deployment becomes as simple as running ipd in the root of your static site generator project, in which case it automatically searches for the appropriate folder name, such as public,static, etc.

$ ipd public -O -C
√ Directory x82_test weighs 374.1 KiB.
√ Added and pinned to Infura with hash:
i QmZjjpcsD5YCP5sJsDU3M9yn6WVeuqLynrSbaMZcgRkXse (​https://ipfs.infura.io/ipfs/QmZjjpcsD5YCP5sJsDU3M9yn6WVeuqLynrSbaMZcgRkXse/​)
QmZjjpcsD5YCP5sJsDU3M9yn6WVeuqLynrSbaMZcgRkXse

Pinning

Once you have deployed your website to IPFS, those files are available so long as there is a host willing to share them. If you are willing to provide an always-on solution to provide access to these files there is no problem, however, those running static sites are usually not willing to have a compute host dedicated to providing these files. This is where pinning comes into play. An external service such as Infura, Pinata, Fission, etc, offers services to host these files so that there is always at least one seeder that a user can use to request these files.

When using ipd these pinning services are included by default.

DNSLink

Since IPFS generates a new hash-bashed address based on the content of the primary index page of our website, users of your website might have a stale version. This is a problem for any website that expects to be updated at some point in time. To circumvent this problem, IPFS uses the concept of DNSLink which allows us to use a DNS TXT record as a mutable resource to point to our immutable hash. Should we wish to host our website on say, x82.io, we would create a TXT record as_dnslink.x82.io at our subdomain. We would then populate the value of the record with the ipfs hash of our website, eg dnslink=/ipfs/.

When users of your site use an IPFS client, it will perform a DHT lookup, and should the initial request URI not match an acceptable hash regex, and will then perform a rewrite should it find an acceptable DNS record for the DNS link.

/ipns/x82.io/blog
->
/ipns/L6Q6m8NXRTmVMxkL5Rc77DvaaCA2QyQZ9iRyHjouRyjfaX/blog

This process can be automated via CI/CD by taking the root hash and amending the _dnslink TXT record.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store