RFC: gaps for out-of-tree WASI/WIT module support

[matthargett]

I ship an Apple app (currently in TestFlight, demonstrated at HOPE 2026 conference a last month) that runs untrusted .wasm guests on Apple TV 4K (A10X), iPhone XS (A12), and Apple Watch SE2/6 (S4, technically A14 efficiency CPU cores and slightly cut-down GPU). we currently integrated WAMR, and are evaluating TinyWasm. Our target is currently wasm32-wasip2 components on WASI 0.2.6; native capabilities are statically linked—we do not need dynamically loaded WASI modules. Most of our WASI/WIT is W3C API shaped, and I'm attributing each in-tree request to the specific module that currently works under the WAMR integration.

I agree with the direction in #62: keep component handling, canonical ABI, resource tables, and custom WASI/WIT modules out of TinyWasm. It decouples maintenance overhead from a shifting standard, and lets crazy people like me innovate :D WASIp1-only users should only see negligible code-size and call-path impact that doesn't affect their low-end embedded deployment scenarios.

The concrete integration needs I can see right now are:

• Preview 2: checked canonical-ABI memory access, realloc/post-return, and resource ownership.
  • custom WASI modulescompression-streams passes list<u8> chunks and stream resources
  • w3c:file-system-access/read-only-file-picker returns a selected-file resource backed by wasi:io/streams.input-stream
  • w3c:web-audio/realtime-render adds short-lived WASM worklet workers and resource cleanup across threads
• Untrusted guests: bounded parse work and memory/resource accounting across worker restarts, including pathological compressed inputs. We will try existing allocator/limiter APIs first and bring small failing fixtures for any missing core seam.
• Preview 3: async functions, futures, and streams
  • replace the current wasi:io/pollevent-queue pattern in w3c:web-speech/speech-recognition, shape-detection-camera/live-camera-detection, and WebAudio worker notifications. Polling is a not great for Apple Watch performance or battery life on any mobile device.
  • An opt-in host-call suspend/wake/cancel seam may be needed; realtime audio callbacks must not block to avoid regressing the audio glitching/skipping I worked hard to eliminate on my real devices.
• General: A stable component-to-core handle seam
  • Exported functions and memories are accessible today, but ordered instantiation is marked unstable and internal by-index access is gated for debugging.
  • If a valid component cannot express its selected memory, realloc, or post-return function through the stable export APIs, I'd request (or can contribute) the smallest store-checked handle API that allows this to durably work end-to-end

Which core APIs would you prefer an external layer to rely on (eg they'll be reasonably stable)? I can contribute narrow, independently tested changes when a concrete fixture demonstrates a gap we can't solve out of tree, but is there a specific place you'd like me to start?

[explodingcamera]

I opened an issue for async host functions since that's something I already want to add and it should cover the async host-call side of this.

I'll also take another look at the exports / extern API. The C API still needs some internal APIs there too, so there's probably some stuff we should expose / clean up anyway.

For anything else I'd rather see what actually ends up being missing and add smaller APIs as needed.

I'll move this to a discussion since that seems like a better fit for figuring out the integration surface.