// the find
WebAssembly/WASI
WebAssembly System Interface
WASI is the official WebAssembly System Interface specification — the standards body repo where API proposals are tracked, discussed, and formalized using the WIT IDL. It's not a library you import; it's the spec itself, plus the WIT definitions for things like filesystem, sockets, HTTP, and clocks. If you're building a Wasm runtime, a language toolchain, or a component-model host, this is the authoritative source.
The shift from 0.1's monolithic witx interface to 0.2/0.3's component model is architecturally sound — each API lives in its own proposal repo, has its own WIT definitions, and can be versioned independently. The 0.3 async story (native `future` and `stream` types instead of the awkward poll-and-streams bolted onto 0.2) fixes the biggest ergonomic pain point for anyone doing real I/O. The WIT IDL is genuinely good: it's readable, generates bindings for multiple languages, and makes the capability model explicit rather than implicit. The specifications directory gives you pinned, versioned overviews for each released version — useful when debugging a runtime that's stuck on an older snapshot.
This repo is a specification tracker, not an implementation — if you come here hoping to find runtime code or language bindings, you'll spend time figuring out that the real work lives in a dozen other repos (wasmtime, wasi-libc, etc.) with no single map to all of them. The proposals list is the closest thing to that map, but it's a markdown file that requires you to already know what you're looking for. WASI 0.3 is still a preview and async support in toolchains is patchy — Rust is ahead, but C/Go/Python support lags, so adopting 0.3 today means accepting that your non-Rust components may be stuck on 0.2 semantics for a while. The filesystem proposal's path resolution semantics differ enough from POSIX that porting existing code has surprises, and the documentation for those edge cases is scattered across proposal READMEs rather than consolidated.