fedwiki/wiki-server

Federated Wiki client and server in Node.js

Wiki-Server

Federated wiki node.js server as a npm module.

N.B. Following a code re-organization over the New Year 2013/4 this repository now only contains the code for the node.js server implementation. You will also notice that the GitHub reposistory name and location has changed, it is now fedwiki/wiki-server. It you have previously forked, and cloned, this repository you will want to update your clone's upstream remote to reflect this change.

This package is now published as wiki-server. The wiki package which depends on this package, to provide the federated wiki server, can be found as fedwiki/wiki.

---

Goals

Over its first two years the Smallest Federated Wiki (SFW) project explored many ways that a wiki could embrace HTML5 and related technologies. Here we will cautiously reorganize this work as small independent modules that favor ongoing innovation.

We proceed by dividing SFW first into large pieces and then these into smaller pieces as we simplify and regularize the communications between them. We now favor the node.js module and event conventions, dependency injection, and increased separation between the DOM and the logic that manages it.

Federated wiki's single-page application reads page content from many sources and writes updates to a few. Read-write server backends are maintained in ruby (sinatra) and node (express). Read-only servers have been realized with static files and cgi scripts. Encouraging experiments have exploited exotic service architectures such as CCNx content-addressable networks.

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.

License

You may use the Wiki under either the MIT License

wiki-server's Issues

the /system/slugs.json doesn't respect db other than flat files

This end point was part of some other plan that was never finished. It is like a fast sitemap. But it is implemented by globing over the page directory, not calling through db interface.

Persona login disable

I'm also having trouble with Persona login. (Running recently downloaded version on my WebFaction.) It may be related to https://github.com/WardCunningham/wiki/issues/36

Now I can live with this as, in practice, I could run a copy of this wiki on my local machine (where editing works) and sync the pages up to my public server.

However, I don't want someone else managing to grab the ownership if it turns out there's something specifically wrong with my Persona. So is there a way to lock the public server so no-one can grab it if I can't?

cheers

Phil

Unexpected Fields in Journal Actions

Here I describe an observation which concerns me but I don't yet know how to even understand it much less resolve it as an issue. This comes from Maha who had considerable trouble editing over a slow connection during Happening 1, especially before the reorganization of the TextEditor to reduce the rate it posts Actions. The problem is exposed by her experimenting with the Grep Plugin. These searches should not have returned any pages. But they did!

I examined the first page identified. Caring and Learning.

Yes, Grep did find an 'add' with the specified site field. My question is, how did this get here? Was there a sequence of activities that could compose this Action in the client? What is it? Or, worse, could the server have constructed this Action out of slow or out of order Action puts?

{
  "type": "add",
  "id": "696e8741eb388066",
  "item": {
    "type": "paragraph",
    "id": "696e8741eb388066",
    "text": "4. You can only threaten people with things they care about. "
  },
  "after": "3f67311374a3e987",
  "site": "maha.uk.fedwikihappening.net",
  "date": 1419487782704
},

A brief inspection shows an even more mystifying 'create' in newpage on chrome. How does one fork a create?

{
  "type": "create",
  "item": {
    "title": "newpage on chrome",
    "story": []
  },
  "site": "maha.uk.fedwikihappening.net",
  "date": 1418278528925,
  "fork": "maha.uk.fedwikihappening.net"
}

image upload fails ... or not? timeouts, claiming, accessing.

Dear people,

in my farm, which is nginx reverse proxy'd, I do have several sites behind a simple basic authentification and one public site.

The ones being auth'd are usually non-claimed, as they are collectively edited wikis. (Yes, I do know this doesn't fit the federation thought, but I'm working myself slowly into the matter - not to talk about the ones I'm forcing to use it ;) )

As mentionned in #24 , I use a rough and insecure workaround to access the wikis directly. (If I don't put the reverse proxy in front, bots banging on my server would create several wikis just by sending random HTTP HOST headers.)

The public wiki is claimed, so no visitor is able to change anything.

---

Question:

Why does image uploading work on the public wiki, even behind the proxy, but not on the "hidden" ones, even when accessed directly?

I've also claimed one of the latter, just to see that it doesn't change a bit. How to revert that?

I'll update this issue soon to provide further details on server logs, configuration examples and different error messages from nginx and/or wiki-client.

