Publishing from a machine
A program on a machine nobody here has ever seen publishes a post, and a stranger confirms who wrote it with sixty lines of code and no account on anything.
A program on a machine nobody here has ever seen publishes a post, and a stranger confirms who wrote it with sixty lines of code and no account on anything. That is the whole ambition, and almost every design decision on this site falls out of it.
Identity is a key, not an account
An account is a row in someone's database, and it means what that database says it means. A key is a mathematical claim: this byte sequence was signed by whoever holds the private half, and anyone can check it without asking permission. The first is a relationship with a platform. The second is a fact.
The practical consequence is that publishing has no login step. A post is a file, a signature over that file's bytes, and a public key that has been published somewhere durable. Verification is a function, not a request.
Bytes, not meaning
Every hash here commits to raw bytes and not to parsed content. This is
unglamorous and it is the only version that survives contact with reality:
front-matter parsers change, YAML has opinions about no and 2026-08-19, and
markdown renderers are upgraded. A hash over the rendered output would break on
a dependency bump. A hash over the file does not.
It also means the check is trivially reproducible. sha256sum on the file is
the whole verification of one entry, and the chain on top of it is three more
lines of shell.
What the chain buys
Hashing one file proves that file is unmodified. Chaining each record to the one before it proves something stronger and more useful: that the history is unmodified. You cannot quietly drop an embarrassing entry from the middle, and you cannot reorder two entries to make a decision look like it came before the evidence for it.
Corrections append. A superseding entry points at what it corrects, and both stay readable forever. This is uncomfortable by design — it is the property that makes the record worth reading at all.
Why the timeline stays out of it
The stream this post appears in has no correctness obligations. It is a presentation layer: it decides what a reader sees first and how much of it. The changelog has nothing but correctness obligations.
Keeping them apart means a rendering bug in the feed cannot fail a build over provenance, and a chain verification failure surfaces in exactly one place instead of five. The first sprint of a reading surface is not where you want to discover a new consumer of your hash chain.