Today, I’m doing a deep dive into multi-writer hyperdb (the technology that will be at the heart of what we’re currently calling “indie site”) by dissecting Jim Pick’s dat-shopping-list demonstration (blog post, editable/forkable online demo; glitch).
I thought I’d document my process.
First things, first:
I fork the git repo on GitHub and clone it and add the original as an upstream remote:
git clone firstname.lastname@example.org:aral/dat-shopping-list.git git remote add upstream https://github.com/jimpick/dat-shopping-list.git
Always fork a repo even when you’re just looking at it. Why? Because:
a. It’s easy to do
b. If you find a bug, etc., you can easily create a branch and submit a pull request (i.e., you will help strengthen the commons)
c. If the original repository goes away, you still have a copy. If it‘s a repository that I am going to be using in a project, I’ve also started to get into the habit of forking it on our own GitLab instance (source.ind.ie) – see https://source.ind.ie/forks. I’m calling this “fork-first dependency management” because it sounds just pretentious enough to maybe get traction in the web community
Seriously though, git is decentralised. It’s a great shame that we’ve re-centalised it with GitHub. Every time you fork elsewhere, you’re again strengthening the commons.
Then, to get a feel for the culture of the project, I open up the project.json file and look through the dependencies:
cat project.json | grep dependencies -C50
I open each dependency …
[YAK SHAVING] OK, why am I doing this on Discourse, when I just demonstrated how you can live blog on the peer-to-peer Web? I’ll be right back*, I just need to set up my own live blogging system (start time: ~9AM, Friday, June 15th)…
Follow along live on this Mastodon thread: https://mastodon.ar.al/@aral/100207852262520843
And, when it’s ready, all my live blogs will go on https://live.ar.al