A CMS made of four git calls

Velta has no content-management system in the usual sense — no server process, no database, no admin accounts. What it has is a single page that edits this site directly in its git repository. Every save is an ordinary commit. Git history is the undo, and the published site is just the repository served as files.

That page has to talk to some git host. The interesting part is how little of it cares which one. All host access goes through four operations — list a directory, read a file, put a file, delete a file — JSON over HTTPS, content base64 in both directions, with the file's sha acting as the concurrency token: put with a stale sha must fail rather than overwrite.

As of today that contract is written down: velta.cc/cms documents the four operations and what each must return. The GitHub-specific code that implements them is one small module, admin/backend-github.js, in the site source. A host that can answer the same four calls — through its API, or through hooks — can run this CMS unchanged.

Two properties fall out of the shape, and both are load-bearing. Reads need no account: the repository is public, so the CMS opens signed-out and the whole site is browsable exactly as stored. Writes need only a token with contents access, kept on the device — there is no server anywhere holding credentials to a third-party service.

If you want to poke at it, open the CMS — reading works without signing in. The contract lives at velta.cc/cms, and the source is in the site repository.