Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
97 changes: 97 additions & 0 deletions wasi/2026/WASI-07-09.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
# 2026-07-09 WASI SG meeting

![WASI logo](https://raw.githubusercontent.com/WebAssembly/WASI/main/assets/WASI.png)

## Agenda: July 09 WASI video call
Expand Down Expand Up @@ -28,3 +30,98 @@ The meeting will be on a zoom.us video conference.
1. Update on wasi:webgpu (Mendy Berger)
1. Experimental support for [`implements`](https://github.com/WebAssembly/component-model/pull/613) and [`external-id`](https://github.com/WebAssembly/component-model/pull/672) in Component Model spec and Wasmtime (Luke Wagner, 15min) ([slides](https://docs.google.com/presentation/d/1WOo9Ukf3cmmJUTcr9yV3fZg8Suy-kECh6adRx9FTECk))
1. _Submit a PR to add your announcement here_

## Attendees

- Bailey Hayes
- Mendy Berger
- Erik Rose
- Joel Dice
- Alex Crichton
- Till Schneidereit
- Yosh Wuyts
- Luke Wagner
- Johnny Birch
- Victor Adossi
- Joel Dice
- Chris Woods


## Notes

### Update on `wasi:webgpu` (Mendy Berger)

Mendy: Last update was exactly 1 year ago, short update on `wasi:webgpu`. Narrowing scope to `wasi:webgpu` and moving it to p3

Mendy: going forward we're only going to have `webgpu` in the `wasi` namespace. `wasi:surface` is simply not stable enough, so it's better to split it out into its own namespace.

Mendy: moving `wasi:webgpu` to p3 - we need that because on the web the WebGPU APIs are async. We have updated the spec to p3, updated the Wasmtime bindings. Browser shim is missing, C and Rust bindings missing.

Mendy: we've moved to using OCI and `wkg`. WebGPU spec tests now run on `wasi:webgpu`, failures are mostly because of missing p3 async support. We're adding `wasi` and `wasi:webgpu` support to llama.cpp.

Mendy: please look at our things and tell us what we're doing wrong. A lot of changes are from people giving us feedback, also Luke (Wagner) giving us feedback. We would like to get more engagement from

Yosh: I am very excited for this. I work at Microsoft. How far out LLama.cpp demo?

Mendy: Two steps. The work to compile to wasm is one step which works with CPU. There is a separate step for adding a WebGPU backend. That is in process.

Colin: I have a demo that I gave in kubecon Atlanta with ONNX Runtime. We want this fork to be merged upstream in ONNX Runtime. If you work at a place that does some kind of edge compute, I would like to go through it with you.

Bailey: we've seen this with ONNX runtime already. Super excited about it. One thing I wanted to highlight is that Mendy has published a release client, aiming for stability there.

Bailey: thank you for the update Mendy!

### Experimental support for `implements` and `external-id` in the C-M spec and Wasmtime

Luke: should be a short update. First motivation + summary for `implements` and `external-id`. These are candidates for inclusion in the next WASI release and going through the vote process. Would be good for people to see and give feedback.

Luke: in 0.3.0 I can import a key-value interface. When I compile it, the key-value store is the name of the import. The interface name _is the name_. You can only have one import of a given interface, and in a lot of cases this is what you want. But what if I have two key-value stores, or two config stores? That can be reasonable to do! What do I do?

Luke: today you might add string prefixes. You could add indirection and resourcify them. But those are extra hops of interactions. Chang the interfaces. Or we could change the import names.

Luke: with experimental implements support we can write `import redis: wasi:keyvalue/store` and `import memcached: wasi:keyvalue/store`. The types are the same in the desugaring, but it has an `implements` _attribute_. This is new: not a part of the name, not a part of the type, but a new third thing.

Luke: The advantages of this is that we can get earlier errs, less runtime name lookup (perf), link-time capability routing (security) using WAC. We can statically link which components have access to which stores. You can link things more aggresively / eagerly.

Yosh: So, secrets. Does this help with the use-case where you have a secret store. Hey here's a key you might care about. I'm trying to figure out if this is the same thing.

Luke: You could have a singular wasi secret, so every import you could name the secret I want. You could have one import per secret, and declaratively say which secret is needed.

Bailey: say you have secrets in Vault and in AWS secret manager, and import both. Downside: wouldn't be declarative unless (next slide). Are both emoji gated under the same emoji?

Luke: that's right.

Luke: what if the runtime has its own naming scheme that isn't kebab-cased for everything. How do we map the names from inside the component to different names in the host? `import redis: wasi:keyvalue/store` -> `"redis": "redis://crstcrstcrstcrst8042304@123.456.789"`

Luke: instead of mangling, what if we added external ID support?

```wit
@external-id("redis://crstcrstcrstcrst8042304@123.456.789")
import redis: wasi:keyvalue/store;
```

Luke: these are attributes. They are not arbitrary, they are pre-defined. In the browser this will be great for ESM integration. Modules in the browser can load other modules, and those carry a module specifier. We could use external IDs for that instead.

Bailey: based on how this is done, each implements is unique right?

Luke: each name has to be unique. Attributes are metadata.

Yosh: We only have two attributes. We also have @since and @unstable. Are we saying these are all part of the same system?

Luke: At the moment, @since and @unstable do not go into the component binary. They are meant to be strippable and are more documentable. At the WIT level they are all attributes but at the component level they are different.

Yosh: We've also discussed adding documentation into the component.

Luke: There is already a documentation custom section, that is how the round-trip works in the custom section. At the moment, that is where I think since and deprecated would go too. Documentation is strippable by nature, and that is how putting it in a custom section it is more semantic. Open for discussion on bringing them closer if we find a use-case.

Colin: This is a little tangential, I am having a hard time visualizing what we would put in external-id.

Luke: This might be the world of a componen that is generated by a component. There are pipelines of these things with the last stage being a deploy of these.

Colin: Ah so this is like emitted by an orchestrator, at some orchestration step.

Luke: Yes. If doing something like lodash in the browser, this is the string that fetches something.

Luke: This emoji-tag it's the :label: tag. In wasmtime it's behind component-model-implements feature.

Bailey: any questions for Luke? No? - You did a great job explaining. Any more items before we adjourn? No - see you in two weeks!