Transcript: wasmCloud GitHub Actions Toolkit, Wash Attestation & WebGPU
wasmCloud Weekly Community Call — Wed, Oct 1, 2025 · 47 minutes
Speakers: Bailey Hayes, Colin Murphy, Liam Randall, Mike
Transcript
Bailey Hayes 05:22
Hey folks, welcome to October's wasmCloud community call. I've got a fairly short agenda today, mainly just updates on continued development on the next version of wasmCloud, and I also wanted to highlight that I released a GitHub Actions toolkit. I showed a mostly-working version of this last week and did a quick walkthrough. I'm going to show it to you working end to end today, and some of the benefits of that, and also some of the features that I'm working on for wash. Does anybody else have any agenda items or anything else we should run through, or questions? I know we've been pretty active asking questions in wasmCloud. Hi Brooks, if you watch this, we miss you. He's been out on vacation having an awesome time, and that's why you're stuck with me again today. Sorry, but he'll be back next week.
So first things first, let me show you GitHub Actions with wasmCloud. Over here, I cut a new release last week. I didn't major-version it. I'm not major-versioning anything that depends on the next version of wash or the next version of wasmCloud, but this is in that push of getting everything in place before we start cutting the final release candidate and doing the major version rev. Here is a monorepo that includes one action that is actually pulled out of that monorepo. So over here it is in its own GitHub repo. This is something I had to do to be able to put this action in the GitHub Marketplace, so that people have an easy way to find it — sort of the canonical way to set up and install wash. This one I did give a release candidate, because I'm not really expecting to make too many more changes to it. It's feature complete, but it's not ready to be a stable major version until the next version is out as a stable major version, because it's designed around the next version of wash, which we're currently on beta 9. Every time we've added a new feature, we've been cutting releases just one-to-one, and we've been making really good progress on that. This includes plugins that you can install, and there's a plugin I've been iterating on quite a bit — I'll talk a little bit about that as we go forward. Essentially you can install wash and immediately set it up, and this will leverage the cache.
One key change in the past week since last time we chatted is that I set it up to install and attest from binary versions of wash. If we go back to the top-level actions repo, where we've got a couple of other actions running, it's pretty interesting to take a look. If you look at the CI we're running for this, it actually treats it as its own project, so you can see what a real run would be. If I look at the continuous integration for it, you'll see this helpful feature: now we're always creating attestations. If you're doing the publish operation and you opt into attestation — this is built into GitHub's native integration for attestation. What I can do from the GitHub CLI, for example, is say gh attestation, and then ask it to attest which artifact we're using. In theory you should be able to use it against any component that you build and publish with this action, but I'm also taking advantage of this for that setup-wash action as well.
Part of the reason I opted to install from source and then always reuse from the cache in the first version of this was that it's not considered a security best practice to install from something like a raw download — it's probably fine, but since I was making something for other people to consume, I wanted to go the extra mile. So now, when we build wash, we create an attestation for the binary build of wash. When we do this release for wash, you'll see that I added this extra verification stuff — I've got SHAs for it. Because this version of wash is now attested, if you look at the install for it and search for dash-b, you can see that you can opt in to making sure we're verifying that this artifact has a provenance chain and has been signed and attested. So now that we've got signed artifacts that we're publishing as part of the wash release, we also have this installer; you can opt into attestation from that, and the setup-wash action itself does that always — you can't opt out. We're making sure that whatever we're installing in your GitHub workflow has been attested, and then once it's installed there, we cache it. So that's the key change for this one over the past week.
Bailey Hayes 11:40
The next thing that's kind of interesting is that inside the actions repo we also have a publish action that you can drop into one of your existing workflows. If I open this up, in this case I did this for a Rust component, and I used a tool called cargo auditable. One piece that's neat is that this is Wasm-enabled. When I do a wash build, which then runs a cargo build, the output is obviously a .wasm — but it's a .wasm with the SBOM of the chain, basically what cargo knew about. Right now that's being built with first-party SBOM support coming in upstream cargo, but until that's done, folks are using cargo auditable for this. Again, opt in on SBOM generation. If you want it, and you're building with a Rust project, you can use the action I published here called setup-cargo-auditable, which configures wash to build with cargo auditable and not just default cargo. You've got to make sure you put it before your wash build, but otherwise this wash build output is now immediately attestable.
Next one up is wash build. It's exactly what you think it is — I don't want to spend too much time on it, but the handy thing is that we produce output, so it's really easy to figure out what .wasm got built. And what's nice is you can do this in a language-agnostic way. If you think about it, when I do a cargo build it obviously goes to ./target; if I do an npm build, it's going to go to maybe dist or somewhere else. Every different npm technology that's like a rollup equivalent puts it in some special place. So having a common, easy way for all these different GitHub workflows to know where to look for the artifact path is the basic idea of why you'd want a wash build action. It felt like something that didn't need to be published to the GitHub Marketplace, although I could be convinced. Right now it's just a composite action, and the way you depend on it — the OCI-published one — is either, well, in this case I'm doing a local reference. Let me give you one other example of a project I've been building and just successfully built, and the way I refer to some of this stuff for a publish.
Bailey Hayes 14:10
So I just gave you an example of a publish.yaml that takes advantage of all these actions. The main thing I wanted to highlight is that you don't have to have something in the GitHub Marketplace to be able to refer to it from the GitHub repo and compose it in. The reason to put something in the Marketplace is basically for discovery, so that when somebody searches the Marketplace they find it. Instead of wash — wash, I think, is our hook to get them started, and then that'll refer them to all these other actions we've built out, that last one being publish, which gives you attestation. So that is the quick walkthrough on the updates on the GitHub Actions toolkit. Feedback, contributions, totally welcome. I think it's working really well for a Rust component. I've got a couple of other changes I've been cooking that make it work well in a lot of other scenarios for other languages, but the TL;DR is, for the most part, it's language agnostic, and you can just slot it into existing workflows. The trick is whether or not you publish to a well-known location that we know to pull the artifact path out of. Oh, I have been totally ignoring chat — I'm sorry, I am not Brooks.
Bailey Hayes 15:27
Okay. Anybody else have a question about those changes, or any discussion in that zone? I'm sorry I keep starting all these calls with, "Hey, let's talk about CI." But it's really important, especially when you're building a CLI tool that you intend for people to build through CI, to make sure we've got that story buttoned up before we cut the release. One example of why I think that's super important is what I ran into. I created my own plugin. My plugin takes advantage of a feature that's part of wash, which allows the plugin to execute commands on the host. It's obviously a privileged operation, so we say, "Hey, do you want to allow this copy to happen, or this git clone to happen?" User says yes, and then it happens. But what about when you're running in CI? Nobody's there to say yes, and it's not a TTY shell. So what do you do? Well, I've added a non-interactive mode: if it's a non-interactive shell, then we just go ahead and run in that mode by default, and that'll allow us to do this in a CI workflow, which is what I needed. So that's one of the features that has landed inside wash over the past week.
Bailey Hayes 17:00
I think this one was handy to have, but there's a couple more major feature changes I want to make before we call it ready for a release candidate. Another one I started on is the idea of adding volume mounts. Right now, what we essentially have is every plugin effectively gets its own scratch cache directory, and we just mount that in if the component requests a host import of a file system. If you're a plugin, you're probably either copying files into that or generating them there, and that's your own little sandbox that nobody's supposed to mess with. The plugin I was using — Brooks helped write the part where it basically copies the scratch results at the end with a host exec, which is one of those privileged operations, which is why I ran into having to fix that non-interactive feature. It copies out of scratch back to wherever the real path is on your host system. That's pretty weird and unexpected, I think. I talked to Brooks before he headed out and he agreed — that's probably something we want to change. The basic idea is similar to what was shown last week about how the next version of the host and the workload spec has a concept of volume mounts. I'd like to propose that we have the exact same thing when you're working with wash and plugins — load them with the same kind of flow with a volume mount. That allows me to have a couple different pre-open doors. Sure, maybe I do still want a plugin cache scratch directory, but maybe when I run my wash plugin in my project's directory, I just want to mount my current working directory straight in and modify in place. That's the main goal of this change. I'm still working on it. There's a little bit of alignment to do between this one and the pull request Brooks has up for the runtime, which is a bit of a chunker, and I don't want to get in his way — since he's going to be back soon, I'm just going to avoid that. But this is in relation to what Brooks walked through two weeks ago. Once we land this, I think we've got a couple more features to land, and then we're looking pretty good for the next version. All right, those were all my updates. Do folks have other community updates or anything else they want to share? I'm gonna stop sharing.
Bailey Hayes 19:41
Hi Colin.
Colin Murphy 19:43
Just wanted to make you hear the solipsism.
Bailey Hayes 19:47
I'm not in a void. It's nice. Thanks again, Colin. By the way, Colin is now one of the champions for wasmCloud's proposal, and he's been landing some API changes and a new feature — time zones — which is a much-needed one, much requested by Colin, actually, as well. For wasmCloud, which is cooking, we've got a release candidate out — a second release candidate out now that folks are implementing, and that's what KCD and I were just chatting about before this call started. Hey, I think it's time to do the implementation of the new wasmCloud APIs. Colin, if you need me to cut another release candidate for all those things, I can.
Colin Murphy 20:41
I'll try to get it out this week. Unfortunately it's gonna be some refactoring of how the clocks work, because the code is going to be totally different.
Bailey Hayes 20:54
Yeah. But I feel like a lot of that work is on track. We're on track, as in, we're working furiously on it so that we'd be where we wanted to be in October. And major shout-out and kudos to Victor on the call as well. He's been making huge progress on the second reference implementation inside JCO. That takes a component and basically makes it run in a Node.js environment with all of the same APIs, but obviously in a totally different way than the way wasmCloud supports the new specs.
Colin Murphy 21:35
Yeah, really excited for 0.3. I feel like with all the stuff we've done around GPUs and cryptography — that I've done, or people near me have done — I feel like we can get wasmCloud to just do GPU, get it all in there, and really make something anyone can just compile to and not have to care that it's wasmCloud. Just run really fast, and it'll just work. They won't even know they're doing WebAssembly. That's my goal. So yeah, we can get it all going. Hi Liam.
Liam Randall 22:20
Colin, when you think about the different choices for what APIs you might use for programming around a GPU — WebGPU — what does it offer as far as hardware agnosticism and the other value props that make it a good choice here? It's obviously integrated into Chrome, Firefox, and Safari, right? It's a pretty ubiquitous standard at this point, with, I think, like TensorFlow.js, which compiles to Wasm — it uses it, doesn't it?
Colin Murphy 23:00
Yeah, there's a few different things. There's actually been a lot recently — I don't know, we're live streaming, and I don't want people to get mad if I say things.
Bailey Hayes 23:14
Let me wrap this call up. People who are on will be here for the after-hour.
Colin Murphy 23:23
I know. I'm not enough of an expert — maybe enough of an expert to do things, but not enough to comment on standards and what should be done. But yeah.
Bailey Hayes 23:34
Yeah. Well, there's a lot I want to add here too, and that's definitely speculation. So if anybody else has no more questions or other discussions for wasmCloud — if so, thank you all for joining us today, and now you know what your incentive is to join us live and come hang out on the Zoom call too and chat with us. But if not, we'll give you a summary in the wasmCloud Slack if we come up with anything too cool.
Liam Randall 24:01
I'll drop the Zoom invite over in the YouTube chat, in case anybody's hanging out over on YouTube. I think we also typically have a bunch of people that watch on Twitter, of all places. But I don't know how to drop anything in your chat, so maybe someone else can figure that out.
Bailey Hayes 24:19
I'll try. All right, thank you everybody. Have a good Wednesday. Okay, we're no longer recording. So Colin, I think you were going to talk about WebGPU implementations and the alternatives.
Colin Murphy 24:35
Yeah, so there's a lot that compiles — well, transpiles — to WebGPU, so Babylon.js, TensorFlow. There was ONNX, which is deprecated and did not support all the ONNX calls, which is how we kind of got into this mess to begin with. But yeah, WebGPU is definitely the standard, and it's really just whether — there are two competing ones. There's a Rust-based one that comes from Firefox called wgpu, and that's what we've been working with — specifically Mendy's been working with. But then there's also the Google Chrome competitor, which — I always think I know what it is, but I'm gonna say the wrong thing. What is it called? Dawn — I have to staple it to my forehead. There's a lot of work going into Dawn and they're very excited about it, and they're trying to get — but it doesn't really matter. It's just the back end. So we don't care if it's Dawn or wgpu on the other side. They're just pushing it forward. Things are probably going to land in Dawn before they land in wgpu, but it's C++. I mean, ONNX Runtime is C++ as well. Chrome is putting a lot of — AI is eating the world, so the Chrome team is putting a lot of effort into Dawn, and they've started inviting me to more meetings around it. So yeah.
Bailey Hayes 26:39
Yeah, I've been pretty interested in the Firefox developments in that space as well. I think the blog post is like "Firefox agents in your browser," something like that, because they've added a Mozilla-maintained inferencing engine to the browser itself, and so it lets you write sandboxed agents — whether it's Wasm, maybe it's just JavaScript bindings to that extension — but writing agents that run in your browser, so it's safely sandboxed away from other people. You keep your personal information local, you're running inferencing locally. That way you could be like, "Hey, I want an outfit, and I'm actually colorblind. I don't want everybody to know — please go and shop for me and buy me an outfit that looks cool."
Colin Murphy 27:30
Yeah, I think personal agents — within C2 and the spec, we have a lot of work around that, just around who's doing the work. If you have 500 agents or whatever, and who you're attesting for, the person who's done the thing — that kind of dependency chain of attestations. But just think of so many things — even glasses, smart glasses. You want it to do certain things for you, agents that do certain things for you, and know people's names or whatever — that should be somehow separate from the Meta, you know, that kind of thing. So yeah, it seems like this is where everything's going. Hybrid AI inferencing is the thing that I'm working on, and we could use it at Adobe, hopefully. At least Google's trying to tell us we need it. So if Google's trying to tell us we need it, then they can convince people that we can do the server side of that. We can get the Chrome people getting the client side, and then we can get the wasmCloud side, get the server side, and it'll all just be WebGPU, and it'll be seamless, no matter which side it's on. That's my goal.
Bailey Hayes 28:58
I am talking to D later today — one of the chairs for the CG — trying to line up some of the things she's proposing with what we would use in the component model. Do you have any requests for her, or anything that you need?
Colin Murphy 29:17
I see her every other week. But yeah, just make sure she knows — as long as we say each other's names in the meetings, we're all working together.
Bailey Hayes 29:28
She works with her team. I'm not thinking of a different D, right? There's only one D.
Colin Murphy 29:42
Yeah, just make sure — because, you know, can't trust myself. Where is she? Deepti Gandluri.
Bailey Hayes 30:06
Yeah, except I only chat with her on the WebAssembly Discord.
Colin Murphy 30:10
Yeah, that's the one that sounds right, okay. But yeah, that's good, because when I have mentioned the component model, she kind of looks at me like, "oh okay, what are you talking about?"
Bailey Hayes 30:31
Well, Ryan Hunt is going to be giving an update on that at the end of the month as well, which I am super pumped about. Luke Wagner, one of the OG creators of WebAssembly, along with Ryan Hunt, who's a pretty awesome technical lead for the Firefox implementation — they're both giving an update on using the component model in Firefox.
Colin Murphy 30:58
Yeah, is she going to hear that?
Bailey Hayes 31:03
I hope everybody hears that, including Colin — right now I'm shouting from the rooftops. I don't know what it's going to be, other than I just saw it come through yesterday, or maybe two days ago, when they added it to the agenda, and I was like, "Hey, what are you doing? That's awesome." But they only added the one sentence, and I don't see any slides or anything yet.
Colin Murphy 31:25
Oh yeah, I'd love to see it. It should have happened years ago — whatever, get there, get there.
Bailey Hayes 31:37
Eventually Victor's gonna make it work great in the browser, with JCO. I know it's gonna be so easy — it's gonna be a lot of work, but it's gonna be awesome when it exists.
Colin Murphy 31:52
All right, good job, Victor. Thanks for staying awake with us. I added at 2:30 in the morning, so.
Bailey Hayes 32:05
I don't think he sleeps. Liam started this call asking me if I sleep. When I get excited about something and I need to get it over the line, I'll crash. But I don't know what he does.
Colin Murphy 32:15
We don't know how you do it. Otherwise the browser stuff is definitely not gonna be done anytime soon, I think. That's what they say every time on everything, pretty much, except for WebGPU — they're very excited to move that forward.
Liam Randall 32:28
Yeah. I mean, look, there's just so much rolling opportunity at the moment. wasmCloud over the next few months has just a ton of awesome updates coming out. We started rolling out the new runtime operator last week, and then there's what that enables. I know Bailey's been super heads-down on stuff that she'll be releasing in the next couple days or week or so, as she lands the last couple pieces here, that we think is awesome. And then we just have a ton of goodies throughout October. I mean, it's just going to be like — wasmCloud or something. Should have practiced that before I tried it. Yeah, didn't work. But you know.
Colin Murphy 33:18
Yeah, okay, we tried.
Liam Randall 33:23
You gotta throw a lot of spaghetti at the wall — comma — see what sticks.
Colin Murphy 33:27
Yeah, I guess, Liam, like when they put the motor oil in the potato chips — that Olestra, the fat-free chips, with negative vitamins, because your body had to shed them.
Liam Randall 33:50
Well, I think it was created by the same team that did that cereal varnish in National Lampoon's Christmas Vacation. The non-nutritive cereal varnish, yeah.
Colin Murphy 34:07
Well, except it was real. I don't know if it was just an American thing — it probably was. It didn't really catch on in the US and Canada.
Bailey Hayes 34:18
Well, I'm gonna go eat lunch, and then I'm gonna be back at landing those wash changes. If anybody has any opinions on some of the features I put up, or the design there, now's a great time, because I'm about to change the API again, which means I have to recompile all the plugins again. It's a big lift. I'd like to stop doing that. So feedback now rather than later, because it's getting increasingly more painful as I go along, as stabilization happens.
Colin Murphy 34:55
Okay, right, bye.