What’s The State of WASI?
The WebAssembly System Interface (WASI) specification is a proposed standard that describes how to connect a WebAssembly application to its underlying environment. Designed with security at the fore, WASI describes mechanisms for Wasm applications to interact with system resources such as clocks, sockets, filesystems, environment variables, and other Wasm components.
What does it mean to be a WebAssembly standard?
The original WebAssembly project was jointly created by Mozilla, Google, Microsoft, and Apple in order to provide a common language runtime inside of the web browser. Following the path of web standards like HTML and CSS, the early Wasm creators decided to standardize the technology through the W3C.
Nearly a decade later, the W3C standardization of WebAssembly is moving along well. WebAssembly 1.0 was completed in December, 2019. And there is a candidate draft of the 2.0 version of the Core WebAssembly Specification, posted in December of 2024.
The WebAssembly standardization process consists of multiple specifications. Originally one for the core WebAssembly instruction set and one defining the integration with JavaScript running in the browser. In 2019, the WebAssembly standardization group started the WASI subgroup to work on an additional specification for generalized integration into other environments as well as defining how different WebAssembly programs communicate with each other.
When it comes to the nuts and bolts of building a standard, essentially there are three big tasks:
- The drafting and re-drafting of the candidate standard. This involves a lot of thinking, writing, and discussing among the members of the WASI subgroup.
- Implementing the standard as a proof that the ideas work in practice.
- Walking through the formal W3C standardization process, including all of the writing, discussing, and voting.
Steps 1 and 2 usually happen in parallel, informing each other, and require a significant number of people to do a substantial amount of work before a candidate specification is even ready for presenting in the context of the W3C working group. In the WebAssembly world, much of that work is done by a collective of engineers called the Bytecode Alliance.
The Bytecode Alliance maintains a number of open source WebAssembly projects, including two WebAssembly runtimes (Wasmtime and Wamr), the component model tools, and language-specific tooling like jco for Javascript and componentize-py for Python. Members of the Bytecode Alliance also do substantial work on standards for the W3C.
When it comes to WASI, the Bytecode Alliance is instrumental in both authoring the specification and building the reference implementations. But to be clear, the Bytecode Alliance itself is not a standards body. The standards are still advanced under the W3C.
What is (and isn’t) included in WASI?
The early work on WebAssembly had focused on integration with a browser. But WebAssembly’s creators realized from the beginning that it could be used outside of the browser. But instead of a browser interface, it needed a more general system interface that could be supported in all kinds of environments.
Modeled on the widely supported POSIX standard, WASIp1 brought in the sort of systems facilities common across a huge number of non-browser applications, including access to the clock, a filesystem representation, environment variables, command line, and random numbers.
Launched in early 2024, WASIp2 included support for HTTP servers and clients (wasi-http) and other higher-level concepts such as Key-Value Stores (wasi-keyvalue). It also changed WASI to be based on the WebAssembly Component Model, enabling WebAssembly programs to communicate with each other using the same interface language they use to communicate with the host: WebAssembly Interface Types, or WIT. And the WASIp1 interfaces were re-described using WIT. (For a solid explanation of the Component Model, check out Joel Dice’s introduction.)
Now, WASIp3 is nearing technical completion. WASIp3 introduces a major new feature: Highly advanced language-neutral support for asynchronous communication. This means that one component can delegate work to another component asynchronously, and then be notified when that component has completed its work. Asynchronous support is game-changing, as it opens up the possibility for sophisticated cross-component composition regardless of the component’s internal representation of concurrency. So, for example, a JavaScript component can make an async call to a Rust component without knowing anything about Rust’s internals.
After WASIp3, the plan is to work toward a final solidification of the specification. Once WASIp3 is complete, attention will be turned to finalizing WASI 1.0 as a stable standard for the next few decades. Other than incremental changes to p3, the specification is nearing completion.
When will WASIp3 be done?
Again, returning to the process by which WASI is standardized, the steps are:
- Draft the standards proposal
- Implement the proposal in a runtime
- Standardize the proposal
In this process, step 2 is just about complete: we have a full implementation in Wasmtime nearing completion. We at Fermyon have already been building things using a snapshot of WASIp3, and we believe that the implementation will be complete by the middle of 2025.
Then it’s off to the third step, with the standard being discussed by the WASI subgroup. After that, the focus will shift to the remaining bits planned for WASI 1.0, planned to be done in 2026.
That may feel like a long time. But remember that the goal of a standards body is to delve into the most minute details in order to assure that, when standardizing a technology, that tech is then stable for use for decades to come.
That does not necessarily speak to the production readiness of the technology. I was comfortable using WASI in production back in 2018, and Spin apps have run in production since 2022. Even as WASI has changed, Spin and other tools have simply provided backward compatibility. It is already a far more stable ecosystem than many technologies experience even after standardization.
Getting Involved
If you ware interested in WASI, you can learn how to join the community work at the official WASI site. Spin work to incorporate WASIp3 is ongoing, and you can head over to the CNCF Spin site to get started (or skip straight to the GitHub repo). There’s much to do, and we’d love to have you join!
