skip to content
donmai
donmai is in 0.x preview. APIs may change between minor releases. See the changelog.
docs · donmai documentation · rev 2026-06-11github.com/RenseiAI/donmai
appendix

Verify a page

How the record chain on donmai.dev is computed, what [verify this page] actually checks, and what it does and does not prove.

Every marketing page on this site (the overview, the changelog, and the about page) is a record document: its rendered content is hash-chained at build time, and the [verify this page] control in the footer recomputes the chain in your browser. This appendix is the method. The verifier and the build script ship MIT with this site's source, and everything below demonstrates against donmai.dev's own pages only.

What gets hashed

Each chapter of a record document is a section[data-record-scope]. At build time, the record step canonicalizes every chapter:

  1. Walk the rendered DOM in order, collecting text content.
  2. After each link, append an [href:<absolute url>] token; after each image, append an [img:<src>|<alt>] token. Links and figures are part of the record, not just prose.
  3. Skip script, style, template, and noscript subtrees, and any element marked data-record-ignore (client-mutable UI such as copy buttons).
  4. Normalize to NFC, strip zero-width characters, collapse whitespace.

The chain then computes, for each chapter nn of document docId:

rec_nn = SHA-256("{docId}/{nn}\n{prev}\n{canonicalized chapter}")

where prev for the first chapter is the hash of the page's doc strip, and each later chapter's prev is the previous chapter's record. The page hash is the SHA-256 of all record hashes concatenated. Every hash printed on a page (the record lines, the footer page record) is substituted from this computation at build; nothing is hand-typed. The build then re-parses its own patched output, recomputes the chain, and fails on any divergence.

What the verifier checks

[verify this page] runs the same canonicalization over the DOM your browser is currently showing and compares it to the manifest that shipped with the page. Three outcomes:

  • verified (green): the prose, links, and figures in your browser match the built record, complete and in order.
  • modified in browser (amber): your DOM differs, but the document the server sent verifies intact when re-fetched and parsed inert. This is the common, benign case: in-browser translation, Grammarly, ad-block cosmetic filters, Dark Reader, or an enterprise DLP extension rewriting text. The chain catching exactly this is the point.
  • chain break (red): the served document itself does not recompute. Reserved for real tampering or a broken build.

Try it: open the overview and click [verify this page] in the footer. To see the amber state, toggle any extension that rewrites page text (a translator is the quickest) and verify again.

What it does not prove

The chain proves the prose, links, and figures you received are the ones that were built, complete and in order. It does not prove the claims true, and it does not cover attributes outside the canon above, page styling, or script behavior. Docs pages (including this one) are not record-chained; they print honest provenance (rev date and build time) instead of a hash.

doc docs/appendix/verify-a-pagerev 2026-06-11 · built 2026-06-12T02:54Z