Further on, after having found the actual wiki's log instead of nginx' ones, I found the entry of the accepted file. It did accept PNG (10 KiB) but rejected JPG (110 KiB). Which I could reproduce on one of the auth'd wikis.

---

Finally:

Is there some kind of (undocumented) size limit for the base64 data: array? Or just my deploy that goes wild?

Nightly greetings from Berlin,

Jon

---

PS : next idea to work on : fedwiki as CMS w/ something like https://github.com/pure/pure or https://github.com/wycats/handlebars.js : what do you think? (similiar to http://fargo.io + https://github.com/scripting/trex, or gh-pages + octopress)

PPS : there's something going on with liquid multi column layouts . just look at https://ginkoapp.com and think of the fedwiki. then have a look at https://trello.com and rethink the wiki again. in the last step let's think of structured data like in https://fargo.io . there (like Bob Ross would say.) ... is ... something. [ I did also like the https://unhosted.org and http://remotestorage.io references I've found the other day in one of the federated wikis. ]

On the path to a simple, reliable install.

Our first goal is to have a simple, reliable and documented install.

Some Immediate ToDos include:

• Make sure all binary dependencies are optional and that wiki works fine without them.
• Correct order of coffeescript build in grunt.
• Explore spurious error messages related to favicon.png.
• Avoid development dependencies on a -g install.
• Revise ReadMe to be npm centric.
• Revise default WelcomeVisitors to refer to Persona.
• Drop port number from farm directories.

For easy installs on services that don't support reliable files we have a few more ToDos:

• Have straight forward configuration (and documentation) for several popular services.
• Consider how (the future) delete will work within those services.

wiki-storage-couchdb

I added CouchDB storage for wiki.
it currently lives here https://github.com/wesrc/wiki-storage-couchdb

Representing and communicating server configuration

@nrn writes ...

So right now there is a very complex system of configs, for a few reasons. It allows us to "Do the Right Thing" tm. with no config, a partial config that it then fills in reasonable defaults based on, or an extremely detailed config where you can set all kinds of things that don't make sense.

The complexity in the config system wins by reducing the complexity in the config file. No need for a huge file of defaults and comments a la php, where to change one setting you may have to touch half a dozen lines to make it consistent.

I'll try and get some documentation up on this soon, since it probably only makes sense to me, and it looks like we may be getting some users :)

I like to keep the config separate from the body of the program so we can keep personal configs separate. We can just require .coffee files since we have required coffee-script, however coffee script is weird and is likely to lose us users on the one piece that the most people will have to interact with. As much as it sucks to type I'm going to stick with json for the config file, it is kind of the universal language of this stuff. Right now there is a very weird thing that you have to use the short names instead of the long ones for the config in the file or env vars, I'll be fixing that soon.

You can now specify a json config file with --config. Or if you make a config.json file it will find it and lift that config.

Fedwiki on Raspberry Pi2

Today I had some fun getting Fedwiki up and running on Raspberry Pi 2. It runs great. The only issue is the Personal login, when trying to claim the site. Persona complains something along the lines of:

