Snapshot Preview 1 is the standard all tools are building to right now. The specification is available here: https://github.com/WebAssembly/WASI/blob/main/legacy/preview...
It's pretty unreadable though!
Preview 2 looks like it will be a big change, and is just being finalised at the moment. I'd expect that when preview 2 is available there will be an improvement in the quality of documentation. I'm not sure how long it will take after release for tools to start switching to it. I'd expect Preview 1 will still be the main target at least for the rest of this year.
In Running WASI binaries from your HTML using Web ComponentsWebAssembly
WASI
Rust2019–2026
WebAssembly / WASI
WASI
WebAssembly System Interface
52Distinct people
57Mentions
0Explicit recommenders
5.8KGitHub stars
What to know before exploring
What it is
WebAssembly System Interface
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- bytecodealliance/wasmtime · linked in 2 of the same discussions
- webassembly/component-model · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:00:59 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year57 dated mentions
Observed mentions: 2019-06-01 02:23:09 UTC to 2026-08-13 14:37:56 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 5 | 2 | 3 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
WebAssembly System Interface
The WebAssembly System Interface (WASI) is a set of APIs for WASI being
developed for eventual standardization by the WASI Subgroup, which is a
subgroup of the WebAssembly Community Group.
WASI started with launching what is now called Preview 1, an API using
the witx IDL, and it is now widely used. Its major influences are POSIX and
CloudABI.
WASI 0.2 (Preview 2) is a modular collection of APIs defined with the Wit IDL,
incorporating many of the lessons learned from WASI 0.1, including support for
a wider range of source languages, modularity, a more expressive type system,
and virtualizability.
WASI 0.3 (Preview 3) is the current preview. It builds on WASI 0.2, replacing
the earlier explicit streams and polling interfaces with the component model's
native, composable async functionality via the future and stream types.
Find the APIs
Development of each API happens in its own repo, which you can access
from the proposals list.
This repo is for general discussion, as well as documenting how we work
and high-level goals.
Propose a new API
If you would like to create a new proposal, get started with our
Contributing guide.
All new API proposals should use the new format and the new repo structure that is shown in the proposal template.
See the Wit in WASI document for more information about using Wit for WASI proposals.
Read the full README on GitHubWhat Hacker News says
10 sources> "Component model interfaces always support link-time interposition."
>
> Like WTF does this mean? The repo tells me nothing
Directly above the sentence you quoted:
"Interposition in the context of WASI interfaces is the ability for a Webassembly instance to implement a given WASI interface, and for a consumer WebAssembly instance to be able to use this implementation transparently. This can be used to adapt or attenuate the functionality of a WASI API without changing the code using it."
> and I've still yet to see a clear write-up about what WASI is.
In the same document: [0]
> WTF is wit?
The first link in that document ("Starting in Preview2, WASI APIs are defined using the Wit IDL.") is [1].
> I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs.
The README for the legacy directory [2] cle
Read the rest
arly explains what they are.
> Where's a single well-written WASI spec?
"Development of each API happens in its own repo, which you can access from the proposals list." [3]
> Whatever WASI is doing, I don't like it.
Clearly not - you've gone out of your way to ignore all of the documentation that answer your questions.
> And neither does AssemblyScript team apparently
The AssemblyScript team have a bone to pick with WASI based on their misunderstanding of what WASI is for (it is not intended for use on the web) and WASI's disinterest in supporting UTF-16 strings. You can see for yourself in [4].
[0]: https://github.com/WebAssembly/WASI/tree/main#wasi-high-leve...
[1]: https://github.com/WebAssembly/component-model/blob/main/des...
[2]: https://github.com/WebAssembly/WASI/blob/main/legacy/README....
[3]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md
[4]: https://github.com/WebAssembly/WASI/issues/401
I've never seen a worse-described project than WASI.
"Component model interfaces always support link-time interposition."
Like WTF does this mean? The repo tells me nothing and I've still yet to see a clear write-up about what WASI is. I click on "docs" folder and there's one file. https://github.com/WebAssembly/WASI/blob/main/docs/WitInWasi.... WTF is wit? This should be in a CONTRIBUTORS.md not in the docs folder. I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs. Wikipedia tells me WASI is a POSIX-like interface but with POSIX I know exactly where to look up the functions. Where's a single well-written WASI spec?
I'll be honest - this whole project feels like candy for architecture astronauts and goes against the spirit of WebAssembly. Looks at how well-written WebAssembly's goals are: http
Read the rest
s://webassembly.org/docs/high-level-goals/. Their spec is easy to find and easy to read. This is what I want from WASM. Whatever WASI is doing, I don't like it. And neither does AssemblyScript team apparently: https://www.assemblyscript.org/standards-objections.html.
WASI: WebAssembly System Interface
123 points · Open discussionFor some reason, the act of choosing a plugin mechanism for our new project has been presented in my head a dilemma. Not a clear winner between the built-in stuff (plugin stdlib), the boring but battle tested option (Hashicorp go-plugin [1]) and the new exciting shiny ("future proof?") object web assembly plugins [2]
I ended up choosing the "traditional" Hashicorp library but any feedback, or comments on why you might think I am making a terrible mistake would be appreciated :)
[1] https://github.com/hashicorp/go-plugin
[2] https://github.com/WebAssembly/WASI/blob/snapshot-01/phases/...
In Choosing Hashicorp go-plugin in 2023?Not directly related to this thread, but I was recently unpleasantly surprised how under-defined and undocumented is WASI.
I was looking into some detail of a WASI call and there is… basically nothing.
Also the latest version of the docs is called something like “snapshot3” or whatever. I thought “wait this is it? that’s the whole definition”? apparently it is.
edit: here. The actual latest definition is in "legacy/preview1". Yes that is the latest WASI definition.
https://github.com/WebAssembly/WASI/blob/main/legacy/preview...
What do the inputs mean? How should it behave in some extreme conditions? Eh YOLO who knows. All implementation dependent.
This document is literally all there is. That's it, that's the WASI definition.
In WASIX, the Superset of WASI Supporting Threads, Processes and Sockets> homomorphic and secure way
A lot of the sandboxing and security focus in Wasm makes sense. But the "capability-based security" mentioned at WASI spec [0] confuses me. For instance, when looking to what Cosmonic (an early adopter in Wasm fields) documents as capabilities [1] (e.g. 'messaging', 'http client', 'key-value store') it seems wholly different to concepts from the E programming language [2] by Mark S. Miller, that are finding their way in Cap'n Proto [3] and early work on the OCapN [4] unification effort. Is there any relationship to these, or are we looking at totally different approaches? Or is Cosmonic overloading the terminology of "capability"?
[0] https://github.com/WebAssembly/WASI#capability-based-securit...
[1] https://cosmonic.com/docs/category/capabilities
[2] https://en.wikipedia.org/wiki/E_(programming_language)
[3]
Read the rest
I've been reading the following repositories.
https://github.com/WebAssembly/WASI/blob/main/Proposals.md
https://github.com/WebAssembly/wasi-threads
In The tug-of-war over server-side WebAssemblyFreeBSD does have Capsicum [0] though — with file descriptors as capabilities. FDs can be passed between programs over UNIX datagram sockets.
Processes can enter "capability mode" where only open (or rather: active) file descriptors can be used.
There used to be an alternative runtime for FreeBSD called CloudABI [1], with which native programs could be started in capability mode, but it was discontinued in favour of WASI [2] (server-side Webassembly) — which adopted CloudABI's libc API.
0: <https://www.cl.cam.ac.uk/research/security/capsicum/>
1: <https://github.com/NuxiNL/cloudabi>
2: <https://github.com/WebAssembly/WASI>
In HelloSystem – OS with original Mac philosophy with a modern architectureAnnoying to use acronym "WASI" and assume that everyone knows what it means. Apparently it’s Web Assembly System Interface. But what does that mean? To quote from https://github.com/WebAssembly/WASI:
> The WebAssembly System Interface is not a monolithic standard system interface, but is instead a modular collection of standardized APIs. None of the APIs are required to be implemented to have a compliant runtime. Instead, host environments can choose which APIs make sense for their use cases.
Uhh… OK, I guess. So it’s a collection of APIs to allow Web Assembly programs to make system calls? Why not just say that?
Edit: The official release notes do not make this mistake. https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-rele...
In Ruby 3.2.0 is from another dimension