Inspired by Mike Caulfield’s tireless evangelism for personal wikis, I decided to set up an instance of Smallest Federated Wiki and not rely on someone else’s farms. Mike has been kind to set up sandboxes for us to play in, but much of the point is to have your own instance that you control.
The first and biggest hurdle is that Smallest Federated Wiki (SFW) won’t run in shared hosting, and some sort of dedicated server is required. A VPS isn’t that hard to find, but I’m thrifty, and have a computer that’s on most of the time in my house. I proceeded to download NodeJS and install a local wiki, which seemed to work fine, but it was only partly federated. I could fork pages in, but it wasn’t on the public web so nobody else could fork from it.
I had, in my explorations of the IndieWeb movement, discovered pagekite, which uses a python script to reverse tunnel from your computer to a subdomain.pagekite.me address. The service is pay what you want, but less expensive than most VPS’s. In order to do this more safely, I decided to run the SFW instance inside a debian Virtualbox VM.
Once the VM is up and running, install nodejs and npm
apt-get install npm
Then use npm to install wiki and pm2
npm install wiki -g -f
npm install pm2 -g
. For some reason I can’t get wiki to start from the shell so I had to use pm2 to launch it. Find the wiki index.js. On my VM it was /usr/local/lib/node_modules/wiki/index.js . I then typed
pm2 start ./index.js
and a simple web connection to localhost:3000 gave me a live SFW node.
After downloading the pagekite script and establishing your account
pagekite.py --signup you launch with
pagekite.py 3000 http://yoursubdomain.pagekite.me The 3000 is there because that is SFW’s default port.
I could now see my VM instance through the pagekite URL and fork from it, but there was still one problem. SFW uses Mozilla Persona to handle editing privileges. I could claim the wiki and login when I was on localhost, but trying to connect via the pagekite URL generated a login error. So my wiki was viewable from anywhere but editable only from the console. I submitted an issue to the SFW Github repository, and the helpful folk there explained that Persona expects certain ports and urls. To make my wiki editable from everywhere required:
pm2 stop [id of wiki process]
pm2 delete [id of wiki process]
pm2 start ./index.js -- -p 3000 --url http://mysubdomain.pagekite.me
You apparently have to tell SFW what URL and port you are running on for Persona to work.
Also note the — between the script path and the arguments that will be passed to the script.
One of the frustrating things about SFW is that individual instances are distinguished by a color gradient favicon, It’s often hard to remember which gradient belongs to whom. Once you have a local instance, you can fix this. SFW stores your files in /home/username/.wiki . The favicon.png is stored in a status subdirectory of .wiki. Just replace that .png with a square PNG file of your choice with the same name (favicon.png). I’m not sure what the maximum size is, but 64 X 64 worked.
I forgot to mention that paying for pagekite allows you to use CNAME records to map your pagekite service to a domain or subdomain you control. I haven’t done that yet as I’m still in the free trial period. I didn’t want to pay until I was sure I could make it work.
@jasongreen Cool!!!!
@holden By the way, what license has your brother put on the five star plugin?
Thanks for writing this up. There are lots of moving parts here, too many except for pioneers. We’ll chip away at them over time.
Imagine my surprise when your customized favicon showed up in my ‘neighborhood’. Federated wiki already has a fair amount of mechanism around favicons, or flags as we call them. You will appreciate the automatic (and constrained) diversity about the 10th time you make another wiki.
Now Ward has me wondering if I’ve contravened some project design principle with my favicon swap.:-) His point about multiple wikis is well taken, but I went off to solve the problem I have rather than that one.
It’s been my experience that in all but the smallest neighborhoods, the two color gradient of the default favicons isn’t sufficiently distinct for me to distinguish consistently which icon belongs to which wiki without mousing over. I imagine the challenge would be even greater for someone who was color blind.
I also came at much of this from the start point of creating, maintaining and controlling my digital identity. I’m a regular twitter user and have found that I often find a particular post in my timeline by scrolling down until I spot the user avatar. I suppose my experiment was an attempt to be able to do that in SFW space.
I am starting to think of a personal wiki as a better replacement for the 17th century commonplace book than a blog. My plan, at least for the time being, is to use the SFW instance I’m attaching to pagekite as my primary SFW presence. As such I want to identify it with something more consistent and distinctive that the gradient of the default.
I suspect that I may make other instances for which the default behavior meets my needs.
Yes, design principles have and will continue to emerge. Some have even been abandoned. Experimentation is highly valued. Thanks for performing the experiment.
I was almost believing in the Way of the Gradients until I noticed, now that there are more than a few ppl in FedWikiHappening, that at least two other wikis have the same gradient as I.
Now that’s a problem.
I can see both sides of it. Both Mike and Ward have at various points established multiple farms for different projects. In that context using an avatar could itself be confusing. The gradient model is hard with fedwikihappening because we have a huge neighborhood, much larger than most users would have in day to day practice. I tried the avatar photo thing because my model here is to establish one non-farm instance where all of my fedwiki pages will live. I think that’s the scenario in which something like an avatar image makes the most sense.