PWA boot-blob — a layer-1, verifiable UI for Hooks

[Hugegreencandle]

The problem

In every "decentralized" app the contract is trustless but the UI is not — it lives on
a web host that can be rugged, MITM'd, or silently swapped. We can close that last gap on
Xahau: a UI whose root of trust is the ledger itself.

The idea (credit to Richard Holland)

Store a very small PWA "bootloader" on-chain — the only thing a wallet has to trust.
It loads a larger stage-2 app from anywhere (Evernode / IPFS / magnet) and verifies it
before executing a byte. A secure-boot chain, rooted in the ledger. Richard's framing:
"fairly similar to remarks, but a dedicated PWA boot blob for each account or hook."

 wallet ──renders──► [L1 boot blob] ──fetch──► stage-2 (off-chain) ──verify hash──► run
 (iff match)
  trusts L1 only      small, on-chain,         heavy, swappable
                      pins the policy

Why it's the provable version

A bootloader's verify core is small + bounded, and its safety property is one invariant:
never run bytes whose hash ≠ the pinned policy — exactly what
xahc-prover proves on Hooks (accept ⟹ condition). So this closes one link — the gate's accept logic: accept ⟹ candidate hash == pinned hash (32B), the same byte-exact discipline as the guardrail's dst-lock. Three things stay out of model and trusted, and I want to be explicit: (1) the on-chain SetBoot tx stores the blob verbatim and verifies nothing — the pin/compare is a wallet-side convention, not protocol-enforced; (2) the wallet's SHA-512Half over the fetched stage-2 bytes; (3) stage-2 sandboxing. It proves the gate, not the whole boot chain — and the proven artifact is a reference model, not a deployed hook.

Proposed v1 (a storage primitive only)

xahaud's job is to store + serve the blob; the bootloader runtime
(fetch/verify/sandbox) is wallet-side. Modeled on the Remarks amendment:

• a new SetBoot transactor + sfBootBlob (VL), amendment-gated, fee scaled per byte
  so the stub stays small (proposed cap ~4 KB);
• owner-key-mutable by default, optional tfBootImmutable to lock it (fixed-pin);
• a wallet resolve → verify → render → capability-sandbox standard (stage-2 may talk
  only to its own Hook, no arbitrary egress).

A reference PoC (boot-blob + a "loads-only-verified" proof against a proven
agent_guardrail Hook) is in progress so we react to running code, not theory. (Build
rig is up; a SetBoot scaffold is drafted against the Remarks pattern.)

Open design questions

Ledger (for Richard Holland):

1. Key it per-account (start) with a per-hook target as a follow-up, or per-hook
   from day one?
2. Optional field on AccountRoot (simplest) vs a dedicated ltBOOT object
   (cleaner for owner-reserve + per-hook keying)? Leaning dedicated long-term, field for the
   PoC.
3. Size cap + reserve economics — does ~4 KB + per-byte fee feel right?

Wallet (for Wietse Wind):
4. The capability/sandbox model is yours to shape — what constraints does Xaman want
on stage-2 (Hook-only messaging? no network? scoped signing only)? Xaman already ships the
webview surface, so it's the natural delivery path.

Context

Builds on the Hooks pipeline: write (xahc) →
simulate (xahau-mcp) → prove
(xahc-prover) → watch
(xahc-watch), with
(evernode-mcp) for stage-2 delivery.
Modeled on the Remarks amendment (#301).

[Hugegreencandle]

PoC's up 👇 a working SetBoot transactor + PWABoot amendment — tested (set/replace/delete,
bounds, amendment-gated) and building clean into the node.

#760

draft on purpose — opened early so we shape the ledger object together (per-account vs
per-hook, field vs dedicated object). proof of the verify core is next.

[Hugegreencandle]

Verify-core proof landed — the next step I flagged on this PoC.

Both core links are now proven for all inputs (xahc-prover): boot-only-the-pinned-blob (the gate) and owner-only + strictly-monotonic re-pin (no downgrade). Writeup + runnable demo:
github.com/Hugegreencandle/xahc-prover/blob/main/docs/PROVABLE-UPGRADES.md

Proving the gate surfaced the next gap: since sfBootBlob is owner-mutable, an authorized owner can re-pin to a new blob that's itself regressed/malicious — gate + authz both pass, target's unsafe. "Authorized ≠ safe."

A way to close it without touching SetBoot: a re-pin is certified only if the new blob re-proves its named invariants → signed proof-registry entry (fail-closed: an unproven blob can't be certified) → a watcher that flags the moment deployed code ≠ proven code. An upgradeable boot target that's always provably-current or loudly flagged.

Honest residual — maps onto the open stage-2 sandbox question: this proves the named invariants, not stage-2 sandboxing or any dimension you don't prove. SetBoot still stores the blob verbatim; this is an assurance layer, not a node check.

Design question: re-pin certification at protocol-level (a field/flag on SetBoot), wallet-UX, or pure tooling? My lean is tooling + wallet-UX, keeping SetBoot minimal.