Distributed Wikis (on worldwide scale)
From WikiSym 2008
openspace session Sep 9 2008 15:30
Animator: Colas Nahaboo, http://colas.nahaboo.net
This was a lively and quite interesting open space. Most of the time was spent brainstorming on the issues a Distributed wiki would have to face. Here are random notes I collected, that may be just reminders, so a bit cryptic. Feel free to modify/complement. Globally, there are (much) more questions than answers!
There are technical as well as social issues.
On social, the linux kernel communiity is an example of a success of distributed authoring network with an active leader. Issues can be awareness, merging, how to reconcile distributed histories? (see http://git.or.cz/)
Use case of distribution can be
an interesting direction is peer2peer, (see http://tribler.org)
you want to avoid that some data be not accessible is a node is down, unlike collanos
Is there something for wikis like RAID for hardware?
Offline edition is incompatible with a synchronous model, you must work asynchronously, and this maybe will need to rethink the semantics of what is a change in a wiki. Doing both offline and p2p is hard, due to how to push updates. More generally, combining problems is hard, for instance offline + distributed storage. Considering asynchronous propagation, with the number of distributed nodes, number of possible change recombinations (thus, complexity) grows combinatorially (is that english? :-)
how do you handle the rejection problem?
A big danger: decentralized failures: buggy nodes emitting broken protocol messages, ...
How to reconcile edits in temporarily disconnected subnets?
Use case brouth by users: "we would like something like git to edit our pages via mobile phones"
There ared technical conflict on merge, but also semantic ones: what if two people add a plural 's" to teh same word, do the system recognize it as a single s? or if A and B add/delete at the same place? suggestions: mark questionable addition in grey, always delete, always keep the most informatikon (both edits)...
What could be the UI to solve conflicts: a simple approach that work well is just to embed markers on the alternatives
what about conflict notifications / alerts? only on automatic resolutions? notification could bring rush of people trying to edit at the samke time, stgressing the system
are alll conflict detectable?
what if corrections create conflicts in turn? will it converge?
aren't we putting too much ewmphasis on conflict resoolutions?
how to backup/restore?
could we just do it for free on a distributed backend? (Distributed file systems like AFS, google/amazon data farms, distributed databases? It seems a wiki exists working on Distribiuted hashtables Could we use git/mercurila as a backend (a twiki plugin exists for mercurial, alpha stage)
other use case: fight censorship, which bring ethic questions, on accepting nodes
how to rollbacks in case of spam/vandals
could we get inspiration from other systems? DNS, Groove, p2p, kadmelia, gnutella, edonkey, serverless bitorrent, freenet
arent we recreating email problems with distribution?
wikis focus a community of users, which should make conflict solving easier since they share some context/vision/goals
should we drop offline updates if they are too old?
Socialtext has centrral editing, but it is not distributed
Victor Grishchenko 
(read from poster: please correct my spelling...)
Irun Lopez Lunel
See the photos of WikiSym2008
Are you in the mosaic?
Keynote and Invited speakers
Poster / Badge