# January 7th

| | |
| -------- | -------- |
| Attending | Calvin Prewitt, Joel Dice, Bailey Hayes
| Note Taker | Guy Bedford

## Subgroup Updates

Include general updates, upcoming plans, and anything you want to raise to the rest of the group.

* C#/.net
- TLS progress; SSLStream implemented in terms of Dave Bakker's `wasi-tls` draft. Joel will present `wasi-tls` proposal at WASI meeting on Thursday.
- WASI support in Dot NET moving to Runtime Labs repo since Microsoft not ready to support it in the upstream repo.
* Go
- Randy still working on upstreaming. Big Go port is still main priority. TinyGo support continues to progress, Randy is just tweaking the wit-bindgen-go code.
* JavaScript
- Many contributors to componentize-js and starlingmonkey
- Need to focus on features, usability in componentize-js. Example: unicode regexes not supported. Fastly does string replacement at build time. Otherwise resolving and releasing bug fixes, but no time for big features yet. Error messages have improved for user errors.
- StarlingMonkey: MS has been contributing a lot, e.g. Blob interfaces, form data, URL APIs, etc. Has ramped up on codebase; looking to add GC tests.
- Reviews slow during holidays; reviews have been bottleneck lately rather than implementation
- Jco: Victor doing great work. Added examples to help with onboarding.
* Python
- Working on improved support for native extensions. Currently have WASI-Wheels to cross-compile .so files with build scripts to WASI. Want PIP-like native experience, Ben is working on WASI-specific python package index for app to use for better dependency management ergonomics.
* Rust
- Cargo component release.
* WASI-Virt
- Added support for `wasi-config-store` in November
- Need to update to WASI 0.2.3
- Hoping for more contributions; 0.2.3 upgrade should make for friendlier messages

## General Updates

# August 6th

| | |
| -------- | -------- |
| Attending | Calvin Prewitt, Linwei Shang, Guy Bedford
| Note Taker | Guy Bedford

## Subgroup Updates

Include general updates, upcoming plans, and anything you want to raise to the rest of the group.

* C#/.net
* Go
* JavaScript
- Guy
- IDL bindings, working towards inlining ComponentizeJS into monorepo
- Combined JS guest meeting now covers Jco, StarlingMonkey & ComponentizeJS
- Calvin
- also investigating IDL bindings, and considering async support
* Python
* Rust
- Low attendance recently, may need restarting. Cargo component development is happening, with wasm-pkg-tools refactoring work.
- Feature gates and WIT changes.
* WASI-Virt

## General Updates

# July 16nd

| | |
| -------- | -------- |
| Attending | Scott Waye, James Sturtevant
| Note Taker | Scott Waye

## Subgroup Updates

Include general updates, upcoming plans, and anything you want to raise to the rest of the group.

* C#/.net
* Go
* JavaScript
* Python
* Rust
* WASI-Virt

## General Updates

