# wiki

Federated Wiki

npm install wiki

# Federated Wiki (Node.js server version)

The original wiki was written in a week and cloned within a week after that. The concept was shown to be fruitful while leaving other implementers room to innovate. When we ask for simple, we are looking for the same kind of simplicity: nothing to distract from our innovation in federation. -- Smallest Federated Wiki

Since the earlier creation of the node version, to complement the original Ruby implementation, there has been a risk of the two versions diverging. A first step to prevent divergence was to extract the client code into the wiki-client. This wiki-client was then used by both the Ruby and Node servers. However, with both server repositories retained the static components of the client, together with the plug-ins there remained some risk of divergence.

In this latest version of the node version of Federated Wiki, we continue by:

• including all the client components in the wiki-client, and
• moving all plug-ins into their own repositories, see below for a list.

When we originally extracted the wiki-client, we included it back into wiki whilst building the wiki package. This had the unforeseen consequence that when creating an updated wiki-client it was also necessary to create a new version of the wiki package for the updated client to be available. To avoid this we no longer include wiki packages in the package for the server.

Here we have a new wiki repository, and package, which only exist to pull together the federated wiki modules (wiki-node-server, wiki-client, and plug-ins) and start the server.

## Using Federated Wiki

Learn how to wiki by reading fed.wiki.org

The quickest way to set up wiki on your local machine is to install it globally with npm:

$npm install -g wiki$ wiki


Visit localhost:3000 to see your wiki. If you choose a host visible to the internet then others in the federation can use your work.

## Server Options

Options for the server can be passed in many ways:

• As command line flags
• As a configuration JSON file specified with --config
• As a config.json file in the root folder or cwd.
• As env vars prefixed with wiki_

Higher in the list takes precedence. The server will then try to guess all unspecified options.

### Datastore options

A number of datastores are supported. Use the --database and --data options to configure, or use the config.json.

The default location of the datastore is ~/.wiki, which contains two sub-directories pages and status:

• pages is used with flatfiles, or leveldb, to store your pages, and
• status stores the site's favicon, and a file containing the identity (email address) of the site owner.

#### flatfiles (default)

The default path to store page data is in a "default-data" subdirectory of the install directory. You can override it like this:

$wiki --data FILESYSTEM_PATH  #### mongodb The mongodb connection arguments are specified as follows: $ wiki --database '{"type": "./mongodb", "url": "...", "options": {...}}'


For convenience the url will also be read from MONGO_URI, MONGOLAB_URI, or MONGOHQ_URL. This smooths the Heroku deployment process somewhat.

The mongodb datastore allows for a graceful upgrade path. If a page is not found in mongodb the flatfile datastore will be consulted.

#### redis

The Redis connection arguments are specified as follows:

$wiki --database '{"type": "./redis", "host": "...", "port": nnn, "options": {...}}'  The Redis datastore allows for a graceful upgrade path. If a page is not found in redis the flatfile datastore will be consulted. #### leveldb The leveldb datastore uses JSON encoded leveldb format and is configured by providing a filesystem path: $ wiki --database '{"type": "./leveldb"}' --data FILESYSTEM_PATH


The leveldb datastore allows for a graceful upgrade path. If a page is not found in leveldb the flatfile datastore will be consulted.

##### Example config.json for Redis
{
"database" : {
"type" : "./redis",
"host" : "your.redis_instance.com",
"port" : 6379,
"options": { "auth_pass" : "all_mimsy_were_the_borogroves" }
}
}


## Participation

We're happy to take issues or pull requests regarding the goals and their implementation within this code.

A wider-ranging conversation is documented in the GitHub ReadMe of the founding project, SFW.

The contributing page provides details of the repositories that form the node.js version of Federated Wiki, together with some guidance for developers.