Tags

, , , ,

One of the main problems in making a site public on a P2P network is its accessibility depends on a running server process on the initial host, until the files are seeded by other peers on the network. Fortunately, some of DAT’s developers operate a hosting service called ‘HashBase’, which we can use to make our sites persistent.

A site can be developed and uploaded to HashBase very easily from within Beaker’s integrated editor. Mine is a very basic site using Bootstrap.css. When done, review and publish the changes, so the finished article is displayed in the browser at the unique address.

Next, register an account with HashBase.io. There isn’t much in the way of account configuration here (it essentially provides a certain amount of storage associated with an account) so we can get straight to uploading the site’s files.

My site wasn’t accessible after my first attempt, and I assumed it just required time for the changes to propagate on the network. It turned out that dat.json needed to be modified in order to enable HashBase to host it – this isn’t mentioned on the Hashbase site, but instead in their documentation on GitHub. I learned the following lines must be added to dat.json:


{
"title": "SAPPHIRE-DAT"
"dir": "./.hashbase"
"brandname": "Hashbase"
"hostame": "hashbase.local"
"port": "8080"
"csrf": "true"
"bandwidthLimit":
"up": "1mb"
"down": "1mb"
}

This was enough to make the site reachable at dat://sapphire-dat.hashbase.io after re-uploading the archive. Reviewing and publishing changes in Beaker might cause dat.json to be reverted to its default, so it might be worth copying the above into another file called ‘template.json‘.

There are other recommended configuration options that might be important if we want to host something more than a static site. If you want to enable HTTPS, HashBase can sort the certificate provisioning if the following lines are also added:


"letsencrypt":
"debug": "false"
"agreeTos": "true"
"email": "myname@example.net"

Hashbase uses JSON Web Tokens to manage sessions. You absolutely must replace the secret with a random string before deployment.


"sessions":
"algorithm": "HS256"
"secret": "RANDOM-STRING-HERE"
"expiresIn": "1h"

Advertisements