* [Joel] -
* Joel: The big thing is "threading". Multi-threading is pervasive in C# and Python in ways that depend on multi-threading in unexpected ways that require ugly patches to get around. I wonder if one of our next initiatives needs to be "how do we get threading into wasi?". I worry that we'll spend more time working around threading to make important ecosystems work than it would take to implement threading.
* Bailey: We've decided to pursue this at the core Wasm level instead of the WASI level. Though we will need to do component model work to enable this. This has been unblocked with some key design decisions being decided on upstream.
* Joel: What I've heard from Alex is that it's not going to be a trivial exercise to go from core module to component model + WASI support for threads. Similarly to wasm-gc integrating it into the ABI and define what it means to have shared in components will be challenging. I think it might not be getting the attention it needs.
* Bailey: Unlike wasm-gc where we need to have canon builtins that are annotated "shared" (may have meant gc), it should be completely encapsulated within the component.
* Joel: Does that mean that only one thread of all the threads running in a component can make calls to the host or other components? If I can't access the filesystem from any thread except the main thread that's going to make it hard to get libraries to play ball with it. I think these are exactly the things we need to be thinking/talking about.
* Robin: We're still expecting to need to make a canon builtin for creating threads because the browser folks don't want one in core wasm right?
* Bailey: yep
* Brett: Python was created with a singular interpreter lock that protects all of the internals. The interpreter effectively runs in a single-threaded way. When you call out to the system you let go of the GIL so I/O can be multithreaded. There will soon also be a build of Python without the GIL and there's a lot of money behind getting this to work. So there's going to be a lot of threaded code in Python. The AI people are going to need it even more.
* Robin: I think the first part for the IO is going to be the harder one.
* Bailey: I think the only spec work we need from the browsers is almost done. Accessing file-system and other wasi stuff... (I missed some of this)
* Joel: ...
* Robin: ...
* Joel: Some mix of design and tooling and host/guest support will be needed to solve these problems.
* Bailey: I want to get Alex Crichton, Nick Fitzgerald, Chris Fallin, and Joel Dice to talk about the threading problems and the layers we need to start solving it in especially now that we know what the shared-everything threads standard looks like. It'd be nice if this was more project managed instead of ad-hoc. Let's write down the real world problems we're solving and start from there.
* Brett: Has there been any discussion about dynamic loading and the cloudflare decision?
* Joel: ...
* Brett: It looks like they launched their Python wasm support without wasi because they don't have dynamic loading. They said what Jamey and Joel did wasn't dynamic enough.
* Bailey: I'll give a bit more on the situation. They didn't actually bring up dynamic loading in the conversation I had. They made a big investment in their V8 engine. We're planning to make a bridge using the shims for nodejs so that the emscripten library can use those shims and bring the ecosystem forward. They weren't upfront about considering wasi/not-wasi. The main emscripten maintainer is planning to add wasi support.
* Brett: I would have assumed that it was about V8 except that they linked to Joel and Jamey's doc. The person who's leading the python stuff at cloudflare is also someone we know. It's great that emscripten is looking at getting closer to WASI I just don't hear about how that relates to python.
* Bailey: I heard Luke talking about this with some folks but didn't here much about it. Maybe it would be good to have Luke talk about this in a WASI meeting. It's also very likely I was talking to different Cloudflare folks and one of the ones I talked to spent half a week trying out wasi and there is interest in component-model stuff it just needs to be more mature.

## Action Item

- [Bailey] - Create a follow up meeting about threading
- [Bailey] - Check in with Luke on dynamic loading
- [Robin] - Announce switch to asynchronous subgroup updates in Zulip

# July 2nd

| | |
| -------- | -------- |
| Attending | Robin Brown, Bailey Hayes, David Bryant, Joel Dice, Mossaka
| Note Taker | Robin Brown

## Subgroup Updates

Include general updates, upcoming plans, and anything you want to raise to the rest of the group.

* C#/.net
* Joel: I've got a PR this week that ports the .NET `system.net.http` to wasi:http
* Go
* Mossaka: My co-organizer for the go subgroup is stepping down. Damian Gryski is stepping up to fill that role. WASI preview 2 is officially merged into tinygo. Unlike wasi p1 implementation, this depends on the wit-bindgen-go implementation Randy has been working on.
* Bailey: When talking about this, make sure to talk about it as wasi-cli support. the http support is possible with bindings but we're planning on adding support similarly to how Joel did for .NET runtime `system.net.http`. We're going to make something that acts like net http in go but is built on top of the bindings.
* JavaScript
* Python
* Rust
* WASI-Virt

## General Updates

