Skip to main content
← Back

Transcript: A Year of wasmCloud 1.0: WASI, the Wasm Component Model & 2.0

← Back to watch page

wasmCloud Weekly Community Call — Wed, May 21, 2025 · 25 minutes

Speakers: Brooks Townsend, Liam Randall, Taylor Thomas


Transcript

Brooks Townsend 04:55

Cool. Sounds good. All right — hello everybody, and welcome to wasmCloud Wednesday.

Brooks Townsend 05:08

We've got a quick discussion item and then an issue and documentation page of the week. The discussion item is a blog of mine that we put up on the site a little earlier today to celebrate a little over a year now — a year of wasmCloud 1.0. It was April of 2024 when we released wasmCloud 1.0, and I'm super proud of it. I'm super proud of where we are as a community.

We stayed on 1.0, primarily meaning we didn't make any major breaking changes to the things we started with in wasmCloud 1.0. That's especially important to note, because we based wasmCloud 1.0 on WASI 0.2 and the component model. These were specifications and standards that were coming about right around the time we released 1.0 — I'll double-check the date, but I'm fairly sure WASI 0.2 released in January of last year. So we made a big stance to use that at the heart of our IDL, our RPC interface support with wRPC, and our capability providers. I'm super, super happy about how that's shaped wasmCloud and the community over the last year of 1.0.

The 'One year of wasmCloud 1.0' blog post on wasmcloud.com

I included a couple of fun little graphs at the bottom. Around the time we dropped 1.0, you can see wasmCloud has continued to grow pretty nicely and linearly, which is really nice — over time wasmCloud is doing great. And our contributors and contributions are holding a really high bar and a high pace for the project. We've onboarded many new maintainers over the last year or so, so a huge shout out to Joe Misaka, Mark Massoud, OSS fellow here in the call, Luke, and Aditya, who is also here. All of you who have come into the wasmCloud org have been showing up for quite a long time — we're super honored to have you as part of the community. I can't wait to see this grow even more.

Charts of wasmCloud GitHub star growth and contributions over the 1.0 year

Looking forward — it's not that any project strives to never break anything. At the heart of innovation, sometimes there are breaking changes. But it's become really obvious that leaning on the WebAssembly standards is a huge benefit to us as a project: there's a lot less effort we need to put into code generation behind standard interfaces. So I'd love to continue to lean into WASI, especially as WASI 0.3 comes up a little later in the year. I think you can expect us to adopt that as quickly as possible so we can start testing and writing applications with async interfaces, things like that.

And even with cutting the scope of the project for 1.0, the wasmCloud host — the core of the project — is still responsible for a whole lot. It maintains connections to NATS. It requires a NATS JetStream-enabled cluster, which carries some operational burden once you take wasmCloud to production. It has to manage sending and receiving global information for links and configuration. We have our notion of JWT claims and signing components and providers, which is something fairly specific to wasmCloud. As we look forward to the next roadmap planning session, I'd love to keep thinking about these areas where wasmCloud has a large area of responsibility and find ways to simplify what we're doing at the project level.

At wasmCloud's core, we are executing WebAssembly components and trying to make it really easy to take that and add your own extension points with providers or plugins — to make it the best way to run WebAssembly in the cloud, on the edge, in production. That's easier said than done. This is really just a call to everybody: I wrote this "year of wasmCloud 1.0," and I hope it represents the view of the entire community. Please let me know if you disagree with anything in it. I'd love for all of us to keep thinking of ways to focus on what we do really well with wasmCloud and not try to do the whole thing all the time. We don't need to reinvent the entire world. We've gotten so much benefit from using WASI, so much benefit from using the OCI distribution spec for Wasm and for providers — instead of, way back in the day, having our own registry. So this is a continual call to everybody to keep thinking of ways to make this simpler, easier to adopt, and to push wasmCloud forward as a great project.

That's my spiel. Thanks everybody for listening and tuning into my wasmCloud 1.0 therapy session. We have a lot of people on the call who've been with the project the same amount of time as me, sometimes even longer. Does anybody have any perspective or thoughts on wasmCloud 1.0 and the last year — not to put everybody on the spot — but does anybody have anything they'd like to add?

Taylor Thomas 11:39

Yeah, I very much agree with what Brooks was presenting. We're just moving to that next step of evolution. Over the years I'd say there have been times the host has done too little, and times the host has done too much. Between all those lessons, I feel like we've — I know Brooks and I have brainstormed a lot about this over the past year — figured out what this can look like, where we're going to go, and what it could do. So there are some good things going forward, and I'm just excited for it as we move into the next stuff for wasmCloud.

I'd also note: we're not going to be one of those projects that stays on 1.0 forever. We'll probably have a 2.0, and then a 3.0, and so on. As things become more mature and stable — as we go from WASI 0.3 to maybe a WASI 0.4, and I'm pretty sure that should be the last one before we get to a WASI 1.0 — once we get there, we'll probably start supporting X number of versions for some amount of time. So we're just seeing things evolve and stabilize, and there's lots to look forward to. Anyone who's been in the community this year, or even beyond that, knows we try to make sure we respect that — the evolution from version to version that's breaking isn't terrible. Hopefully we can keep that as we go on.

Liam Randall 13:02

