WebAssembly
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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 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
57 sourcesOk, I've swapped that link in at the top and put the submitted URL (https://github.com/WebAssembly/WASI/releases/tag/v0.3.0) in the toptext.
In WASI 0.3If you don't want to download the .tar.gz I think you can browse the content for this release (.wit interface files) here on GitHub: https://github.com/WebAssembly/WASI/tree/v0.3.0/proposals
In WASI 0.3It's possible to run WebAssembly programs from the command line (without any GUI) using WASI (see e.g. https://github.com/WebAssembly/WASI). Thus if the user downloads pdfconverter.wasi , and the user already has e.g. wasmtime installed, they can run `wasmtime pdfconverter.wasi input.pdf output.pdf` from the command line (see https://github.com/bytecodealliance/wasmtime/blob/main/docs/... for details).
In addition to the web site, the Electron app and the Chrome extension, you may want to distribute a command-line version of your tools as WASI-style .wasm program files. If you do so, I would exclusively use the them this way, from the command line.
In Show HN: Pdfwithlove – PDF tools that run 100% locally (no uploads, no back end)The WASI systems libraries that define the standard platform for WebAssembly/wasm are Capability-based.
From their first high level goal:
> Define a set of portable, modular, runtime-independent, and WebAssembly-native APIs which can be used by WebAssembly code to interact with the outside world. These APIs preserve the essential sandboxed nature of WebAssembly through a Capability-based API design.
https://github.com/WebAssembly/WASI/blob/main/README.md#wasi...
In Why not object capability languages?> Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation?
The big change going from WASI 0.1 to WASI 0.2 is that we decoupled the calling convention (Wasm Components) from the actual syscall APIs (WASI). That enabled us to make the various syscall APIs modular and composable.
Because CDN functions probably shouldn't know about TCP; and CLI applications probably don't care about blob storage. And now they don't need to. Take a look at the WASI Proposals page [1] for an overview of all WASI APIs.
[1]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md
In Hyperlight WASM: Fast, secure, and OS-freeWasm is getting merged in and designed in a way that it is "drop in". As in, the standard libs are written to do WASI calls instead of libc (or whatever else) for standard I/O concerns.
This is represented in some languages better than others -- for many languages you just switch the "target" -- from x86_64-unknown-linux-gnu to wasm32-wasip2 (ex. Rust). Some things won't work, but most/many will (simple file access, etc), as they are covered under WASI[0]
That's not to say that nothing will change, because there are some technologies that cannot be simply ported, but the explicit goal is to not require porting.
[0]: https://github.com/WebAssembly/WASI/tree/main/wasip2
In WASM will replace containersTrue
WASI Design Principles
Capability-based security
WASI is designed with capability-based security principles, using the facilities provided by the Wasm component model. All access to external resources is provided by capabilities.
There are two kinds of capabilities:
Handles, defined in the component-model type system, dynamically identify and provide access to resources. They are unforgeable, meaning there's no way for an instance to acquire access to a handle other than to have another instance explicitly pass one to it.
Link-time capabilities, which are functions which require no handle arguments, are used sparingly, in situations where it's not necessary to identify more than one instance of a resource at runtime. Link-time capabilities are interposable, so they are still refusable in a capability-based security se
Read the rest
nse.
WASI has no ambient authorities, meaning that there are no global namespaces at runtime, and no global functions at link time.
Source: https://github.com/WebAssembly/WASI/blob/main/README.md
Yes and No.
Check out the WASI repository. For people not understanding what WASI is, I always tell them it's something like a reference/specification of cross platform syscalls that have to be implemented in WASM VMs.
Of course, access to such things always come with assumptions of control and policies that rely on behavioral analysis. So I hope that something similar to host and web application firewall rules will come out of this, similar to how deno does it.
[1] https://github.com/WebAssembly/WASI
In WASM will replace containersGood point! This is the hard work that people are undertaking right now.
Things are going to change a little bit with the introduction of Preview3 (the flagship feature there is async without function coloring), but you can look at the core interfaces:
https://github.com/WebAssembly/WASI/tree/main/wasip2
This is what people are building on, in the upstream, and in the bytecode alliance
You're absolutely right about embeddings being varied, but the standard existing enforces the expectations around a core set of these, and then the carving out of embeddings to support different use cases is a welcome and intended consequence.
WASI started as closer to POSIX now, but there is a spectacular opportunity to not repeat some mistakes of the past, so some of those opportunities are taken where they make sense/won't cause too much disruption to pe
Read the rest
ople building in support.
WASI Preview 2:
https://github.com/WebAssembly/WASI/blob/main/wasip2/README.... :
> wasi-io,
wasi-clocks,
wasi-random,
wasi-filesystem,
wasi-sockets,
wasi-cli,
wasi-http
In I Wrote a WebAssembly VM in C"WASI 0.2 Launched" (2024-01)
https://news.ycombinator.com/item?id=39289533 :
> At the same time, work towards WASI 0.3, also known as WASI Preview 3, will be getting underway. The major banner of WASI 0.3 is async, and adding the future and stream types to Wit. And here again, the theme is composability. It’s one thing to do async, it’s another to do composable async, where two components that are async can be composed together without either event loop having to be nested inside the other. Designing an async system flexible enough for Rust, C#, JavaScript, Go, and many others, which all have their own perspectives on async, will take some time, so while the design work is starting now, WASI 0.3 is expected to be at least a year away.
WebAssembly/WASI > WASI Preview 2:
https://github.com/WebAssembly/WASI/tree/main/wasip2
In WasmCloud makes strides with WASM component modelEventually by using the component model which will expose the DOM API. It will get to direct wasm to WebIDL calls one day:
https://github.com/WebAssembly/component-model
The component model is being used for the WebAssembly System Interface (WASI). WASI provides operating system integration for wasm applications outside the browser:
https://github.com/WebAssembly/WASI/tree/main
In the meantime you can use JavaScript glue code auto-generated by your toolchain to access the DOM. This will be made better with builtins like the js-string-builtins proposal:
https://github.com/WebAssembly/js-string-builtins/blob/main/...
You can call JavaScript functions and DOM methods from wasm like this example from Hoot, which is a Scheme to wasm compiler:
https://spritely.institute/news/building-interactive-web-pag...
In Ask HN: What are some unpopular opinions you got?Very cool! I've been watching the "toolchains in Wasm" landscape for a while, and seeing a Clang/LLVM toolchain running in Wasm is awesome!
YoWASP has also had an LLVM toolchain working in Wasm for a while too[1], although it seems like this version solves the subprocess problem by providing an implementation of `posix_spawn` whereas the YoWASP one uses some patches to avoid subprocesses altogether
My biggest question marks around this version are about runtime/platform support. As I understand it, this toolchain uses WASIX, which (AFAICT) works with Wasmer's own runtime and with a browser shim, but with none of the other runtimes. Are there plans to get WASIX more widely adopted across more runtimes, or to get WASIX caught up to the latest WASI standard (preview2)? Or maybe even better, bring the missing features from WASIX to mainline W
Read the rest
ASI like `posix_spawn`[2]? I'd love to be able to adopt this toolchain, but it doesn't seem like WASIX support has really caught on across the other runtimes
[1]: https://discourse.llvm.org/t/rfc-building-llvm-for-webassemb...
[2]: https://github.com/WebAssembly/WASI/issues/414
Showing the 15 most recent of 57 sources. Enable JavaScript to search and browse every indexed mention.