Transcript: Bytecode Alliance Summit Recap, Named Interfaces & wasmCloud v2 Plugin Simplification
wasmCloud Weekly Community Call — Wed, March 4, 2026 · 23m 53s
Speakers: Bailey Hayes, Lucas Fontes, Eric, ossfellow
Full Transcript
Bailey Hayes 00:12
I'm going to eat pizza for the next two minutes.
Bailey Hayes 00:20
I didn't hear your audio. Maybe you were already muted. You might have heard — I don't know.
Eric 00:36
Can you hear me now? Awesome.
ossfellow 02:55
Hey — I saw you virtually in the Plumbers meeting.
Bailey Hayes 03:04
What did you think? Was it good? Did you catch all of it?
ossfellow 03:14
I watch on YouTube because of my work. I can't really join live. But day one and day two on YouTube.
Bailey Hayes 03:24
Cool. I just put up a feedback survey in a couple places if you wanted to give us feedback on how to do more next time, or if the format worked, what didn't work. Very interested to hear your thoughts on the Bytecode Alliance side.
Bailey Hayes 03:42
Yep — look in the events channel, there's a Google form. You can do it anonymous or put in your name, and I can talk to you more about what you put in.
Bailey Hayes 04:28
Hello and welcome. This is the wasmCloud community call — first one of March, March 4. We're following a previous week of conferencing for the Bytecode Alliance Summit. If you haven't caught that already, I totally recommend watching it. Both days were packed full of awesome content.
Day 1 was very much focused on the road to 1.0 for the component model. Luke kicked us off. There were other amazing talks — like cooperative threading and the timeline for it, the roadmap around that from Cy Brand. Joel gave an amazing walkthrough on where we are with all the different guest languages. Alex Crichton gave a talk about what it takes to land a lot of these proposals we've been talking about all the way through. I thought that was gold for maintainers. Yordis got a shout on that one — if you're watching this later, you should watch and get your name called out that you did a great job.
Last but not least, Victor Adossi from wasmCloud maintainers came in and talked through all the changes we're making with JCO and all the different pieces and parts that come together. That was really wonderful. Eric, you want to talk about some of the draft blog posts you have cooking on that?
Eric 05:55
We're going to have two blog posts coming out of the Plumbers Summit. Folks can look out for them in the next couple of weeks, in the lead-up to Wasm I/O. One is going to walk through the road ahead to component model 1.0, and another is going to break down JCO in depth as a project, looking at it from five different angles — thinking about it as a multi-tool with a lot of different roles in the ecosystem.
Bailey Hayes 06:25
I've been working on a draft blog post also — you should expect to see it in a couple of weeks for just WASI P3 and diving specifically on the WASI changes we made. That is it for getting you up to date on what's happening external to us. Let's put the focus back on wasmCloud now. Lucas, if you'd like to share where we are right now with wasmCloud v2, I would love to open the floor to you first. I'll also give a shout out to one of the changes that I just put up.
Lucas Fontes 07:21
Thank you. I'm going to share my screen. We are pretty much in the last minutes of this release. The way things will start happening now will be a mixture of wash repository and wasmCloud repository. Quick rundown of what's missing and how this change will happen — in terms of PRs to merge for 2.0 that are blocking, we have very few.
Namely — named interfaces. This is an alignment with the component model where we will have new WIT instructions that let you import the same interface multiple times under a different name. This happens during build time, then at runtime you can bind the same interface — let's say wasi-keyvalue with a different name — sessions versus cache. This way you can use Memcache for one wasi-keyvalue and Redis for another. The runtime part — operator, wasmCloud, and so on — we're getting the configuration in right now. So we are paving the path so that when this is released in wasmtime, wasm-tools, and all the other WebAssembly tooling, it will just work. We just get that feature enabled to us on the spot. It will be optional, so you don't need to specify a name. It is backwards compatible, and things really line up to not have the previous concept of links being pushed forward — instead working with the ecosystem to use something that will work for everybody in all runtimes.
The other one is the removal of the wash CLI plugin system. Let me really be clear that there are two plugin systems inside wash. One is for all the host plugins — when we're talking about Blobstore, key-value, the plugins we usually talk about. Wash also has another type of plugin, which is a component plugin. What this component plugin used to do: you can create a WebAssembly component that's invoked before or after a build, before or after with-fetch. We realized that executing this as a component actually makes things really hard for you to do anything meaningful.
So what we're doing — we realize we don't have any plugins for this right now. We wrote a few that we tried to check the ergonomics — how that would behave — and it didn't feel right. It felt a bit forced. We're taking a step back with that implementation and we'll not have wash CLI plugins / dev plugins in wash 2.0 to begin with. We'll see how far we can get by having the current shell hooks. Inside your wash configuration, you can essentially define which build command you want to execute. If you want to execute a command before another, you put it there and have another shell script that takes care of it. It's a different approach that gets the same end result.
ossfellow 11:49
Hey Lucas, I thought the idea was that for users such as me, wash provides a convenient way to extend what an administrator can do — and then use the plugin model to have it in a standard manner. In the age of agentic coding, for example, if I teach the affects to an agent about wash plugins, then I can use that to create different utilities that I might need in my specific installation. So I'm wondering why it's being removed.
Lucas Fontes 12:50
Great question. We realized it's a bit of "we're stronger together." We could make wash do everything that other tools are doing, or we could play nice in the sandbox — and by playing nice in the sandbox, this means we have in wash the hooks that allow you to bring other developer experiences and interact in a cohesive way. The interesting part about administrators is that in wasmCloud v2, wash is for local development. All cluster administration happens over kubectl. There's a separation of concerns and tooling. That's why it also feels like — if we added this to wash, the initial idea, yes, was to have wash with a kubectl plugin inside and talking directly to Kubernetes. We realized it would be writing kubectl in Rust, essentially.
The way we see this integrating now — in your wash config you can specify the build command and where to expect the WebAssembly file to exist after your build is finished. If you need to ping an external system or enforce some linting rules, you would do that here — either combining commands with semicolons and ampersands, or extract this into a shell script and call it in your wash build flow. Most people are also used to doing npm build, so we don't want to force them to start doing wash build in those situations. The approach: you don't have to always be on wash build for WebAssembly. You can continue your own flow.
Bailey Hayes 15:16
Another example that would be good to show, Lucas, is the one you did for the service — if you've got one handy. In terms of playing nice in the sandbox and being able to use other components to extend what you're doing even when you're doing local development — we basically have it set up now where you can load multiple WebAssembly components. This fills the exact same need that we were trying to (or were thinking we'd) use essentially a plugin framework around, like having local wash dev plugins. Instead of having an entire plugin system around that, have it mapped to what would behave exactly like in production. This is the slimmed-down version of what you would put in a workload deployment. That's a really great simplification.
For me, why I was motivated to remove the plugin system right now: for the longest time we were trying to align the release of wasmCloud v2 with WASI P3, and it looks like it's going to be one more month. I don't want to wait one more month for P3. To get a wasmCloud v2 out there, we have to have an API that we are confident we're not going to break, and that requires a radical simplification of things. When I look at the WIT definition for our plugin system, there are a lot of things I would change to take advantage of P3 and make a lot of those function calls async. Knowing that's coming and that we currently don't have a need for that plugin WIT right now, I'd rather not break the API and require a wasmCloud v3 or a wash v3. I really don't want to try to solve some type of migration story if it's not a key MVP feature.
So much has changed in the evolution where what Lucas was saying — basically, we started thinking that all the different things we have right now on this config file would be refactored into different component modules, whereas in reality what a lot of people want is to be able to call external systems and just give them that exact hook for exactly what they need in their config. We had this radical simplification of what we have to do inside wash itself, and that means very unlikely we'll break the API, which is what I'm going for.
Lucas Fontes 18:00
Less moving parts. That's how you make a system more resilient. So we talked about the pull requests. Now what's happening regarding the repos — we spent most of our life of wasmCloud inside the wash repository. Everything we have in there is going to come over to wasmcloud/wasmcloud and essentially take over the main branch. With that we're going to bring all the pull requests, issues, everything we can use — the magic converter Bailey has — and the things that are in the wasmcloud/wasmcloud repo (the current main, which is v1) will move to a wasmcloud-v1 repo.
So two things will happen — they will move to a wasmcloud-v1 repo (it's going to be another repo). All the information regarding contributors — which is the important part here — all contributors will be kept intact (stars, contributors, community traffic — you're not losing access to anything). This is more for contributors and people with write access. We are not replacing the repository — the repository will remain the same. The settings are the same. What we are replacing is the main branch. The git history will still be there. None of the contributor history is going to be lost. Anything to add, Bailey?
Bailey Hayes 19:55
You called it out directly. I would just say what's currently on wasmcloud/wasmcloud main — I'm thinking what I'm going to do is create a wasmcloud-v1 repo and move that there. The main motivation: the way that we build and publish v1 is so different from v2 that I don't want those two CIs to be intermingled. I want to be able to, if we have to cut a patch of v1 independent of v2, just have that. It's a mechanical thing. We are very close to going and doing that — which means we'll basically pause everything for a day or two, do this migration, and turn it back on. We'll let everybody know in wasmCloud Slack.
Lucas Fontes 20:50
Anybody going to KubeCon?
Bailey Hayes 20:58
Or Wasm I/O. We'll be at both. If you end up going, please come and say hi. Stop by our booth. Booth duty is boring without you. That's our whole agenda. Any other questions or topics we want to raise?
Eric 21:23
Before we close, I'll point folks to a couple of new docs that might be useful. At the top level we have a new and expanded intro on the What is wasmCloud? page for v2 — some pretty graphics, breakdown of the why and the what. Good more detail than before. I hope folks find that useful for introducing new people to the project. But the real meat here is thanks to Jeremy — Jeremy has been on a tear in the operator manual. Want to make sure people see our new operator and gateway overview that gets some great documentation in on the runtime gateway — a bit of a gap we had previously — as well as some wonderful docs for roles and role bindings. Definitely check those out — really good practical hands-on documents.
Bailey Hayes 22:36
Those are all great shouts. We also have a ton of diagrams. Somebody was asking me for a diagram for a problem they had, and I went and looked, and I found I don't know, eight that touch different parts of the story of what they were asking for. That feels good. It's like — not only do I have one link, but I can send lots of different pieces of this puzzle in detail now. In terms of getting ready to launch v2, I feel like we're in an excellent place documentation-wise. If you're hearing this, please go look at the docs and give us feedback. Make sure that what I think is accurate and we're ready to get a lot of folks coming and looking and trying it out once we make big noise about the v2 release.
Bailey Hayes 23:35
Alrighty — any other topics or questions? If not, we're going to get back to locking this thing in. Let's go. Thank you everybody. Bye.