Federate archives via content mounts

Prerequisites

• Two media-knowledge-* content repositories on the same filesystem (or a shared mount like NFS)
• Read access from the primary instance's process user to the secondary repository's content directory
• knowledge.toml write access on the primary instance

Purpose

Read a second instance's articles from a running instance without copying files — the mechanism app-mediakit-knowledge calls a content mount. This is narrower than a "federation" in the isolated, namespaced sense the term usually implies: mounted content joins the same flat slug space as everything else the instance already serves.

Procedure

1. On the host running the secondary content, confirm the primary instance's process user can read it:

   sudo -u <wiki-process-user> ls /srv/wiki/media-knowledge-projects
   

   If the path is on a remote host, mount it locally first. A path that's absent at startup causes the mount to be skipped, not to error.

2. Declare the mount in the primary instance's knowledge.toml. See Use declarative knowledge mounts for the full mechanical steps and the real Mount schema (path, role, blueprint_set — no URL-prefix field exists).

3. Restart the primary instance. Both the config and the mounted content are read once, at startup — changes on either side require a restart to take effect.

4. Access an article from the mounted repository at the same /wiki/<slug> path pattern the primary uses for its own articles — there is no separate namespace or prefix to navigate to.

Expected outcome

The primary instance serves both its own articles and the mounted repository's articles, indistinguishably, from one merged content index.

Verification

Confirm an article you know exists only in the mounted repository resolves correctly, and — critically — confirm neither repository has an article with a slug the other one also uses. See Use declarative knowledge mounts's verification steps for exactly how to check.

Warning: wikilinks inside mounted articles resolve into the same merged namespace as everything else, with no existence check — a [[some-slug]] link works if that slug exists anywhere across every mount, and produces a dead link if it doesn't, regardless of which repository originally contained it. Don't assume a mounted article's internal links stay scoped to its own source repository.

Rollback

Remove the [[mount]] entry and restart. See Use declarative knowledge mounts for what to check if a slug collision already shadowed an article before you noticed.

Next steps

• Use declarative knowledge mounts — the full step-by-step mechanics and the real schema
• Deploy a knowledge instance — provision the instance that will serve federated content

See also

• MediaKit knowledge application — the wiki engine that processes mount declarations