* [Robin] - Stepping down as co-chair
* [Robin] - Moving to async updates
* [Joel] -
* Joel: The big thing is "threading". Multi-threading is pervasive in C# and Python in ways that depend on multi-threading in unexpected ways that require ugly patches to get around. I wonder if one of our next initiatives needs to be "how do we get threading into wasi?". I worry that we'll spend more time working around threading to make important ecosystems work than it would take to implement threading.
* Bailey: We've decided to pursue this at the core Wasm level instead of the WASI level. Though we will need to do component model work to enable this. This has been unblocked with some key design decisions being decided on upstream.
* Joel: What I've heard from Alex is that it's not going to be a trivial exercise to go from core module to component model + WASI support for threads. Similarly to wasm-gc integrating it into the ABI and define what it means to have shared in components will be challenging. I think it might not be getting the attention it needs.
* Bailey: Unlike wasm-gc where we need to have canon builtins that are annotated "shared" (may have meant gc), it should be completely encapsulated within the component.
* Joel: Does that mean that only one thread of all the threads running in a component can make calls to the host or other components? If I can't access the filesystem from any thread except the main thread that's going to make it hard to get libraries to play ball with it. I think these are exactly the things we need to be thinking/talking about.
* Robin: We're still expecting to need to make a canon builtin for creating threads because the browser folks don't want one in core wasm right?
* Bailey: yep
* Brett: Python was created with a singular interpreter lock that protects all of the internals. The interpreter effectively runs in a single-threaded way. When you call out to the system you let go of the GIL so I/O can be multithreaded. There will soon also be a build of Python without the GIL and there's a lot of money behind getting this to work. So there's going to be a lot of threaded code in Python. The AI people are going to need it even more.
* Robin: I think the first part for the IO is going to be the harder one.
* Bailey: I think the only spec work we need from the browsers is almost done. Accessing file-system and other wasi stuff... (I missed some of this)
* Joel: ...
* Robin: ...
* Joel: Some mix of design and tooling and host/guest support will be needed to solve these problems.
* Bailey: I want to get Alex Crichton, Nick Fitzgerald, Chris Fallin, and Joel Dice to talk about the threading problems and the layers we need to start solving it in especially now that we know what the shared-everything threads standard looks like. It'd be nice if this was more project managed instead of ad-hoc. Let's write down the real world problems we're solving and start from there.
* Brett: Has there been any discussion about dynamic loading and the cloudflare decision?
* Joel: ...
* Brett: It looks like they launched their Python wasm support without wasi because they don't have dynamic loading. They said what Jamey and Joel did wasn't dynamic enough.
* Bailey: I'll give a bit more on the situation. They didn't actually bring up dynamic loading in the conversation I had. They made a big investment in their V8 engine. We're planning to make a bridge using the shims for nodejs so that the emscripten library can use those shims and bring the ecosystem forward. They weren't upfront about considering wasi/not-wasi. The main emscripten maintainer is planning to add wasi support.
* Brett: I would have assumed that it was about V8 except that they linked to Joel and Jamey's doc. The person who's leading the python stuff at cloudflare is also someone we know. It's great that emscripten is looking at getting closer to WASI I just don't hear about how that relates to python.
* Bailey: I heard Luke talking about this with some folks but didn't here much about it. Maybe it would be good to have Luke talk about this in a WASI meeting. It's also very likely I was talking to different Cloudflare folks and one of the ones I talked to spent half a week trying out wasi and there is interest in component-model stuff it just needs to be more mature.

## Action Item

- [Bailey] - Create a follow up meeting about threading
- [Bailey] - Check in with Luke on dynamic loading
- [Robin] - Announce switch to asynchronous subgroup updates in Zulip

# April 2nd

| | |
| -------- | -------- |
| Attending | Robin Brown, Joel Dice, Kevin Moore
| Note Taker | Robin Brown

## Subgroup Updates

Include general updates, upcoming plans, and anything you want to raise to the rest of the group.

* C#/.net
* Joel: Working on resources in wit-bindgen
* Go
* JavaScript
* Python
* Rust
* WASI-Virt

## General Updates

* [Robin] -
*

## Agenda

* [Robin] - Recruiting
* [Calvin] - Registry Support for JCO and other tools
* Guy: I think it's more of a componentization than JCO.
* Robin: ya, like using it to import a component or target a world in a registry
* Calvin: You'd reference something like `fermyon:spin` and it could pull it.
* Guy: Or you could point at a WIT file that itself uses an id like that.
* Joel: I want to be able to generate lightweight Python components that import cpython module.
* Robin: that should be possible using existing tooling.
* Guy: componentizing tooling should do this by default.
* Robin: there's some work that will need to be done to support unlocked-deps

## Action Items

# April 2nd

| | |
| -------- | -------- |
| Attending | Robin Brown, Calvin Prewitt, Joel Dice, Guy Bedford
| Note Taker | Robin Brown

## Subgroup Updates

Include general updates, upcoming plans, and anything you want to raise to the rest of the group.

