An audit of what the federated wiki node server actually serves, from the wiki-server source. The finding: the read path is files all the way down. This grounds the Read Write Split.
## Static by Nature
The page route reads the flat file for a slug from the pages folder and sends it verbatim — no transformation. The sitemap, the sitemap XML, and the search index are prebuilt files in the status folder. The favicon is a file. Assets are files. Plugin client code is static bundles. The wiki client itself is one static bundle, and the lineup route is a small HTML shell that the client fills by fetching page JSON. Neighbours fetch page JSON and sitemaps cross-origin from the browser, so the one non-negotiable is a permissive CORS header on those routes.
## The Dynamic Rump
Everything else is the write side: the journal-action PUT, favicon upload, the recycler, the proxy route, login and claim, and the server routes some plugins register. All of it sits behind the authorization gate. A server with no owner and no security module is already read-only — the posture a static clone imitates for free.
## Derived Files
The server rebuilds sitemap and search index when a page is saved through it. Writing files straight to disk skips that machinery — the familiar stale-sitemap bug. The lesson for any split architecture: whatever performs the write must regenerate and republish the derived files. One writer, one rebuild, one publish.
## Prior Art
The wiki client's own README notes that read-only servers have been "realized with static files and cgi scripts". The wiki-ssg tool builds a static site from a data folder today. Static read-only federated wiki is a recognised deployment mode, not a trick. An earlier route list from 2017 lives at Fedwiki Server Routes; Serving Static Content and Static Site Generation hold the era's thinking.
## Links
# Assets
the-read-path
# See