Permanent wiki and Git forges on AO

This page is a project proposal for what could be built: a permanent wiki and Git forge layer that keeps editing local-first, federates between independent forges, and pins approved snapshots to Arweave, with AO processes coordinating releases, work claims, and small payments. The pieces are real and publicly documented. The integration is the idea. It belongs beside Local-first wiki and Git mirrors and the wider list at Project proposals.

The goal: editable knowledge and editable code that live together, survive the loss of any single host, and reward the people and agents who improve them, without becoming one more corporate wiki or centralized Git clone.

Stack pieces

Arweave

Arweave is a storage network designed for permanence. A one-time fee pays for long-term storage, and each upload receives a transaction id that names those exact bytes. Gateways let ordinary browsers read the data, and the apps and pages served this way form the permaweb. See Permaweb basics.

Here Arweave is the durable mirror layer for reviewed wiki exports, Git bundles, and release manifests.

AO

AO, described at ao.arweave.net as a decentralized hyper-parallel computer, runs on top of Arweave. Programs in AO are processes that communicate by messages recorded on Arweave, so anyone can replay the log and check the resulting state. That design aims at trust-minimized compute: the inputs are permanent and public, so no single server must be trusted.

In a forge and wiki context, an AO process could act as a registry, recording which wiki export and Git tree form an official release, who claimed which issue, and which bounty was paid. Processes run in parallel, so each project could keep its own registry.

HyperBEAM

HyperBEAM is the production implementation of the AO-Core protocol, written in Erlang on the OTP platform. The public HyperBEAM documentation describes nodes that load modular components called devices. Requests reach devices through HTTP paths, and nodes route messages among themselves and out to the wider web. Documented devices include ~process@1.0 for shared executions and ~relay@1.0 for relaying messages.

The documentation also states that node operators can charge users for computation. The ~p4@1.0 device is described as a framework for operators to sell usage of their hardware, and ~simple-pay@1.0 as a pricing device for flat per-message fees. A forge or wiki service on HyperBEAM could therefore cover its own costs with small, transparent charges.

Why wiki and Git together

MediaWiki lets many people write prose together, with talk pages, recent changes, and readable history. Git lets developers track code, branch, merge, and tag releases. Most serious projects need both, yet they usually live on separate platforms owned by separate companies.

Joining them gives a single citation story. A release could say: this documentation export plus this source tree, named by these hashes, approved on this date. A reader, an archivist, or an AI agent could fetch both halves and verify them, and documentation would stay tied to the code it describes. MediaWiki stays the editing front end, a self-hosted forge stays the home for repositories, issues, and pull requests, and AO and Arweave sit underneath as ledger and archive.

Versioning and hashing

Both MediaWiki and Git are version control systems at heart. MediaWiki stores every saved revision with an id, author, timestamp, and summary. Git names each commit by a hash over the tree, parents, and metadata. Change one byte and the hash changes.

Content addressing extends that habit beyond one host. IPFS content identifiers, Arweave transaction ids, and Git commit hashes all name exact bytes. A manifest listing a MediaWiki revision id, a hash of the exported wikitext, a Git commit hash, and the Arweave transaction id of the stored bundle lets any mirror check integrity on its own.

Hashing diffs adds another useful layer. If each approved wiki change and merged patch is hashed as a diff, mirrors can compare small fingerprints instead of whole histories, and a mismatch points to the exact revision where two copies diverged. Applying Git-style discipline to wiki revisions would let federated wikis agree on history the way Git remotes do. Related ideas appear in Content-addressed wikis.

Federation with ForgeFed and Forgejo

ForgeFed is an extension of ActivityPub, the protocol behind the fediverse, designed to federate software forges. It describes how repositories, issues, pull requests, and comments can be shared across hosts, so a person on one forge can open an issue or submit a patch on another without a new account. Vervis is the reference implementation used to develop the specification.

Forgejo is a self-hosted, community-owned forge in the same class of tools as GitHub and Codeberg, and Codeberg itself runs on Forgejo. The name comes from the Esperanto word forÄejo, meaning forge. (This page means the Forgejo software forge, not any unrelated project with a similar name.) The Forgejo community has been working on federation with ForgeFed as a guiding protocol, and public reports describe that work as ongoing.

In this proposal, federation handles live collaboration while AO and Arweave handle permanence. Forges exchange ForgeFed-style activities, wikis could exchange signed revision notices, and only approved releases cross into permanent storage.

Micropayments and agent work

Gitcoin showed one way to fund open source: sponsors attached bounties to GitHub issues, and contributors who solved them were paid. People pick up well-scoped work when a clear reward is posted.

A permanent forge could take the idea further with very small fees. Posting an issue, claiming a task, or submitting a pull request could carry a tiny charge, similar in spirit to gas on smart contract networks but ideally far lower, closer to the fractions of a cent seen on Bitcoin Cash class rails. Small fees discourage spam and claim squatting while staying affordable. Bounties could be escrowed in an AO process and released on merge.

An AI agent could pay a HyperBEAM node for metered compute, pay a forge to submit a patch, and receive a bounty when it is accepted. Payment standards such as X402 and the patterns in Permissionless rails for agent pay and Agent-to-agent commerce point toward how those calls could work over plain HTTP. Short public release notes could travel through Bitcoin Cash Memo.

All of this is for legal, ethical uses such as funding maintenance, documentation, and security fixes. Nothing here is investment advice.

Safety before permanence

Permanent storage removes the option of deleting a mistake later. A leaked password, a private address, or a malicious link that reaches Arweave can outlive any cleanup on the live wiki or forge, so every write to Arweave or an AO registry should pass review first.

The gates described in Publish gates before permanence and Pre-publish checks for MediaWiki and Git apply directly: secret scanning on Git pushes, AbuseFilter-style rules on wiki saves, link reputation checks, personal data detection, and human review for borderline cases. Only a signed, approved manifest should trigger a permanent write. Posting fees reduce spam, yet they never replace these checks.

What is not claimed yet

This page does not claim that a combined MediaWiki, Forgejo, and AO product exists. Forgejo federation is still in progress, HyperBEAM ships no forge or wiki devices that this page knows of, and no fee level has been tested. It describes only what public documentation shows. The proposal maps how existing pieces could fit together, offered so builders can test, criticize, and improve it.

The vision is a commons where knowledge and code are editable today, verifiable tomorrow, and readable decades from now, in the spirit of Post-scarcity tooling.