current
WASI proposals
WASI APIs are developed as proposals. These proposals go through 5 phases of development (following the WASI Subgroup’s Phase Processgithub).
You can learn more about contributing new proposals (and other ways to contribute) in our Contributinggithub guide.
Active Proposals
Phase 5 - The Feature is Standardized (WG)
| Proposal | Champion | Versions |
|---|
Phase 4 - Standardize the Feature (WG)
| Proposal | Champion | Versions |
|---|
Phase 3 - Implementation Phase (CG + WG)
| Proposal | Champion | Versions |
|---|---|---|
| Clocksgithub | Dan Gohman, Colin Murphy | |
| Randomgithub | Dan Gohman, Roman Volosatovs | |
| Filesystemgithub | Dan Gohman, Victor Adossi | |
| Socketsgithub | Dave Bakker | |
| CLIgithub | Dan Gohman, Lann Martin | |
| HTTPgithub | Pat Hickey, Lann Martin, John VanEnk |
Phase 2 - Proposed Spec Text Available (CG + WG)
| Proposal | Champion | Versions |
|---|---|---|
| Clocks: Timezonegithub | Dan Gohman, Colin Murphy | |
| HTTP: Informational Outbound Responsegithub | Pat Hickey, Lann Martin, John VanEnk | |
| I2Cgithub | Friedrich Vandenberghe, Merlijn Sebrechts, Maximilian Seidler | |
| Key-value Storegithub | Jiaxiao Zhou, Dan Chiarlone | |
| Machine Learning (wasi-nn)github | Andrew Brown and Mingqiu Sun | |
| Runtime Configgithub | Jiaxiao Zhou, Dan Chiarlone | |
| WebGPUgithub | Mendy Berger, Sean Isom | |
| Messaginggithub | Jiaxiao Zhou, Dan Chiarlone, Taylor Thomas. |
Phase 1 - Feature Proposal (CG)
| Proposal | Champion | Versions |
|---|---|---|
| Blob Storegithub | Jiaxiao Zhou, Dan Chiarlone. | |
| Cryptogithub | Frank Denis and Daiki Ueno | |
| GPIOgithub | Merlijn Sebrechts, Maximilian Seidler | |
| Distributed Lock Servicegithub | Jiaxiao Zhou, Dan Chiarlone. | |
| Logginggithub | Dan Gohman | |
| Observegithub | Caleb Schoepp | |
| Parallelgithub | Andrew Brown | |
| Pattern Matchgithub | Jianjun Zhu | |
| SPIgithub | Merlijn Sebrechts | |
| SQLgithub | Jiaxiao Zhou, Dan Chiarlone. | |
| SQL Embedgithub | Robin Brown | |
| Threadsgithub | Alexandru Ene, Marcin Kolny, Andrew Brown | |
| TLSgithub | Joel Dice, Dave Bakker, James Sturtevant | |
| URLgithub | Radu Matei | |
| USBgithub | Wouter Hennen, Warre Dujardin, Merlijn Sebrechts | |
| OTelgithub | Caleb Schoepp, Andrew Steurer |
Phase 0 - Pre-Proposal (CG)
Note: The pre-proposal phase is simply meant as a way to share ideas. This means that there may be overlap between pre-proposals. It also means that the WASI subgroup has not yet decided that the pre-proposal is in scope for WASI.
| Proposal | Champion | Versions |
|---|
Inclusion in WASI 0.3
WASI 0.3 (also known as Preview 3, or WASIp3) corresponds to versions numbered
0.3.x in Wit packages and related identifiers.
To be included in WASI 0.3, a proposal must:
- Reach phase 3 in the WASI Subgroup’s Phase Processgithub
- Satisfy its own portability criteriagithub
- Be voted for inclusion by the WASI Subgroup
Versioning
Once a proposal reaches Phase 3, we expect the champions to start creating releases, following the conventions of semantic versioning (semver). Releases for active proposals are linked in the chart above.
Proposals remain in the 0.x semver range until they reach Phase 5 and are fully standardized. At that point, a 1.0 release should be made available.
For some APIs, it makes sense to add new features after the API itself has reached Phase 5. These feature additions should go through the same standardization process. Once they have reached Phase 5, the minor version number of the release should be incremented.
Some APIs may require backwards-incompatible changes over time. In these cases, we allow proposals to increment the major version number only if the old API can be implemented in terms of the new API. As part of the new version, champions are expected to provide a tool that enables this backwards-compatibility. If that is not possible, then a new API proposal with a new name should be started. The original API can then be deprecated over time if it makes sense to do so.