History of decentralized wikis

The history of decentralized wikis is the story of a simple idea, a web page that anyone can edit, slowly escaping the single server it was born on. Each generation of builders tried to spread hosting, editing, and preservation across more hands: federated forks, Git repositories, peer-to-peer replication, content-addressed mirrors, offline archives, and permanent storage networks. None produced a final answer, and each taught something useful about what shared knowledge needs in order to survive without one owner. This page walks through that history, notes the lesson of each stage, and closes with grounded guesses about what comes next.

Related background lives in Content-addressed wikis and How content hashing works.

The centralized beginning

The first wiki was the WikiWikiWeb, which Ward Cunningham launched on 25 March 1995 at c2.com, the website of his company. It accompanied the Portland Pattern Repository, a community discussion of software design patterns. The name came from the Hawaiian word wiki, meaning quick.

WikiWikiWeb was centralized in every practical sense: one site, one database, one operator. That made it easy to start and easy to understand, and later projects such as Wikipedia followed the same basic pattern at far larger scale. It also showed the weakness of a single host. In December 2014 the site came under attack from vandals and was placed in a read-only state, and in February 2015 Cunningham announced that it had been migrated onto his newer Federated Wiki software.

Lesson: openness invites both collaboration and abuse, and a single operator carries the whole burden of defending the commons.

Federated Wiki and the chorus of voices

Cunningham himself started the most direct rethink of the model. Smallest Federated Wiki, later simply Federated Wiki, was launched at IndieWebCamp in 2011. It borrows forking from source control. Instead of one shared page that everyone fights over, each person keeps copies of pages on their own site, forks pages from others, and can see where related versions live across the federation. Cunningham described the result as "a chorus of voices", where people share content while keeping individual perspectives.

Wikipedia resolves disagreement through consensus on a single article. Federated Wiki lets disagreement persist as parallel versions and leaves readers to decide which fork to follow.

Lesson: forking removes the need for a central referee, but it moves the hard work of synthesis and discovery onto readers.

Wikis inside version control

A parallel line of work put wiki pages directly into version control. ikiwiki, designed by Joey Hess and first released in 2006, calls itself a wiki compiler. It stores pages and history in a system such as Git or Subversion and renders them as static HTML. Gollum, a Ruby wiki with Git as its storage backend, started life as the wiki system used by GitHub; a Gollum wiki is simply a Git repository with a particular layout. Fossil, created by D. Richard Hipp, bundles distributed version control, bug tracking, and a wiki into one program.

These tools made wikis portable. A repository can live on a laptop, a forge, and a backup drive at once, which is the core idea behind Local-first wiki and Git mirrors.

Lesson: every clone holds a complete, verifiable history, yet communities still tend to treat one repository as the official one.

Peer-to-peer wiki research

Academic researchers attacked the merging problem head on. A team in Nancy, France, built Wooki, a peer-to-peer wiki presented at the WISE 2007 conference by Stéphane Weiss, Pascal Urso, and Pascal Molli. Wooki replicated pages across a changing network of sites and used the WOOT algorithm so that every site would converge on the same text even when edits arrived in different orders. The same research community later built Distributed Semantic MediaWiki (DSMW), an extension that let Semantic MediaWiki servers publish feeds of patches, subscribe to each other, and merge concurrent edits with the Logoot algorithm. DSMW is one of the clearest real precedents for P2P MediaWiki.

Lesson: convergence of text can be solved mathematically, but research prototypes rarely gain the community, hosting, and moderation needed to become living public wikis.

Offline and content-addressed mirrors

Another branch focused on reading. Kiwix, created by Emmanuel Engelhart and Renaud Gaudin in 2007, packages Wikipedia and other content into compressed, searchable ZIM files for offline use in schools, libraries, ships, and remote communities. It proves that a wiki can live as a portable artifact far from its origin server.

In May 2017, after Wikipedia was blocked in Turkey, the IPFS team published a read-only snapshot of Turkish Wikipedia on IPFS, built from a Kiwix archive. Because IPFS names content by its cryptographic hash, anyone could serve the snapshot and readers could verify it was unaltered. The announcement named a harder second goal, a fully read-write Wikipedia on IPFS, which was never reached. The Distributed Wikipedia Mirror repository was later archived, and its README explains that unpacking huge archives into millions of files proved expensive, hard to reproduce, and incompatible with Kiwix tools.

Lesson: read-only mirrors are achievable and valuable, but someone still has to build, publish, and vouch for each snapshot. See IPFS and Arweave.

Blockchain and permanent storage

The late 2010s brought blockchain encyclopedias. Everipedia began in December 2014 as a fork of Wikipedia and launched on the EOS blockchain in August 2018. Critics noted that much of its content was copied from Wikipedia, and the site became a read-only archive in October 2022 as its parent company shifted to a cryptocurrency-focused encyclopedia, IQ.wiki.

Arweave focused on storage itself. Its mainnet launched on 8 June 2018 with the goal of paying once for data that the network keeps permanently, and the permaweb of pages and apps grew on top of it. AO, a parallel compute layer built on Arweave, opened a public testnet in February 2024 and launched its mainnet in February 2025. Together they suggest a wiki whose revisions are permanent and whose logic runs without a single server, as explored in Permanent wiki and Git forges on AO and Permaweb basics.

Lesson: chains add permanence and new funding models, but they do not create good editors, sources, or moderation. Permanence also raises the stakes for mistakes, which is why Publish gates before permanence matter.

Federation for forges

ActivityPub became a W3C Recommendation in January 2018 and now connects many federated social platforms. ForgeFed extends ActivityPub with vocabulary for repositories, commits, patches, and issues, so people on different code hosting sites can open issues and propose changes across servers without creating accounts everywhere. Its reference implementation is Vervis, and Forgejo is implementing federation. Since Git-backed wikis already live inside forges, forge federation offers a plausible path for wiki pages to federate too.

Lesson: shared protocols tend to outlast individual apps.

Why fully decentralized wikis remain hard

Across three decades, the same problems keep returning:

Moderation. Without a central operator, each node needs its own policy, and readers need a way to choose whose judgment to trust.
Merging. Algorithms can merge text, but merging meaning and sourcing still needs human review.
Identity. Pseudonymous keys are cheap to create, which makes reputation and accountability hard to build.
Spam. Open write access at near zero cost attracts automated abuse. Small fees can help, as explored in Self-sustaining wikis.
Discovery. When knowledge is spread across forks and nodes, finding the best version becomes its own problem.

Where things might go next

The likely future blends these lessons. A practical stack could look like this: pages edited in a familiar MediaWiki or Git workflow, mirrored to local copies, checked by pre-publish checks, and anchored to permanent, content-addressed storage once reviewed. Federation protocols could carry change proposals between communities. AI agents could help with spam triage and citation review under human oversight, as discussed in Decentralized multi-agent coordination.

The goal stays the same as in 1995: make knowledge quick to share. The new ambition is to make it hard to lose and hard to capture as well.

External links