I've been with the project since the first line of code, and I think we've been pretty fearless about trying new things and innovating. One of the things we've always really followed is the feedback from users — we've tried to be really responsive to that. As we've gotten wasmCloud into some pretty high-profile places — you've seen community members come out and give really powerful demos, whether at KubeCon, or Wasm I/O, or any of the other conferences, with a lot of really big names coming out and saying "we're using wasmCloud" — we've learned some really powerful lessons in production. One of the key lessons I've learned is that sometimes less is more.

What we put in the blog post we dropped a couple weeks ago is that the kind of refactoring and design we're thinking through now is to continue to make the host more pluggable and integratable at all layers. Part of that will be refactoring out some of the complexity, making the core simpler, and allowing you to run the simplest piece of the core and then turn on the desired functionality from there.

What I'd like to do is formally reach out to some user groups over the next few weeks. I actually just started — some of you have probably already received a DM from me — to invite you to sit down and do some design feedback one-on-one, just to get your feedback, and then we're going to roll this out into the community itself. As we do that, everybody will have the power to participate in the community like we always do. We haven't determined a timeline yet, because we've been thinking through ideas and iterating — sometimes with partners or customers, sometimes on our own — for the last few months. But I think we're pretty close to formally kicking off some proposals in the community and trying to pull something together on the design side.

Brooks Townsend 15:48

All right, thanks folks. Go give that one a read — it's a fun one, a quick one, won't take up too much of your time. That was actually the only other main agenda item. Now, we are bringing back the segment of the week, with the issue and documentation page that we want to highlight.

On the Issue of the Week: this is a really small one. We've triaged it. It shows a deprecation warning in the wadm logs when you run wash app list or wash app get — it's using the old endpoint, but this is functionally the exact same as running wash app get with no application name now. It's a really small issue, but it would be great if you're looking to get your hands dirty in the wasmCloud CLI or in wash. It would be pretty much a quick shift from calling the list operation to calling get. This is a good one as a first contribution. Thomas — thank you so much. I saw you came into the Slack and raised this as "should I be concerned about this?" and we were like, no, you don't need to worry, but this would be a great issue. Always remember that filing issues and leaving comments is contributing to the project, so it's huge. And Sudhanshu, it looks like you're looking to take it up — I love it, let's do it. I don't think I can assign you unless you comment on it, but I'm not too stressed. Look forward to the PR, let me know if you have any questions.

The GitHub issue for the wash/wadm deprecation warning

Brooks Townsend 17:30

The next kudos — partially to Eric for integrating this in the docs, but a lot of kudos to Aditya for coming in with an awesome idea in the Slack, I think last week. He said the distinction for capability providers and our images isn't always super obvious. The WebAssembly logo is recognizable — it's always purple, it's a component. But we don't really have anything for providers; we'd use Excalidraw diagrams or diamonds, and it's like, meh. I don't know how long Aditya spent on the design work for it, but I love this. The capability-provider icon is great — it's really easy to see the difference now, really easy to see component talking to component versus component talking to provider.

To me it just shows that you're thinking about this stuff, looking at the docs all the time and thinking "this could be better." So huge kudos. Thank you so much for being involved all over the place. We've traditionally struggled with representing the concepts of wasmCloud on an architecture diagram, because with providers and the lattice and everything, there's so much in the abstract — but these little things really help make that simpler.

A wasmCloud docs architecture diagram using the new capability-provider icon

Brooks Townsend 19:54

That really improved that version too. Yeah, look at that, that's nice. Is there another one? I guess this is another place we could throw it into. This is just nice — I like it. I don't really have anything hugely more to say there, but thank you, Eric. I didn't poke through all of the pages, so this is good to know.

Taylor Thomas 20:34

I'll say it out loud for those on the stream: we should probably just make all these Excalidraw resources available as a library. Aditya did all this work, Eric's done all this work — we should put all these things in there and make sure anyone can take it. Anyone who's updating docs can just go access the library and use those components. Or if they need to put together something for a talk that's wasmCloud-related — here are some wasmCloud components, here are some Wasm components, we'll come up with a better name. I think that'd be really nice to have, because this is all really cool stuff we've done. It'd be nice to have them around for everybody. I know I would use them.

Brooks Townsend 21:15

Great point. I'll go ahead and make an issue for that in the wasmcloud.com repo. No huge urgency, but it would be awesome.

Taylor Thomas 22:00

We should just feed a recording of the call into a bot, and then have the bot parse out all the issues for us and create them for us.

Brooks Townsend 22:08

Not a bad idea. Hey, Otter bot, are you listening? That would be nice. It'll be in the community meeting notes if you need it. Well, this is great — we got the thing. I love that suggestion, and we can get on it.

I think that's all we had on the agenda today. Kind of a quick one, with just a couple of discussion items — but good discussion items nonetheless. We got an issue figured out and called out some awesome work. Is there anything from the broader WebAssembly ecosystem, wasmCloud in general, or anything else folks wanted to throw on as a discussion item for today?

Brooks Townsend 23:34

All right, a quiet one, but I think that's good enough. Well, thanks everybody for coming today. I'll give you back some time, in the old corporate speak, and hope you all have a great rest of your week. Have an awesome cloud day, and we'll see you next time. Thanks, everybody.

Taylor Thomas 24:27

No jaundice — if I turn up the warmth on my lighting, I could make myself look jaundiced.

Brooks Townsend 24:41

Way too bright, who needs that. All right — I'm going to go relax. Thanks everybody, have a good one.