Alex Crichton (Jun 23 2025 at 17:59): Alex Crichton (Jun 23 2025 at 17:59):Hey all I meant to give a heads up about this at the last Wasmtime meeting but I failed to account for the holiday on that day and so I didn't attend the meeting and broadcast this out. In lieu of that here I am! I'd like to share a "declaration of intent" of sorts of the beginning of the process of merging the wasip3-prototyping fork upstream into Wasmtime itself.
As background for those that aren't familiar the wasip3-prototyping repository has been a staging ground for the implementation of component model async and WASIp3 primarily authored by @Joel Dice within Wasmtime and @Roman Volosatovs for WASIp3 bits. This is a major feature being added to our component runtime and was developed out-of-tree to make development easier and avoid unnecessary churn in the main repo. The intention was to always merge upstream eventually and the time has now come for that.
The current thinking is to split the wasip3-prototyping into two major initiatives:
The initial pieces landing will exclusively be (1) meaning that wasmtime-wasi and wasmtime-wasi-http will have few, if any, changes made to them. The WASI bits are expected to come later once we're happy with the Wasmtime bits in-tree.
For the Wasmtime bits I've just talked with @Joel Dice and our thinking is that this is going to be split across four different PRs:
todo!() but all other APIs in the wasmtime crate are updated to account for async (e.g. Func::call_concurrent will be added). This PR will showcase how the rest of wasmtime is affected with respect to concurrent/async APIs, but without actually introducing concurrency/async yet.concurrent.rs and futures_and_streams.rs. This will be filling out todo!() blocks added in PR (2) above.*.wast tests, updates to tests/all/*, and a new major test suite at crates/misc/component-async-tests/*. The current intention is that no tests will land as part of PRs 1/2/3. Tests will only land in PR 4 above at the very end. The goal here is to reduce the size of the diff to make it more digestable and to reduce noise in the PR itself. The rationale for this is that the complete CI matrix is already passing in the wasip3-prototyping repo so we know that all tests are green across the board and that the implementation is already well-tested. Tests can always be consulted during review but they'll just temporarily only be available in an external repository until the final PR is reached.
If anyone has questions/concerns on this plan please feel free to message here! This is the initial draft of an idea of how to upstream all this but both Joel and I are happy to adjust if others feel this should happen different. Currently there is no concrete plan for WASIp3 except "we know it's after the Wasmtime bits", and my hope is that we could use lessons learned from upstreaming the async bits as well.
Steve Williams (Jun 23 2025 at 18:03):wasmtime-wasi-http sounds both cool - will be very useful & concerning - there's danger of bloat going too far with wasi extended functionality. initial thoughts are - want :)
Pat Hickey (Jun 23 2025 at 18:46):the wasi-http spec has been in progress since 2022 and wasmtime-wasi-http has been in the wasmtime tree since april 2023. Its not super helpful or very welcome to get feedback that you're concerned about "bloat" if you arent familiar with the history of this interface and how its the foundation of the shipped component model implementations from several different vendors who fund wasmtime's development
Alex Crichton (Jun 23 2025 at 18:51):@Steve Williams this is not the appropriate topic to be raising these concerns on. I'd recommend raising such concerns with the WASI subgroup if you are concerned about the overall trajectory
Chris Fallin (Jun 23 2025 at 18:54):@Steve Williams respectfully, it's not up to us to delete your comments we don't like. It's up to you to take feedback and adjust to community norms.
You've had a history here of extremely verbose, off-topic messages on all sorts of topics that don't contribute to the conversation or that ask us to help/debug your thing/comment on a random third-party technology/etc in inappropriate ways. We've tried to be polite in letting you know. Please do better in staying on topic and avoid unhelpful contributions.
Chris Fallin (Jun 23 2025 at 18:55):(For the record, you had a message here "if unhelpful, please delete", which you deleted after I responded.)
Steve Williams (Jun 23 2025 at 19:27):you're right to scold. we have no wasi use case & it's optional so I don't care what's in it so should stay out of the subject. apologies.
Oscar Spencer (Jun 26 2025 at 21:37):Hey @Steve Williams, of behalf of the Technical Steering Committee, I'd like to say that I appreciate the passion you have and understand that sometimes it can bubble over. It's great that you've noticed you didn't like what you said and decided to apologize. When you've got some time, take a moment to review our Code of Conduct. We use it to ensure that everyone has a good time participating. Thank you!
Steve Williams (Jun 27 2025 at 06:29):Hey Oscar. Nothing was poor conduct on anyone's part. Simply a collision of ideas.
I've reconsidered. I think wasi-http will be useful for us too, at least in the short term. Needs https support for real-world use cases, obviously. Swamped in work so don't know exactly what everyone else is doing. Hi :)
Steve Williams (Jun 27 2025 at 06:34):The big picture issue is on current trajectory, wasi will end up becoming an interface to o/s functionality. That's no bad thing but from a web perspective, such a thing is called a browser. We've delivered that to MVP already with current release wasmtime as our current wasm engine (thanks all).
https://advance-software.com/develop/#tutorial
My current job is fixing breakpoints in lldbg which have broken, again. lldb fizzbuzz debug test working so seems its solid in wasmtime itself.
Steve Williams (Jun 27 2025 at 06:38):If anything I'm doing falls outside of your interests or behaviour expectations, please be specific. Not trying to force technology onto anyone that's not wanted, nor to promote here when that's not wanted either.
The collision is wasm interfacing to the wider world - you're doing that one way, we're doing it another, html browsers do that a third way (via javascript bridge) & there may well be other approaches.
None of this may interest & you might wish to strictly adhere to your current development plan with no interest in alternatives & if that's the case, that's cool & can continue my work elsewhere with engagement here restricted to only where wasmtime specific issues arise.
Steve Williams (Jun 27 2025 at 06:39):This is all of course off topic, current post, but you chose to extend here.
Steve Williams (Jun 27 2025 at 06:47):Happy to expose this functionality immediately you have it ready & stable, in our stuff, @Alex Crichton
The ability to make an http request & receive a response from scripting unlocks functionality.
That's exciting :) Will need to be encrypted for anything serious. Hence https a requirement.
Steve Williams (Jun 27 2025 at 07:15):libcurl provides industry tested solution to multiple protocols with an acceptable open source licence for commercial work. not a requirement but re-inventing the wheel not a requirement either.
Oscar Spencer (Jun 27 2025 at 14:38):I will message you privately.
Scott Waye (Jul 08 2025 at 16:11):does wasip3 bring a new triple ?
Joel Dice (Jul 08 2025 at 16:15):It will, yes: wasm32-wasip3. wasi-libc (and toolchains downstream from it) don't have support for that yet, so in the meantime you can target wasm32-wasip2 and use wit-bindgen-generated bindings to access p3 features. Only C and Rust are supported so far.
Joel Dice (Jul 08 2025 at 16:16):I'm planning to add Python support (via componentize-py) and maybe experimental .NET support if nobody beats me to it.
Scott Waye (Jul 08 2025 at 16:19):So mixing triples (p2 and p3) is expected to work in the future?
Joel Dice (Jul 08 2025 at 16:20):Yes, in the sense that hosts supporting p3 are expected to also support p2 until/unless we develop a p2->p3 adapter.
Last updated: Dec 06 2025 at 06:05 UTC