verify failed:: {status: colon reason audience mismatch, domain mismatch...

Essentially it doesn't like any user trying to claim the domain at the ip address of the Raspberry Pi. Claiming sites on localhost of the laptops behind the LAN works -so the question is is this an issue with the Pi install or something else?

The other thing that did not quite work is tying to login with the built in Raspberry Pi Epiphany browser - it comes up with a blank login screen in a new window at the url (login.persoan.org/signin) - but then does not offer an email to or any buttons to sign in with - the inside of the frame is blank. That's a pity but not such a big deal - as mainly we want to server a wiki site / farm.

The main issue here is to have the option to remove Mozilla Persona for local hosting. It's not good for a number of reasons - the main one being that one main use-case for local hosting is to be able to serve up sites when there is no internet connection. Mozilla Persona requires a round trip to Mozilla servers at present - this effectively prevents running Fedwiki in a teaching / conference / group situation offline - the only option is to use the browser cache.

Could this be a server plugin?

I'd like to create the ability to monitor attention on Fedwiki pages using the Javascript and some of the code base of Protip - ProTipHQ/ProTip#6

There would be two benefits:

1. A user or teacher or class could view / share the time data to see what material is actually being used by the community
2. This time data could be used as a bitcoin protip compatible wallet to sponsor content creation

Could we take a look at the Fedwiki and Protip code bases and advise the ProTip developers what they would need to do / if it were possible to create a ProTip plugin for Fedwiki so that people could use elements of Protip without the need for a Chrome extension while using Fedwiki sites?

Would this Wednesday Hangout be a good opportunity to discuss - or is it a bit technical?

TLS/SSL Support

Instead of using an TLS/SSL Proxy, that breaks the current implementation of Federation, I'm investigating ways to use Node's https module for integrated security support.

Appearantly, Public Key Client Authentication + HTTP fallbacks, if needed, will have to be implemented.

This is aimed at private wikis, that are directly connected to the internet. Having federation working between them is needed for corporate environments.

I believe that this requires a fork and an extension of the library itself, but wonder if the current plugin-engine would also be able to handle this? Reading of pluginsFactory in the code doesn't give me the impression.

Any additions / thoughts / concerns / ideas are highly appreciated!

Refactoring - next steps

As this affect multiple repositories, please see WardCunningham/Smallest-Federated-Wiki#403

Farm Security

I've set up a server farm on Digital Ocean using the script here - https://gist.github.com/nrn/f818fa7decfd910362b7

Just checked - and I've a few weird domains popping up in ~/.wiki/ -- stuff like ya.ru So I'm asking about how people go about security here - I've not added thee domains to the DNS - any thoughts / advice?

Prebuilt Binaries for LevelDB?

This project takes an optional dependency on level. This leads to slower installs and sometimes scary red output from npm install. It also means an install requires c build infrastructure, not necessarily a given.

The DAT project has recently switched to pre-built binaries for LevelDB to much cheering. This makes me wonder if we want to do likewise. This is the project that makes the binaries:

https://github.com/mafintosh/node-leveldown

Another approach would be to make page storage systems be their own projects.

npm test - working?

Spotted while doing a little tidy (see #59).

Running the tests, npm test, on Windows do not pass.

While the first is to be expected, the others all fail due to timeout.

Is this just an issue on Windows, or does this problem exist on other platforms?

  8 failing

  1) defaultargs #defaultargs() should modify dependant args:

      AssertionError: expected 'C:\\tmp\\asdf\\pages' to be '/tmp/asdf/pages'
      + expected - actual

      +"/tmp/asdf/pages"
      -"C:\\tmp\\asdf\\pages"

      at Assertion.prop.(anonymous function) [as exactly] (C:\github\wiki-node-server\node_modules\should\lib\should.js:60:14)
      at Context.<anonymous> (C:\github\wiki-node-server\test\defaultargs.coffee:19:22)
      at callFn (C:\github\wiki-node-server\node_modules\mocha\lib\runnable.js:223:21)
      at Test.Runnable.run (C:\github\wiki-node-server\node_modules\mocha\lib\runnable.js:216:7)
      at Runner.runTest (C:\github\wiki-node-server\node_modules\mocha\lib\runner.js:374:10)
      at C:\github\wiki-node-server\node_modules\mocha\lib\runner.js:452:12
      at next (C:\github\wiki-node-server\node_modules\mocha\lib\runner.js:299:14)
      at C:\github\wiki-node-server\node_modules\mocha\lib\runner.js:309:7
      at next (C:\github\wiki-node-server\node_modules\mocha\lib\runner.js:247:23)
      at Object._onImmediate (C:\github\wiki-node-server\node_modules\mocha\lib\runner.js:276:5)
      at processImmediate [as _immediateCallback] (timers.js:330:15)

  2) server #actionCB() should create a page:
     Error: timeout of 2000ms exceeded
      at null.<anonymous> (C:\github\wiki-node-server\node_modules\mocha\lib\runnable.js:139:19)
      at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

  3) server #actionCB() should move the paragraphs to the order given :
     Error: timeout of 2000ms exceeded
      at null.<anonymous> (C:\github\wiki-node-server\node_modules\mocha\lib\runnable.js:139:19)
      at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

  4) server #actionCB() should add a paragraph:
     Error: timeout of 2000ms exceeded
      at null.<anonymous> (C:\github\wiki-node-server\node_modules\mocha\lib\runnable.js:139:19)
      at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

  5) server #actionCB() should remove a paragraph with given id:
     Error: timeout of 2000ms exceeded
      at null.<anonymous> (C:\github\wiki-node-server\node_modules\mocha\lib\runnable.js:139:19)
      at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

  6) server #actionCB() should edit a paragraph in place:
     Error: timeout of 2000ms exceeded
      at null.<anonymous> (C:\github\wiki-node-server\node_modules\mocha\lib\runnable.js:139:19)
      at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

  7) server #actionCB() should default to no change:
     Error: timeout of 2000ms exceeded
      at null.<anonymous> (C:\github\wiki-node-server\node_modules\mocha\lib\runnable.js:139:19)
      at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

  8) server #actionCB() should refuse to create over a page:
     Error: timeout of 2000ms exceeded
      at null.<anonymous> (C:\github\wiki-node-server\node_modules\mocha\lib\runnable.js:139:19)
      at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)


