Wiki over Freenet
A wiki over Freenet would be really awesome. In fact it could be a killer app. But it is not easy to implement. The main challenges:
- Scale and reinsertion. A Wikipedia-sized wiki would be rather large, with millions of keywords. It needs to be possible to lookup a keyword efficiently, and it needs to be possible to make a few changes and update the wiki without uploading everything. However, smaller wiki's could also be very, very useful.
- No real time editing. Because there is no central server, edits cannot be integrated instantly.
- No anonymous editing. We cannot simply publish the private keys and let everyone spam it. Freenet services are regularly DoS targets (see Frost e.g.), and there is no way to ban IPs unlike on real wiki's.
The obvious solutions for the latter two problems are:
- Central "server" with an edit queue. One user publishes a wiki, the plugin allows users to edit pages and then send him the diffs. He can decide whether or not to merge proposed changes, and publish an updated version.
- Fork-and-merge approach. Any user who edits the wiki automatically creates their own fork, reinserting the changed pages and their parents right up the tree. This is an application of fork-and-merge DSCMs. The fork can (mostly) automatically track the original, and users can merge changes from each others' trees, mostly automatically.
Scaling issues can be resolved with B-tree indexes, which are efficiently forkable so fit well with the fork-and-merge approach. However, we probably want published wiki's to be accessible via fproxy without the wiki plugin, which will require either new metadata or support in fproxy for b-tree indexes.
In any case, we will need some way to protect from spam. Options:
- Use Web of Trust identities, and always edit under a pseudonym. Use WoT to announce forks.
- Allow truly anonymous one-off contributions, either using a temporary WoT identity or using a separate per-contribution introduction system such as CAPTCHAs.
The fork-and-merge approach creates a new tree so if the tree is to be maintained it really requires a persistent identity, as with the first approach.
In any case, it would be best if wiki over Freenet software could be bundled with Freenet, meaning it should be a plugin, written in Java.
One of the first implementations was Freekiwiki by Volodya (aka Anarhist). This is roughly on the server model although may eventually support servers pulling from each other. It is directly based on MediaWiki. It is not currently working and there are no published wikis as of 1 March 2010. Anarhist was discussing it but did not have access to Freenet or Java development tools, and there are bundling issues with the plugin. It is unlikely to scale to wikipedia-scale wikis and the current code uses a KSK queue so is spammable.
A more recent development is Fniki, Wiki over Mercurial over Freenet using python scripts for editing and FMS for it's WoT and commit notification. This is a semi-centralized system that requires the site-publisher to remain active, fetching any changes submitted and merging them into the final published wiki page. This may also have scalability problems, but is actively developed and may turn into a Freenet plugin someday.
Even more recently, Jfniki is a port to Java that does not depend on having Mercurial installed. This is a plugin, it does fork-and-merge and WoT or FMS based announcement of versions, and very promising. It doesn't scale to wikipedia-sized wikis yet, but this is not an immediate problem.
saces is working on a git plugin for Freenet as of 1 March 2010. This will be a server, with complete control over bundling etc, but will integrate cleanly with command line tools. It will reuse objects when forking, reinserting only what is necessary. He suggests that we could have one repository per wiki term in a git-based wiki, but have them reuse objects within an uber-repository. See , which literally translates as "git plugin".
ikiwiki is a wiki backed by git.
Anarhist also mentioned friki. FIXME: Look this up.
WikiShare  might also be relevant.
Fossil  distributed SCM with distributed bugtracker and distributed wiki