* C#/.net
* Go
* JavaScript
* Guy: Componentize-JS latest release is running on StarlingMonkey. There's still some work to figure out incoming handlers and fetch, but everything is based on StarlingMonkey.
* Guy: StarlingMonkey is a runtime for doing guest Wasm. Componentize-JS supporting it gets us access to WinterCG support. You can use preview2 in JavaScript and use them alongside builtins in the JavaScript environment. You can disable features like clocks and random individually and it will stub them out so you can create a pure component.
* Guy: Working on some edge cases in resource implementation.
* Python
* Joel: I added a feature to stub out WASI imports. This lets you target a specific world and say I don't want any WASI imports. When we added the ability to do native extensions we lost that capability, and it's being added back.
* Joel: I haven't had the chance to dig into Pandas but I have an unofficial WASI wheels repository. Chris Dickinson from Dylibso has contributed a bunch to that repo but hasn't had time to test much of it. Since Pandas relies on Cython and the C++ generation step runs into issues with exceptions that we didn't get passed, it doesn't fully work.
* Joel: Don't start using isyswasfa. We want to make that obsolete as quickly as possible. I'm working with Luke on prototyping 0.3 async. I'm hoping to have a working prototype soon.
* Rust
*
* WASI-Virt
* Guy: In talking with Cosmonic and WasmCloud folks, they are looking into taking over maintenance of WASI-Virt to move it in the direction of extending the permissions/adapting model of Virt to make the deny functionality more flexible and be a full security model. They also want to support running components that are targetting the CLI world and retarget it onto the runtime environment world, supporting that in WASI-Virt. Since Virt does dead code elimination, we can add more stuff. Ideally we'll move towards isyswsfa and do more with linking.
* Robin: If they take on maintenance will it stay a BA project?
* Guy: Yes and it will stay focused on WASI interfaces.

## General Updates

* [Robin] - Claw
* Robin: Announced at Wasmio. It's
*

## Agenda

* [Robin] - Recruiting
* [Calvin] - Registry Support for JCO and other tools
* Guy: I think it's more of a componentization than JCO.
* Robin: ya, like using it to import a component or target a world in a registry
* Calvin: You'd reference something like `fermyon:spin` and it could pull it.
* Guy: Or you could point at a WIT file that itself uses an id like that.
* Joel: I want to be able to generate lightweight Python components that import cpython module.
* Robin: that should be possible using existing tooling.
* Guy: componentizing tooling should do this by default.
* Robin: there's some work that will need to be done to support unlocked-deps

## Action Items

# March 5th

| | |
| -------- | -------- |
| Attending | Robin Brown, Calvin Prewitt, Joel Dice, Guy Bedford, Jiaxiao Zhou (mossaka), Brett Canon, Timmy Silesmo
| Note Taker | Robin Brown

## Subgroup Updates

Include general updates, upcoming plans, and anything you want to raise to the rest of the group.

* C#/.net
* Timmy: We have been working on adding the basic component types lists, options, results, varients, etc. Resources and streams are still being worked on. After that, we'll start implementing wasi:http for the http client in .net and I've spoken with the .net team quite a bit and it looks likely that we'll be able to get that into the official client. We're bringing some of the generic primitives into their own library with their own tests. When things become more stable, we'll look into upstreaming that in .net. We've been getting lots of support
* Go
* Zhou: Work on wit-bindgen go
* Zhou: Work on tinygo wasi p2 bindings. Syscalls are almost all implemented.
* Zhou: Export work in "big" go is still in proposal stage. It's also just targeting p1 at the moment.
* Calvin: Is there any news on 64-bit data structures in wasm32?
* Zhou: I know there is a wasm32 proposal, but I'm not sure.
* Zhou: Here's a link https://github.com/golang/go/issues/63131
* JavaScript
* Guy: We're discussing expanding the scope and unifying wider JavaScript work. We've pulled in Fastly folks and are working on pulling in Fermyon people. We're having ongoing discussions about what it would mean to share JS guest runtime work, though it is still in the early stages. There's room for more people to get involved.
* Guy: We're hoping to work towards some announcements soon.
* Calvin: Do you think we should have some meeting/structure for WASI-Virt?
* Guy: We do need some stewardship
* Python
* Brett: Python is now officially a Tier 2 language!
* Brett: Python should not be broken for wasi on main for more than 24 hours and there should never be a release where it's broken.
* Brett: I'm working on a PR to use p2 primitives.
* Brett: I'm going to work on getting wasi-sdk 21 working. Work around DLL Open.
* Brett: This will be my last meeting till June. I'm taking leave till June 9th.
* Brett: I'm working on getting wasmtime 18 stuff working and have backup on the Tier 2 stuff. Though the wasi-sdk 21 work may get punted.
* Joel: I'm working on wasi-sdk 22 and 0.2 support for sockets. By the time you get back, I hope we'll have wasi-sdk 22 released or ready to release.
* Rust
* N/A

