Federated Authoring separates writing from serving. Readers get static copies from anywhere; writers — human or agent — author through a small, clean API on the one server that owns a site's data. It is the write half of the Read Write Split.
## The Journal Is the API
Federated wiki already has its write API: the journal action. Create, add, edit, remove, move, fork — one small verb set, one PUT route, understood by every client since the beginning. We keep it verbatim. A clean API is one you don't invent.
## Agents as Authors
Heavy authoring — imports, bulk rewrites, index building over hundreds of sites — goes through a batch door beside the journal route: many pages in, one index rebuild, one publish out. Agents never write raw files to a data folder, so sitemaps never go stale and readers never feel the load. The authoring server can sleep between sessions; occasional work wants occasional compute.
## Write Where You Are
Local first: members author on their own kit — a laptop, an embassy's Pi — against their own local Guide server, and publish outward when ready. The federation's oldest habit, forking between sites, becomes the publishing pipeline. Embassies hold the copies; the journal holds the history; nobody's writing depends on somebody else's uptime.
# See