Federated Wiki Technology

This wiki does the sharing in the browser, not the server like most every other wiki ever. Let's look at the technology that makes this work.

Wiki relies on the perfect storm of creative commons, cross-origin resource sharing and javascript object notation. We can write this as a formula.

Everything we write we contribute to the commons using the attribution and share-alike license. This is all automatic so it is no extra work for you, except for figuring out how to live this way, which is hard. website

Javascript in the browser lives with some shackles designed to keep malicious code at bay. We add headers to everything we serve that say it can be read and used by javascript from other origins. This means we can share in the browser. website

The object notation describes key-value pairs where the values can be arrays or more objects or strings or numbers or a few other things. The inventor says there is never going to be a version two so everything we write in version one keeps working. Cool, eh? website

If you want to own and operate a federated wiki server then you will have to master a few skills beyond logging in.

You will need a recent install of node.js. Bundled with a typical install is the v8 javascript interpreter and the npm node package manager. website

You will need a server too. We've had good luck renting servers from Digital Ocean. They are quick to setup and inexpensive to run. website

You will probably want a domain name for your server unless you already have one which you can reuse several ways. I've been happy registering domains at Name.com. website

You will want to claim every site you make if they appear on the open internet. We use Persona to manage the passwords you will use to prove your sites are your own. website

Developers will want to download source from github for the parts of wiki that they will be modifying. We've moved active development to an organization called fedwiki. You will find all the pieces there. github

We code both client and server code in the CoffeeScript dialect of Javascript. This provides many conveniences but does add another build step in most cases. website

We build production files with the make replacement Grunt. The node package manager will load Grunt plugins we use in our builds. website

We've used a variety of testing frameworks but find that most new code falls under our build-time tests written and run with Mocha. website

We use jQuery where it helps but we don't expect it to make our application work everywhere. We assume html5 in most cases. We use jQuery UI for drag/drop. website

We've done several plugins with D3.js for building and manipulating SVG graphics. website