open-standards/wai/wai-web/demo

wai-web demo — interactive-worlds browser sink

world.html is a conformant wai.world.replay sink running in a tab: the WWLD payload (a tick-0 world + signed op log, ~1.3 KB for the truss vector) is re-derived frame by frame in WebGPU by the same wai crate native sinks run, compiled to wasm32 with the codec chain off (--no-default-features --features world). At the sealed final tick the sink recomputes the BLAKE3 state hash and compares it to the publisher's Ed25519-signed seal — replay-equivalence, demonstrated: the hash the browser computes is byte-identical to world-conformance/expected_hashes.json.

Run

# from wai-web/: rebuild the wasm pkg after engine changes
wasm-pack build --target web --out-dir demo/pkg

# vectors come from the conformance corpus
cp ../world-conformance/vectors/{truss_fracture,ballistic_bounce,basic_kinematics}.wwld demo/vectors/

# serve (any static server; WASM needs http, not file://)
python3 -m http.server 8741
# → http://localhost:8741/demo/world.html

Needs a browser with WebGPU enabled. No build steps beyond wasm-pack; no JS dependencies.

int_synth.html — integer-exact neural image sink (no ML runtime)

int_synth.html decodes a wai.neural.int_synth payload to RGB with the same pure-i64 Rust that decodes natively, compiled to wasm32 — no onnxruntime-web, no WebGPU, no float. Because the decode is integer all the way down (the integer-entropy contract, SPEC §6), the reconstruction is byte-identical on every machine, so the page re-checks its BLAKE3 against the hash the native reference froze into neural-conformance/expected_hashes.json. The four staged vectors (demo/int_synth/, copied from the corpus) include the real trained photo model (128×128, 21.6 dB PSNR).

# from wai-web/: build the web pkg, then serve
wasm-pack build --release --target web --out-dir demo/pkg --out-name wai_web
python3 -m http.server 8741   # → http://localhost:8741/demo/int_synth.html

Reproducible CLI proof that the wasm decode equals the native corpus (builds the nodejs-target pkg and checks all four vectors' hashes):

./demo/verify_int_synth.sh

Staged delivery — StageSink in the browser

src/stage.rs binds wai::staged::StageSink, the staged-delivery sink a native player runs (extensions/staged-delivery.md), for JS: StageBase.decode decodes a base envelope by SPEC §4 through the integer path, with its pin and under the page's cost limit; StageBase.fromStage0 takes a base the page decoded elsewhere, which is claimed (its chain's reports, units and stage hashes say so). StageSink adds bases (taking them), offers refinement layers, expires holds and removes bases in any order, and every unit's stage, producer, tier, output and stage hash reads back. stageLayerInfo reads a layer's refines, WIR1 header and declared cost, and a base's declared decode cost, before either is offered. Reports and units come back in the corpus's own form (staged-conformance/README.md).

verify_staged_wasm.mjs replays every case of staged-conformance/ through the wasm32 build and requires every report, final unit, stage hash and clip hash the native sink wrote; each integer base is decoded in wasm32 and must give its stage0.bin. It then checks the binding's guards: bases that declare huge clips (wai-rs/tests/vectors/staged_bounds/) refused under a cost limit with linear memory watched, a base past the chain budget, base facts a page cannot raise, and a seeded fuzz that must not trap:

# from wai-web/
cargo build --release --target wasm32-unknown-unknown
wasm-bindgen --target nodejs --out-dir demo/pkg-node --out-name wai_web \
  target/wasm32-unknown-unknown/release/wai_web.wasm
node demo/verify_staged_wasm.mjs ./pkg-node/wai_web.js ../staged-conformance

Staged measurement — the native figures in the browser

src/measure.rs binds wai::stage_measure, the code the native measurement tool wai_stage_measure runs (extensions/staged-measurement.md), for JS. A title is read from a Map of files by their path below wai/: titleMissing(dir, files) names the next file it needs, so a page fetches files one at a time until it holds them all. evaluateTitle (or new MeasureTitle(dir, files).json()) gives the text wai_stage_measure eval --json prints: counted bytes per object, stage and prefix, quality integers per presentation and per prefix, first presentable bytes, the layering overhead's points, deduplication and the output tree. simulate and simulateModel give the text wai_stage_measure sim prints. countObject counts one envelope (or names the code it is not countable with), qualityRgb8 gives one picture pair's integers (sums of squares as decimal strings), and outputRoot the output tree's root over presentations.

sessionBegin(entry, host, nonce) is wai::session_recorder::SessionRecorder over the session's entry object: decoderFor names the decoder that decoded an envelope, presented and received record what the page did, and finish(seed, signer_id, issued_at) seals the reconstruct-session claim (extensions/jwp-receipts.md §2.4.12), checked against the record first; a browser session states no energy figure. verifyClaim(claim, outputs, objects) checks a claim against the presentations and the objects received, and gives "" or the reason.

verify_measure.sh builds the nodejs package (or takes one already built), runs verify_measure_wasm.mjs over staged-measure-conformance/ — every golden, refusal title, counted object, quality pair and simulator case, byte for byte, and a session per fixture recorded the way a page records one, which must be the native tool's claim byte for byte — then requires the native wai_stage_measure eval --json to equal the wasm32 evaluation of every fixture, and the native and independent Python claim verifiers to give the wasm32 build's verdicts on every session it sealed:

# from wai-web/ (claim_verify.py needs the `cryptography` package)
bash demo/verify_measure.sh