npm ERR! Test failed.  See above for more details.
npm ERR! not ok code 0

Wiki@Next : Claiming wiki

When claiming a wiki, the server state does not get updated to reflect that the site has been claimed.

While the site ownership file is created, in the status directory, the server will not:

1. display the ownership on page reload, and
2. attempts to update the page result in a Forbidden response and the page being saved in local storage.

Mocha Browser tests fail to start.

Looks as if an earlier commit, see WardCunningham/Smallest-Federated-Wiki@bf5c73b, broke the mocha tests.

runtests.html fails to start with the following error in the browser console TypeError: this is undefined @ http://localhost:3000/test/testclient.js:9733 - same error is seen at http://nrn.io/runtests.html

While a quick solution would be to reverse that earlier commit, is there a better solution?

Data is wiped out when upgrading via npm update -g

The default directory for wiki data is in the wiki install directory. The README for wiki suggests using the -g option with npm when installing. However, when updating global packages using npm update -g (I haven't tested any of this with a local install), npm wipes out the entire package directory. That means all data is lost when updating to the newest version.

A few solutions if the user launches wiki without a --data flag:

• Prompt the user for a data directory.
• Make --data a required parameter.
• Warn the user what the consequences are of updating their package.

Problems with Express 3.4.5?

Just pushed the updated over to OpenShift, and there is a problem.

(The problem only appear to affect certain platforms, OS X and Windows appear not to be affected).

I'm getting the error

Error on /persona_login: Error: stream encoding should not be set at makeError (/var/lib/openshift/524d1f84e0b8cda2aa00008b/app-root/runtime/repo/node_modules/wiki/node_modules/express/node_modules/connect/node_modules/raw-body/index.js:132:15) at /var/lib/openshift/524d1f84e0b8cda2aa00008b/app-root/runtime/repo/node_modules/wiki/node_modules/express/node_modules/connect/node_modules/raw-body/index.js:48:17 at process._tickDomainCallback (node.js:459:13) 

Others are reporting the same problem elsewhere, not sure if the problem I am seeing is the same, as others are seeing. Need to do some more investigation...

Update to CoffeeScript 1.8

Also requires fedwiki/wiki#16

An uplift to the latest version of CoffeeScript, having missed out 1.7.

REST Interface

I'd like to use a RESTful interface to be called from a remote mobile client. I'd like to start some Federated Wiki documentation of this project, and of the process of creating a mobile app that interfaces with the wiki-node-server. Could someone advise / point me to the relevant portions of code or existing SFW notes elsewhere?

URLs with line-up with sites other than the origin not working

A request for a URL with a lineup, like http://forage.rodwell.me/forage.ward.fed.wiki.org/weeds-in-the-farm/fedwikihappening.rodwell.me/weeds-in-the-farm fails with the following in the page returned by the server.

<section class='main'>
      <div class='page' id=weeds-in-the-farm data-site&#x3D;forage.ward.fed.wiki.org ></div>
      <div class='page' id=weeds-in-the-farm data-site&#x3D;fedwikihappening.rodwell.me ></div>
    </section>

Plugin Installation Issue

Hi would appreciate any advice and help installing plugins on my local server. I'm stuck :)

I can't get the custom plugins working on localhost. Latest node and npm - fresh install of wiki locally:

Uncaught TypeError: Cannot read property 'emit' of undefined(anonymous function) @ client.js:4m.event.dispatch @ jquery-1.11.3.min.js:4r.handle @ jquery-1.11.3.min.js:4

I posted a video and recorded the issue here - http://issues.fedwiki.org/plugin-installation-issues.html

How to run wiki as a daemon and keep it alive

I have installed FedWiki on my server using npm install -g wiki and can run it without problems by typing wiki -p PORT_OF_CHOICE

However, I would like to use https://github.com/nodejitsu/forever for ensuring that the process is alive all the time, as I do with other nodejs apps. Forever expects a js file as parameter which should start the daemon. I noticed that index.js references coffee-script files and the gruntfile manages testing but...

How can I run the wiki in a nodejs fashion (node jsfile.js)? Can you please provide some instructions on how to achieve this? Alternatively, How would you deploy FedWiki on a server?

Farm problem

I've started the node server in farm mode (screen wiki -f) and added a wildcard DNS A record to my zone file, but I still get resolver errors when I try to hit a new subdomain in the browser to make a new wiki. At this point I can't even figure out if the request is reaching the server. Is there a log file somewhere that would track failed connections?

Stealth Persona Disabling in Farm Mode

Following @WardCunningham observation that if you don't claim a site, it will let you post anything. I started as instructed to "Think of not-claiming as disabling-persona". This made me feel good and warm inside.

This feature enables offline running of a wiki-farm setup on a laptop. This is useful. I tried @paul90 's suggestion of running the wiki farm on localhost and not claiming sites with interesting results.

Rather than the farm creating sites based on the referer's IP address - it creates a site based on it's own address, which results in several people editing the same wiki. I guess this is a bug with a simple fix?

In a future and better world I dream of an authentication plugin architecture which plays well with WebID and the ongoing WC3 specs in this area - something to hack on at Chaos Camp?

server doesn't understand scoped modules when looking for plugins

If I install a scoped plugin with a command like this:

npm install @wardcunningham/wiki-plugin-plugins --save

The plugin will be installed within a subdirectory of the node_modules named @wardcunningham/wiki-plugin-plugins. If this is to be supported, then we will have to extend the search inside the server to look inside scope folders.

We have a related but different problem with accessing the bin file when using scoped copies of wiki-node. Nick has a fix for this.

Migrating to fedwiki org.

Part of the refactor, see WardCunningham/Smallest-Federated-Wiki#403

• review documentation, and update
• move to fedwiki org, and rename as wiki-node-server
• merge refactor branch into master
• Update package.json to include new repository and issues url
• publish to npm, as wiki-node-server

Server generates recent changes page

Taking a look at server - I see that it generates the [[Recent Pages]] json in response to a request from the client.

It would seem to me that all the necessary information is already available to the client to generate a Recent Pages page from the site map JSON - so the request is unnecessary? To check whether client and server are in sink we'd need to just check the sitemaps - not have the server render this page?

Quick question about Recent Changes

Just to check.

When it says : "Here we list neighborhood pages with those most recently changed listed first." on the recent changes page, that "neighbourhood" just means the wiki itself, right?

SFW isn't sending information about changes that have been made on my private wiki on my local machine, up to the cloud or the original SFW that the first page was forked from, is it?

Rejected Actions Silently Fail

https://github.com/fedwiki/wiki-node-server/blob/master/lib/server.coffee#L345

This put exits with a 403 when a 404 is expected by the client code in this situation.

I've tried to recreate this error which happened as I was working on another bug. It has something to do with persona getting out of sync with the server. I will continue to isolate the error conditions.

Could not run tests successfully

I ran mocha in the wiki-node-server directory, and was informed of the following:

TypeError: Cannot read property 'should' of undefined
at Object.cb (C:\Users\ryan\wiki-node-server\test\page.js:33:18)

Steps to reproduce:

Runing Windows 7 64-bit
Installed nodejs
Installed mocha using mpm
Cloned wiki-node-server from github
Entered wiki-node-server directory
Typed mocha

International character can not be page name

International character can not be page name

npm start fails on Windows

On Windows, installing wiki globally and running the executable does start a server. However, running npm start from a cloned repository fails (after successfully installing npm packages and building the client).

C:\Practice\wiki>npm start

> [email protected] start C:\Practice\wiki
> ./bin/server.js

'.' is not recognized as an internal or external command,
operable program or batch file.
npm ERR! [email protected] start: `./bin/server.js`
npm ERR! `cmd "/c" "./bin/server.js"` failed with 1
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR! This is most likely a problem with the wiki package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     ./bin/server.js
npm ERR! You can get their info via:
npm ERR!     npm owner ls wiki
npm ERR! There is likely additional logging output above.

npm ERR! System Windows_NT 6.1.7601
npm ERR! command "C:\\Program Files (x86)\\nodejs\\\\node.exe" "C:\\Program File
s (x86)\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "start"
npm ERR! cwd C:\Practice\wiki
npm ERR! node -v v0.8.16
npm ERR! npm -v 1.1.69
npm ERR! code ELIFECYCLE
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     C:\Practice\wiki\npm-debug.log
npm ERR! not ok code 0

Warning Message from Connect.

Wiki reports the following warning when started.

  connect.multipart() will be removed in connect 3.0
  visit https://github.com/senchalabs/connect/wiki/Connect-3.0 for alternatives
  connect.limit() will be removed in connect 3.0

I would appreciate some advice on how to respond to these warnings. Where are they from? What do they mean? A pull-request would be awesome. Thanks.

HTML markup on initial page load

The server rendered page displays content which has been escaped. For example:

  <body>
    <section class='main'>
      <div class='page' id=welcome-visitors  data-server-generated=true>&lt;div class="twins"&gt;&lt;p&gt;&lt;/p&gt;&lt;/div&gt;
&lt;div class="header"&gt;&lt;h1&gt;&lt;a href="/" style="text-decoration: none"&gt;&lt;img  height="32px" src="/favicon.png"&gt;&lt;/a&gt; Welcome Visitors&lt;/h1&gt;&lt;/div&gt;
&lt;div class="story"&gt;&lt;div class="item paragraph"&gt;&lt;p&gt;Welcome to the <a class="internal" href="/federated-wiki.html" data-page-name="federated-wiki" title="">Federated Wiki</a>.&lt;/p&gt;&lt;/div&gt;
&lt;div class="item error"&gt;&lt;p&gt;markdown&lt;/p&gt;&lt;/div&gt;
&lt;div class="item paragraph"&gt;&lt;p&gt;<a class="internal" href="/paul-rodwell.html" data-page-name="paul-rodwell" title="">Paul Rodwell</a>&lt;/p&gt;&lt;/div&gt;
&lt;div class="item error"&gt;&lt;p&gt;markdown&lt;/p&gt;&lt;/div&gt;

CLI option for $DATABASE_URL formatted DB credentials

Heroku, Stackato, and other Platform-as-a-Service environments expose database credentials in a $DATABASE_URL (or similar) environment variable with a format like:

db-protocol://username:password@hostname-or-ip:port/db-name

It varies a bit depending on the data store you are connecting to. For example, Stackato exposes this to my app:

REDIS_URL=redis://user:[email protected]:5101/

It would be nice to support this format with a '--db-url' (or similar) CLI option for server.js. That way, I could start the server with:

node server.js --port $PORT --db-url $REDIS_URL

running server with wildcard DNS

Hi,

I am struggling with setting up a farmed federated wiki server. If I want to limit the amount of wikis by manually creating them, the wiki server crashes, when I use an URL for which no farm element directory exists. Any ideas to overcome that, but still limit the number of wikis in a farm? (I know, this is newbie stuff, but I'd like to figure things out).

[ { _: [],
    test: false,
    help: false,
    h: false,
    p: 3000,
    port: 40002,
    d: '/home/wiki/node-fedwiki',
    data: '/home/wiki/node-fedwiki/test2.fed.hsr.ch',
    f: true,
    farm: true,
    '$0': 'wiki',
    valueOf: undefined,
    farmPort: 40000,
    root: '/usr/lib/node_modules/wiki/node_modules/wiki-server',
    home: 'welcome-visitors',
    url: 'http://test2.fed.hsr.ch',
    packageDir: '/usr/lib/node_modules/wiki/node_modules',
    client: '/usr/lib/node_modules/wiki/node_modules/wiki-client/client',
    db: '/home/wiki/node-fedwiki/test2.fed.hsr.ch/pages',
    status: '/home/wiki/node-fedwiki/test2.fed.hsr.ch/status',
    id: '/home/wiki/node-fedwiki/test2.fed.hsr.ch/status/persona.identity',
    database: { type: './page' },
    debug: true } ]
[ 'Smallest Federated Wiki server listening on',
  40002,
  'in mode:',
  'development' ]

/usr/lib/node_modules/wiki/node_modules/coffee-trace/lib/coffee-trace.coffee:33
      coffee_trace = (stack = err.stack.split("\n"))[1].match(options.stack_ma
                                                        ^
TypeError: Cannot call method 'match' of undefined
    at process.<anonymous> (/usr/lib/node_modules/wiki/node_modules/coffee-trace/lib/coffee-trace.coffee:33:57)
    at process.EventEmitter.emit (events.js:95:17)
    at process._fatalException (node.js:272:26)

trouble diagnosing persona issues

I'm running a server, but not able to get the persona login to work. I can't get anything other than failure while logging in.

I've used persona on other sites, so I know my "basic" persona skillz are ok - none-the-less, this is most probably an error on my part. Or is some configuration required which isn't I didn't notice in the docs?

Anyhoo, before I dive in, I'll just note that there aren't really any good diagnostics for this particular failure. Here are the symptoms:

• a red list item at the top of the browser page which says Error on /persona_login: FAIL in red
• Chrome DevTools shows a POST to https:///persona_login which is getting a 401 (Unauthorized). The form data posted is the persona assertion (long), the response pay load is FAIL.
• the server prints the following:

[ 'isAuthenticated? owner=',
  '',
  'req.session.email=',
  undefined,
  false ]

Update to Express 4

Another overdue update.

The Express 3.x to 4.x migration guide has been updated.

non-local session support

to run on a "cloud" the session support should store sessions in some remote db, that each instance of the wiki can access. I don't see any code to do that today.

As an example, I might want to use something like this to store my session in mongo, prolly same db as my pages, different collection.

Thoughts?

Linkmap Plugin Findings

As you know, I'm constantly exploring the SFW universe.
Following the discussion in #23, I'm not sure where to post this question, as it might have server and client side related perspectives.

Following a transcript from #fedwiki :

• http://fed.wiki.org/view/add-plugins could indicate more precisely that one has to change the factory-item in the story array/section, but really not in the journal. "At the bottom of the story array" sounds very close to "at the bottom" if one doesn't read very carefully. Led to a misunderstanding with me at least.
• http://wardcunningham.github.io/ - 12th video - first appearance of "plugins" on the page : the link is broken.
• The linkmap does not support configurations behind a reverse proxy that adds an authentication layer
• In some cases the connection of the GET /plugins/linkmap request times out.
  
proxy_connect_timeout 180s;
proxy_send_timeout 180s;
proxy_read_timeout 180s;

  Helped in nginx.
• Either way, also within another setup without any reverse proxy, the linkmap returned was empty.

Now, my questions would be:

• Do I need some of those "keyword-value pairs" that Add-plugins is talking about to make it work?

Thanks for your always kind guidance.

Unexpected Persona FAIL with aliased domain names.

I have two domain names that point to the same server. I'm not running the server as a farm so I expect both to show the same content, which they do. However, when I claim one with Persona I would expect to have claimed the alias too. This is not the case.

Sequence:

Visit localhost:3000
Claim with email address successfully
Logout of localhost:3000
Visit foo.localhost.3000
Claim with email address, successful through persona popup
Wiki reports catchall error: "Error on /persona_login: FAIL"

The condition is persistent. All subsequent visits to foo.localhost:3000 report the same error immediately. The message appears to come from persona.coffee, line 6.

Subsequent visits to localhost:3000 work correctly, including login/out.

Browserified Fedwiki

I'm very interested in running Federated Wiki entirely as a front-end application inside of a browser. We can do this on top of IPFS, which gives us first-hand content versioning and distribution. This requires some adaptation of some parts of the information flows, and expectations, but i think it would be a very valuable thing to do.

Benefits:

• federated wiki becomes totally distributed, decoupled from physical locations
• anyone can try running a fed wiki node with just one click
• fedwiki could work offline
• easier to operate a fedwiki node
• easier to use fedwiki to build other applications
• p2p sharing of resource loads

Key challenges;

• understanding how the data model would look on top of ipfs instead of at a specific location (i.e. are there any location-specific addresses (i suspect lots of URLs) and which could be changed)
• understanding how authentication + identity would be managed (i suspect pub/private key pairs)
• adapting server + client code to these
• browserifying a lot of the code from the server

Questions I have:

• What URL schemes are followed?
• What are all types of content addressed?

We have described the url scheme in other issues. We've prepared a simplified version for federating foreign servers

• When does a host's domain come into play?

Pages are rendered from the page json alone. We remember where that was retrieved in order to display a flag (favicon) and the sitemap to be added to the neighborhood. The source could be a domain name or the symbols 'origin', 'local', 'view'. In some cases null is used as a synonym for 'view' which means to choose 'origin' or 'local' as appropriate.

• How is identity defined right now?
• Who (precisely) gets to create/edit pages on a given host?

We treat domain names as identities. Convention has the welcome-visitors page further identify the owner as that owner sees fit. We distinguish between sites, servers and hosts. The site is responsible for authenticating and authorizing users which has been delegated to the server. We have a 'claim' process where a new site learns of the credentials its owner will use for authentication. There is currently a project underway to provide modular authentication.

• Is there interest in allowing users to sign their edits?

Yes. We would expect a page be signed at multiple points in its history by multiple authors, each of which can be verified by a well known, independent and public trust network.

Notes:

• there is a way to use DNS domains with IPFS, so that we don't need to change URL formats much, if at all. just the "host" might be virtual, instead of an actual server listening.

I would suggest we just start outlining the stuff for the data model + auth/identity first. We're working on some changes to ipfs at the moment which will make it waaaay easier to just use JSON natively to build arbitrary data structures (at that point importing a fed wiki datastructure might be as trivial as storing all the json.

How to design new plugin: principles and steps to follow

I would be interested to (try to) design a new plugin, allow a page to act as a Literate Wiki.
I had a look at existing plugins code but I would really appreciate an introduction/explanation about design principles of the current design, i.e. what/why/when server.coffee, what is the pages directory and how to generate it at plugin "bootstrap" time, how to deal with a development wiki, how to enable all existing plugins (there are plenty of them in the codebase but only few seems available in deployed fedwikis)...thanks

Rendering URL to particular view

Spotted while looking at #33

Each view into the Federated Wiki has an address which details those pages contained in that view, though it will vary depending on the starting point.

So using the example from #33 - Welcome Visitors > How to Wiki > Frequently Asked Questions > More About Browsing and Linking Sites
http://wiki-paul90.rhcloud.com/view/welcome-visitors/view/how-to-wiki/view/frequently-asked-questions/view/more-about-browsing-and-linking-sites
does not recreate the view. Both frequently asked questions and more about browsing and linking sites pages are not found.

The same issue exists with the Ruby version, see WardCunningham/Smallest-Federated-Wiki#400

HTML Title marked incorrectly

I've been experimenting with indexing using custom Google search and have noticed that all the titles come up as "Smallest Federated Wiki"

<!DOCTYPE html>
<html class='no-js'>
  <head>
    <title>Smallest Federated Wiki</title>
    <meta content='text/html; charset=UTF-8' http-equiv='Content-Type'>

sanitize-caja changed namespace

From a recent Docker build:

Step 2 : RUN yarn global add [email protected]
 ---> Running in fc587865b73a
yarn global v0.21.3
[1/4] Resolving packages...
warning wiki > wiki-server > [email protected]: This module is now under the @mapbox namespace: install @mapbox/sanitize-caja instead

inefficient (?) load of prettify.js/css

The use of code plugin inserts a

<style type="text/css">@import url("/plugins/code/prettify.css")</style>

line for every code snippet in the page.
This sounds inefficient in principle, but for this specific plugin not a problem.

Let's be clear who owns each wiki

We're not the usual service with lots of users. That means the usual login workflow is confusing to visitors. Let's make the owner of claimed sites show the owners name like this:

ward can (Log In)
[email protected] can (Log Out)

We already to this second form. The first form makes it clear that only one person who is not you can login.

In the event that nobody has yet claimed the site then the eye-catching persona login is appropriate:

[ Login with your email >

I've revised the welcome-visitors text to mention login as part of the template prompts, not body text that has to be discarded to make a site make sense to visitors.

How do I use this?

It's not clear to me how to use wiki-node-server outside of using the smallest federated wiki
package. Is wiki-node-server itself useful outside of the context of the sfw? If so,
what are it's use cases? How do I use it? Some documentation in this regard would be helpful.