Client-side verification: no trusted server, math is the authority

[joelteply]

Problem

The current verification page (cambriantech.github.io/forge-alloy/verify/) is a single point of failure and trust. If compromised, it shows fake provenance. The website should NOT be the authority — the math should be.

Design

Alloy is self-verifiable

The alloy JSON contains everything needed to verify itself:

• Model hash (SHA-256 of weights)
• Code hash (SHA-256 of forge binary)
• Attestation signature (ES256/EdDSA)
• Public key of the signer

Verification runs CLIENT-SIDE

The verification page is a static JS app that:

1. Fetches the alloy from ANY source (URL param, file upload, QR scan)
2. Recomputes hashes locally in the browser (Web Crypto API)
3. Verifies signatures locally (no server round-trip)
4. Displays results — green checkmarks or red X per claim

The page could be hosted anywhere — GitHub Pages, IPFS, locally. The JS is the same. If our page goes down, anyone can host a copy. The math doesn't change.

No single point of trust

Component	Trust Model
Alloy data	Fetched from HF, IPFS, local — multiple sources
Verification logic	Client-side JS, open source, anyone can audit
Hosting	Static page, hostable anywhere, no server state
Signing keys	Public keys in the alloy — verifiable by anyone
Model weights	Hash in alloy vs actual file — user verifies locally

QR code contains

Option A: Full compact alloy (<3KB, fits in high-density QR)
Option B: Hash + URL to fetch full alloy from HF/IPFS

CLI verification

forge-alloy verify model.alloy.json --model-dir ./weights/
# Checks: alloy signatures, model hash vs weights, code hash
# No network needed if alloy file is local

Spec

The alloy schema must define the verification algorithm so ANYONE can implement a verifier — not just our tools. The algorithm is:

1. Parse alloy JSON
2. Verify attestation signature against public key
3. Recompute model hash from weight files
4. Compare computed hash to claimed hash
5. Check code hash against known forge binaries
6. Verify Merkle chain if present

Same principle as bitcoin: you don't trust a website to verify transactions. You run the math yourself.

Priority

High — trust infrastructure must be right before public grid economy (#716).

Related

• Stage types are LLM-specific — forge-alloy should be domain-agnostic #7 Domain-extensible stages
• continuum#716 Grid economy (credits, reputation)
• continuum#717 QR pairing + passkey auth
• Joel's FIDO2/WebAuthn expertise — same attestation model