## General Updates

*

## Agenda

* [Robin] - Component-Opt
* Robin: ...
* Calvin: How does this relate to Joel's component init?
* Joel: Is a goal of component-opt to be run an on arbitrary component runtime?
* Robin: By configuring which passes and the paramters for those passes are run, it should be possible to avoid introducing any features/proposals that aren't supported by a given runtime.
* Joel: Will component-opt compile to components?
* Robin: That's definitely a goal
* Calvin: There's not a lot of docs for component init and people are interested in how it works?
* Joel: Jamey Sharp is working on a README as an initial step towards improving this and there are also some comments in the code.
* Robin: Are there any other questions/comments on component o pt?
* Guy: You should check out the `wasmtime-environ` crate which has some useful representations for component data and an implementation of dead code elimination.
* https://github.com/bytecodealliance/wasmtime/blob/main/crates/environ/src/component/dfg.rs
* https://github.com/bytecodealliance/ComponentizeJS/blob/main/crates/spidermonkey-embedding-splicer/src/stub_wasi.rs
* Joel: wit-component does dead code elimination.
* Jeol: Another thing that may or may not be in scope for a tool like this is a lightweight version of wasi-virt that doesn't involve any component composition by stubbing out common imports and doing things like telling guests that there are no environment variables.
* [Shared] - Where do common tools live?
* Guy/Robin: *talked about how to communicate the status of projects like walrus, wasi-virt etc.*
* Joel: As a new user, the priority is probably good documentation. The component model docs have tracks for each language and things like optimization, virtualization, and composition fit into those docs. So you wouldn't have to know about these tools before using them.
* Guy: Writing docs is a
* [Shared] - Recruiting contributors
* Punted for future discussion

## Action Items

* [Robin] - Talk to the docs sig chairs

# February 6th

| | |
| -------- | -------- |
| Attending | Robin Brown, Calvin Prewitt, Danny Macovei, Jason Smith
| Note Taker | Robin Brown

## Subgroup Updates

Include general updates, upcoming plans, and anything you want to raise to the rest of the group.

* C#/.net
* Go
* JavaScript
* Calvin: Working on rescheduling meeting to bring more people in.
* Calvin: A new project being planned/discussed that we may talk about soon.
* Python
* Rust
* Danny: Thinking about how to make cargo-component take advantage of registry and embed dependencies.
* Calvin:

## General Updates

* None

## Agenda

* [Danny] - Zig interest
*

## Action Items

*

# January 2nd

| | |
| -------- | -------- |
| Attending | Robin Brown, James Sturtevant, Guy Bedford, Peter Huene, Calvin Prewitt
| Note Taker | Robin Brown

## Subgroup Updates

Include general updates, upcoming plans, and anything you want to raise to the rest of the group.

* C#/.net
* James: Merged the wasm import linkage in the aot project
* James: We started adding tuple and multiple return value support. Someone has started on resources.
* James: Timmy Silesmo presented at the [December Community Meeting livestream](https://www.youtube.com/watch?v=fnAjxzMPPqk) and summarized some of our work.
* Go
*
* JavaScript
* Guy: JCO + Node.js now passes the Wasmtime conformance tests for WASI random, io, clocks, cli, and http. It does not yet pass two of the fs test cases yet, which appear to be caused by a Node.js bug which I'm working to upstream.
* Python
*
* Rust
* Peter: We added new subcommands to cargo component for making and running commands using new and run.
* Peter: updated to Wasmtime 16

## General Updates

* None

## Agenda

* [Guy] - Other Language Support
* Guy: looking at the stakeholders we have in language ecosystems it'd be interesting to see wher our gaps are and how we could improve other lnaguage representation.
* Guy: I know Danny was working on Zig and there's Ruby and Dart work.
* [Robin]

## Action Items

*