diff --git a/wasi/2026/WASI-06-25.md b/wasi/2026/WASI-06-25.md index 38e73447..d6ca0799 100644 --- a/wasi/2026/WASI-06-25.md +++ b/wasi/2026/WASI-06-25.md @@ -28,3 +28,123 @@ The meeting will be on a zoom.us video conference. 1. Proposals and discussions 1. [Require OCI-published artifacts as a part of the phase 2 acceptance criteria](https://github.com/WebAssembly/WASI/issues/932) (yosh) 1. _Submit a PR to add your announcement here_ + +## Agenda items + +1. Opening, welcome and roll call + 1. Please help add your name to the meeting notes. + 1. Please help take notes. + 1. Thanks! +1. Announcements + 1. WASI 0.3 release recap (yosh) +1. Proposals and discussions + 1. [Require OCI-published artifacts as a part of the phase 2 acceptance criteria](https://github.com/WebAssembly/WASI/issues/932) (Yosh) + 2. Process for depending on Component Model Features in WASI 0.3.x (Bailey) + +## Attendees + +- Bailey Hayes +- Yosh Wuyts +- Luke Wagner +- Till Schneidereit +- Victor Adossi +- Nick Fitzgerald +- Kevin Moore +- Johnny Birch +- Steven Fontanella + +## Announcements + +### WASI 0.3 release recap + +**Yosh**: Hurray! We passed the vote for WASI 0.3.0 is out. Folks saw our announcements, release notes were posted on hackernews, so far all good. As far as the release goes, everything went well. We discovered a small bug in wasm-tools where the wasi:http docs, during encoding, the published OCI artifcat did not encode those notes. The checked in WIT includes the wit doc, but the published OCI artifact does not. This bug has already been fixed and will be in 0.3.1. + +**Yosh**: We are not going to move up 0.3.1 to mitigate this as this is a small issue. Now the long tail of work begins for implementers to ungate, implement in language SDK's, etc. + +**Yosh**: Alex put forward a PR to rust-lang to move the rust compiler toolchain for wasip3 to tier 2. That will take some more time, and the compiler team will decide on the rationale once LLVM has landed. + +**Yosh**: Everything went about as well as we could have hoped for. Looking forward to 0.3.1. + +## Proposals and discussions + +### [Require OCI-published artifacts as a part of the phase 2 acceptance criteria](https://github.com/WebAssembly/WASI/issues/932) + +**Yosh**: We have phase acceptance criteria. Today we require the WIT to be checked in. Since we've made this criteria, we have added and stabilized OCI image format for WebAssembly. You may take a .wit and turn that to .wasm, and then publish to an OCI registry. + +**Yosh**: I would like to propose we have a new acceptance criteria. As we make new proposals, we also require that the WIT is published to OCI so that folks may use tooling to fetch those and bring them into their projects. So we will require this as our registry format. + +**Yosh**: For all phase 3 proposals, we already publish to OCI. For phase 2, we have some but not all with automation to publish to OCI. Most notably, we wasi-otel has nice automation for this. By the time 0.3.2 rolls out, we will run a check, do all of these have it? By 0.3.2, ensure that all phase 2 proposals have OCI artifacts for their WIT definitions available. Not having OCI artifacts, will make them fall out of phase 2. + +**Luke**: Is there an easy instruction, automated way to do this? + +**Bailey**: follow what wasi-otel is doing. + +**Luke**: Before phase 3, proposals are external to the monorepo. But once voted to be at phase 3, they are moved into the monorepo? + +**Yosh**: Exactly right. Phase 2 exists so that folks can try things out and actually use it. Which means it is challenging if it isn't in OCI and their tools can't pull it down to use it. + +**Bailey**: I'm in favor. + +**Yosh**: See GH issue [Require OCI-published artifacts as a part of the phase 2 acceptance criteria](https://github.com/WebAssembly/WASI/issues/932). Leave thoughts or concerns in the issue. We will not merge this for a while yet. + +### Process for depending on Component Model Features in WASI 0.3.x + +**Bailey**: [slides](https://docs.google.com/presentation/d/1vGknzlIs4x1tTeID4AzkW2yROB_mJhAbOHWSt-7gKHY/edit?usp=sharing) + +**Bailey**: 0.3.0 has been released. want to discuss the process for adopting new upstream features in the component model and how to align that to the release schedule. The component model have emoji feature gates inside the spec. For the most part those changes don't land until we have toolchain feedback .But some features like cooperative threads have a longer tail of toolchain feedback and we want to see at least two languages implement this and have stackless and stackful languages work together. + +bailey: we want to be able to depend on this feature from wasi. that would need to go through a vote, and then in a future release we can then start depending on that feature in WASI versions. + +luke: make sense to me. means we can go back to the component model repo and group emoji-gate features by WASI release. + +bailey: **The component model features are not being developed as part of WASI. What we'd be voting on is the ability for WASI to depend on component-model features.** + +Bailey: tentative release schedule as we're looking at things now + +- **0.3.1** (august 4th): maps, implements, fixed length lists +- **0.3.2** (october 6th): error context, stream splice/forward +- **0.3.3** (december 1st): coop threads + +Bailey: thoughts? ideas on what to prioritize for 0.3.1? + +Luke: good list and makes sense how you've organized it. Implements has made a lot of progress and seems like a great candidate for 0.3.1. Also made progress on a feature called "external id" that gives a stable id if something doesn't fit in a kebab string. In the same vein of use cases. Useful in the short-term too: optional imports. Great for small components targeting exactly what they want to target. + +Bailey: would love optional imports + +Till: one thing that's interesting that you've listed cooperative threads - it doesn't fit the pattern you've described. We'd vote that proposals can make use for it. GC bindings for component model is internal to a component. I actually think it is still a good idea. + +Bailey: *pulls up slides* + +Till: Oh "if applicable" - that makes sense to vote on it. + +Bailey: would a better way of phrasing it be to make it "part of the p3 target"? + +**Till**: "Can be depended on by toolchains of this version of WASI". Doesn't make it that version of WASI, it makes it a dependency. + +**Yosh**: Co-operative threads, if you consider end to end, users of WASI will be writing in a programming language. + +What it will unlock for the wasip3 target, it will unlock the ability for programming languages to take advantage of that functionality. If you think of WASI as encompassing more than the WIT definition. + +**Till**: This group made the decision to be a collection of WIT definitions. + +**Yosh**: The characterization is right in that in order to implement WASI 0.3.2. There will be spectecs that say you must support this feature. + +**Till**: WASI can be implemented without WebAssembly. There is no such thing as a host API or a collection of standardized interfaces. Tying it to specific characteristics of the virtual machine would mean that we are giving up on that. + +**Luke**: The part of "if applicable", starting with wasi 0.3.2 you can now use `map` type. We're saying WASI is layered on the Component Model. You could say threads could have added a wit type but it didn't make sense. But it does expand the semantic universe that WASI lives in. We are moving forward what we make available to our base universe. On a pragmatic level, it is nice that we have this one version to communicate this one version. + +**Till**: I still think expressing as a layering, or maybe as a strong recommendation, I do want to support wasip3 API's but in my environment GC support just doesn't make sense, + +**Luke**: Well for GC we want to use this optional import feature for. By the way that I was specially wording this, the async emoji is included in the 0.3.0 release. + +**Victor**: NIT: there's still a command/reactor difference right? the `_start` export is still the differentiator right? + +**Luke**: What that has morphed into is a toolchain convention. When we zoom out, all components are reactors. `wasi/cli.run` and conventionally it says run once, but technically you can call it multiple times, but will likely break. + +**Till**: I think we should not re-introduce any new framing for WASI. We are using the guidance of the WASI subgroup of wasi runtime implementers as part of implementing wasi should also support this set of Component Model features. + +**Yosh**: I think we might all be on the same page here. It is very much the layering approach. WASI is built on the component model. We do not define component model things, but this is the part of the component model we expect to be there. + +**Yosh**: OK great sounds like we have a good understanding. I'm excited for the new features to land in 0.3.x. + +**Bailey**: that's it for the agenda items. Any more items people want to bring up? No? Thanks everyone!