Changes touching this path
- Extract loot-codec + wasm core; de-risk the in-memory SDK boundary (#423)
Slice 1 (the tracer bullet) is a multi-session build; this lands its
riskiest integration — the Rust→WASM crypto/codec boundary — proven
end-to-end, per the #381 "verify spikes before building" mandate.
Spike result (ADR 0040): zstd-sys will not build for wasm32
(needs clang for its C), while aes-gcm/blake3/ed25519/getrandom-js do.
So:
- Extract `loot-codec`: a no-fs, wasm-buildable crate holding the byte
format, sync-bundle codec, sealed content (AES-GCM + blake3), and the
leaf types (Oid/Visibility/RepoError/ChangeNode). loot-core depends on
it and re-exports every item at its original path — a pure relocation,
proven by the unchanged, still-green workspace (767 tests pass).
- zstd is an optional loot-codec feature (default on for the native host;
off for wasm). A new zstd-free `sealed::decrypt` single-sources the
AES-GCM step so native `open` and the wasm core share decrypt code;
public content is inflated host-side in JS.
- `loot-wasm`: wasm-bindgen exports (bundle decode, decrypt, blake3
address) over a pure native-testable `core`, plus the minimal diskless
identity (generate/fromSeed/publicKey) on ed25519 directly — not
loot-identity, whose OpenSSH/passphrase machinery is native-only (#383).
- Golden-parity harness (loot-wasm/tests/parity.rs) runs identical
assertions natively and under `wasm-pack test --node`, freezing
native-computed vectors; both green.
Remaining for slice 1 (next sessions): the TS package, fetch transport +
client-side path-scoping, host-side zstd, and the live-relay behavior
suite.
Refs #423, #421. ADR 0040.
491cf780 · dbf3dbe6…
Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.