The verify URL & Verified badge

A published Altretta page carries its own proof and checks it in the reader's browser. The signed bytes travel with the page, and a small script on the page re-derives the hash, verifies the signature, and only then lets the badge say Verified.

What travels with the page

When Altretta publishes a note, it bakes a verification record into the page. That record is everything a reader needs to redo the cryptography themselves, with nothing left to look up:

• The canonical signed bytes — the literal strings that were hashed: the parent action hashes, the author JSON, the per-author sequence number, the RFC 3339 timestamp, and the payload JSON.
• The Ed25519 signature over that action.
• The signer's public key.
• The note's BLAKE3 content hash.
• The exact source Markdown those bytes cover.

What the reader's browser actually checks

A small self-contained script in the published bundle runs three checks, in order:

The badge fails closed

The badge is a claim, so Altretta only makes it once a check has actually succeeded.

• It starts in a "checking" state and stays there until all three checks pass.
• If any check fails, the page says so instead of quietly showing the mark.
• A browser without Ed25519 in WebCrypto reports that it could not check — never "verified". An unearned badge is worse than no badge.

What this proves — and what it does not

Two limits matter enough to state plainly rather than bury.

The public key travels with the page

The key that the signature is checked against is carried by the page itself. So a passing check proves that this page's content was signed by the key the page names — it does not prove who holds that key. There is no certificate authority in this picture and no binding to a person or an organisation. It is a self-attestation.

A reader who wants more than that has to do one thing Altretta cannot do for them: pin the key out of band — get it from you through a channel they already trust — and then compare it across everything you publish. A key that is the same across your publications, and that matches the one you gave them directly, is worth something. A key that only ever vouches for itself is worth exactly what it says: these bytes were signed by whoever holds this key.

This is the same admission the app makes about the in-app seal, and for the same reason. See Provenance & proofs.

The signature covers the source, not the rendered page

The signed bytes cover the note's source Markdown. They do not cover the HTML you are looking at. Between the two sits a renderer — Altretta's site builder, which turns Markdown into pages, rewrites wikilinks, and wraps everything in the site's chrome.

That is why the published page ships the signed source alongside the rendered version: a reader can read exactly what was signed and compare it with what they are being shown. The check is honest about its own boundary — it verifies the source, and hands the reader the source so they can judge the rendering for themselves.

The hosted verify URL: a second, different check

A hosted site also has a verify URL on my.apilium.com/verify/<slug>, shown next to the public URL when you publish. It answers a different question, and it is worth having for that reason.

The verify URL re-hashes the whole site tree as it is actually being served and checks it against a portal-signed attestation that the bundle has not been altered in hosting. It covers the things a per-note signature cannot: a page added after the fact, an asset swapped out, a bundle tampered with somewhere between your publish and the reader's screen.

Sharing the guarantee

When you share a hosted site, share both URLs: the public URL for reading, and the verify URL for checking the hosting. Readers who care about authenticity — auditors, collaborators, anyone relying on your published knowledge — get the per-note check for free the moment the page loads, and can follow the verify URL for the rest.

Related