WASM Support

[commial]

Supporting a WASM version of MLA would be nice. For instance, it would allow the support of:

• in-the-browser opening of compressed and encrypted HTML reports
• a platform agnostic GUI (in the browser)

Targeting WASM in Rust has some requirements. This issue is made to track them.

---

For now, compiling to WASM WASI is working:

# Compile to WASI
$ cd mlar
$ cargo build --target=wasm32-wasi --release

# Get the resulting `wasm` file
$ cd /workspace/MLA/target/wasm32-wasi/release/
$ file mlar.wasm 
mlar.wasm: WebAssembly (wasm) binary module version 0x1 (MVP)

# Execute it using `wasmtime` (file access is sandboxed)
$ wasmtime  mlar.wasm list -i /workspaces/MLA/samples/archive_v1.mla -k /workspaces/MLA/samples/test_x25519_archive_v1.pem
...
[ERROR]
...
failed to find a pre-opened file descriptor
...

# Allow accesses to the source directory
$ wasmtime --dir /workspaces/MLA/samples/  mlar.wasm list -i /workspaces/MLA/samples/archive_v1.mla -k /workspaces/MLA/samples/test_x25519_archive_v1.pem | head
big
file_0
file_1
file_10
file_100
file_101
file_102
...

[extiop]

As of today, Rust glue, to enable Wasm interactions in the browser, to web components can made with polyfills from the well-known wasm-bindgen toolchain such as :

• web-sys for WebIDL, which is web main standard for its API (https://github.com/rustwasm/wasm-bindgen/tree/main/crates/web-sys)
• js-sys for JS (https://github.com/rustwasm/wasm-bindgen/tree/main/crates/js-sys)

Also, there is WASI which aims to be an ABI standard for Wasm thus running anywhere (https://wasi.dev/). WASI 0.2 preview (https://bytecodealliance.org/articles/WASI-0.2) is stable enough to be used in browsers with jco transpiler (https://bytecodealliance.org/articles/jco-1.0) which is a native JavaScript WebAssembly toolchain and runtime built for WebAssembly Components (cf. https://component-model.bytecodealliance.org/design/why-component-model.html) and WASI 0.2 preview.

Thereby, we need to evaluate the need to interact with WebIDL and JS in a Wasm version of MLA which targets in-the-browser opening of compressed and encrypted HTML reports, thus a browser GUI.

Then, options are :

• The GUI interaction (WebIDL or JS) could be incorporated in Rust, thus importing JS functions : this one is not preferred as web languages are well-suited for web design and scripting for the moment (thus the GUI).
• MLA could be imported as a Wasm module and used in a HTML / JS GUI without the need to import JS functions on the Rust side. Still there will be HTML / JS interaction. Two suboptions :
  • Target wasm-bindgen with js-sysand web-sys.
  • Target WASI 0.2 with jco. As Rust considers WASI as a relevant option (cf. https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html), it could be interesting to dig this one first.

Update (23/08/25): WASI 0.3 will be released soon, and version 1.0-rc1 is expected in Q1 2026 (see: https://wasi.dev/roadmap). Therefore, continuing to support WASM via WASI for MLA remains both promising and relevant.