Add WASM runtime support (future)

[N3xusFour]

Summary

Add WebAssembly (WASM) as a supported runtime for language-agnostic, strongly-isolated code execution.

Motivation

• Stronger isolation: WASM provides a second sandbox layer on top of gVisor/Docker
• Multi-language support: Run precompiled modules from Rust, Go, C/C++, AssemblyScript, etc.
• Capabilities model: WASI's explicit capability grants align well with the permissions design
• Fast cold starts: WASM runtimes (Wasmtime, WasmEdge) are lightweight and start quickly

When to Implement

This is a future/advanced feature. Consider implementing when:

• There's clear user demand for running Rust/Go/C# code
• Stronger isolation boundaries are needed beyond Docker+gVisor
• Performance-critical workloads where JS/Python aren't sufficient

Implementation Approach

Phase 1: Precompiled WASM modules

Accept precompiled .wasm files rather than source code:

1. Runtime image with Wasmtime or WasmEdge
2. Runner that:
   • Loads /workspace/main.wasm
   • Passes event/context via WASI stdin
   • Captures stdout as JSON result
3. No compile step in setup - users provide compiled WASM

Phase 2: Source compilation (optional)

If needed, add builder images for:

• Rust → WASM (via wasm32-wasi target)
• Go → WASM (via TinyGo)
• AssemblyScript → WASM

Builder images used only in setup phase; execution images stay minimal.

Example Dockerfile

FROM bytecodealliance/wasmtime:latest

USER 1000:1000
WORKDIR /workspace

COPY runner.sh /runtime/runner.sh

ENTRYPOINT ["/runtime/runner.sh"]

Example runner.sh

#!/bin/sh
# Read stdin, pass to WASM module, capture output
wasmtime run --dir=/workspace::/workspace /workspace/main.wasm

Considerations

• No npm/pip equivalent: Dependencies must be compiled into the WASM module
• WASI limitations: Network access, filesystem access controlled via capabilities
• Toolchain complexity: If adding source compilation, images become large

Effort Estimate

• Phase 1 (precompiled): ~1-2 days
• Phase 2 (source compilation): ~1 week per language

Acceptance Criteria (Phase 1)

• runtime: "wasm" accepted in setup request
• Precompiled .wasm modules execute correctly
• WASI stdin/stdout communication works
• Works with gVisor sandboxing
• Resource limits (memory, timeout) enforced