Local-first wiki and Git mirrors
A local-first wiki mirror keeps the editable MediaWiki close to the people who write it, including on a laptop or a small office server that can work offline, while still publishing durable copies to content-addressed storage such as IPFS or Arweave. The same pattern applies to Git: the working repository stays local, and selected trees or release tags become mirrors that outsiders can fetch without depending on one corporate host. This page describes that architecture at a high level for small groups that want editability and permanence without turning into another rented wiki clone. It is not an install guide and not a vendor endorsement.
Local-first editing first
Local-first means the primary copy for writing lives where the editors already work. A MediaWiki instance on a home server, a club laptop, or a small virtual machine that the group controls can accept edits while the wider network is down. Drafts, talk pages, and user accounts stay under local policy. Search and recent changes remain ordinary MediaWiki features on that host.
Offline editing does not require every reader to run a full wiki. It requires that authors can save revisions without waiting for a cloud account to approve the session. When connectivity returns, the group exports or syncs outward. That order matters. If the only editable copy sits on a rented platform, an outage, a policy change, or a billing failure stops the work. A local primary copy keeps the work moving, then publishes snapshots when the group is ready.
Git follows the same logic. Clones already are local-first. Commits land on a laptop before they ever reach a remote. The remote is a convenience and a collaboration hub, not the definition of the project. Treating Git hosting as optional infrastructure, rather than as the sole home of truth, is the same habit the wiki side needs.
Mirrors are not clones of corporate wikis
A mirror, here, is a published copy of selected wiki exports or Git trees that readers and archivists can retrieve independently. It is not a full replica of every private account table, every suppressed revision, or every editorial queue. It is also not a promise that the public mirror will accept live edits from strangers the way a large hosted wiki does.
Corporate wiki clones centralize accounts, spam fights, search ranking, and brand. Small groups often do not need that product shape. They need a place to write together, a way to keep history, and a way to hand a stable citation to outsiders. Local MediaWiki plus scheduled mirrors can serve that need without importing the full politics of a mega-host. The group still sets policy for who may edit the live wiki. The mirror only needs to be faithful to the public bytes the group chose to release.
Content-addressed and permanent storage
IPFS content identifiers (CIDs) and Arweave transaction identifiers name exact bytes. Once a wiki XML dump, a static HTML export, or a Git bundle sits under such an identifier, any party that still holds or can fetch those bytes can verify the match. That property is why mirrors on these networks differ from a bookmark to one hostname. Neighboring coverage appears in Content-addressed wikis and in IPFS and Arweave.
IPFS availability depends on pinning. Unpinned content can fade. A small group should plan at least two independent pins when a release matters. Arweave aims at longer retention after an up-front fee, usually read through gateways. Neither network replaces editors, moderation, or search. Both reduce the chance that a single MediaWiki host failure erases the public record.
Permanent storage raises the cost of a bad publish. Secrets, private contact data, and malware links that slip into a mirrored snapshot can outlive a later redaction on the live wiki. Pre-save and pre-push checks belong in the pipeline before a CID or a permanent write leaves the building. See Publish gates before permanence and the proposal Pre-publish checks for MediaWiki and Git.
Git mirrors beside the wiki
Many projects already keep prose in a wiki and code or structured sources in Git. Mirroring both keeps the citation story coherent. A release can pair a MediaWiki export CID with a Git tree CID or a signed tag whose object hashes are recorded in a small manifest. Readers who care about software and documentation together can fetch both without trusting one platform account.
Practical Git mirror shapes include:
- A bare mirror of selected branches pushed to a second remote the group controls.
- A Git bundle or archive added to IPFS under a root CID.
- A release tarball or static site build uploaded to Arweave with a recorded transaction id.
- A signed pointer file that names the current wiki export identifier and the current Git tree identifier.
Git history that never left a laptop is cheap to rewrite. History that was pushed and mirrored is expensive to erase. Treat the mirror boundary the way careful teams treat a public remote: scan for secrets, confirm the tag, then publish. Tools in the Gitleaks class fit that moment. AbuseFilter and related MediaWiki rules fit the wiki save path. The two sides share a goal even when the software differs.
Why decentralization matters for small groups
Small groups lose more from a single point of failure than large platforms do. A club, a research circle, or a volunteer project rarely has a legal team and a second data center on standby. If the only copy lives inside one vendor account, a lockout can end the archive. Local-first editing plus content-addressed mirrors spreads the risk across machines the members already own and across storage networks that do not require the original host to stay online for every read.
Decentralization here is operational, not theatrical. It does not mean every edit is a public chain transaction. It means the group can rebuild the live wiki from the latest approved snapshot, can cite a version by hash, and can keep writing during an outage. It also means a community split can publish two pointers instead of fighting forever over one hostname. Clear written rules for which pointer is current still matter.
Cheap compute and storage make this pattern more realistic than it was a decade ago. When export jobs and pins fit ordinary budgets, permanence stops being a luxury reserved for national archives. That backdrop is part of the wider discussion in Post-scarcity tooling and Post-scarcity economy.
High-level architecture
A workable layout has three layers.
Mutable live layer: MediaWiki for collaborative editing, plus one or more Git remotes for source that belongs in version control. Accounts, permissions, talk pages, and draft branches live here. This layer can sit on a local server or a small hosted machine the group administers.
Release and check layer: scheduled or manual exports, secret and PII scans, link reputation checks, human review for borderline cases, and a signed manifest that lists titles, revision ids, and content identifiers. Browser warnings and server enforcement on the wiki path, and pre-commit or pre-push hooks on the Git path, belong here.
Durable mirror layer: IPFS pins, Arweave writes, for approved snapshots, plus optional secondary Git remotes. Gateways help browsers, yet the group should keep local replicas and more than one retrieval path. Old identifiers stay published so prior citations still resolve.
Data that must stay private never enters the durable layer in plaintext. Encryption of private working notes is a separate concern from public mirrors. Public mirrors should carry licenses and attribution that allow lawful republication.
Short public notes about a release can travel on ordinary channels or through patterns such as Bitcoin Cash Memo. Those notes are pointers, not a substitute for the full wiki export.
What this design refuses
It refuses to treat a corporate wiki skin as the only professional option. It refuses to publish every keystroke to permanent storage. It refuses to pretend that a hash replaces moderation or legal duties. It refuses silent disappearance as the recovery plan for secrets that already mirrored worldwide.
Operators who need erasure guarantees for personal data should decide before upload. Content addressing makes quiet global deletion unreliable once copies spread. Design the gates so private mistakes stay rare.
Conclusion
Local-first wiki and Git mirrors keep editing under small-group control while publishing durable, verifiable copies to IPFS, Arweave, and secondary Git remotes. MediaWiki stays the collaborative front end. Git stays the natural home for trees and tags. Content identifiers name releases. Pins, fees, manifests, and pre-publish checks make the system honest about availability and about mistakes. The result is a wiki that can work offline, sync when ready, and survive a host failure without becoming a miniature copy of a corporate platform.