 I'm sure people will trickle in and out. That's the normal thing here. So welcome everyone to Untangle That Spaghetti Code, make dreamy fettuccine instead. We'll go ahead and start off with some introductions. Like my life. Apparently that's not working right now. But that's working. OK. We'll take it. We'll take it. So I am Taylor Thomas. I am a engineering director at Cosmonic. Wasm Cloud Maintainer. Big restation. I'm pretty large. I do a lot of large rest projects. And then I'm serial open source contributor. The picture of me on the right is actually what happened when Bailey described me to an AI and tried to have me made into the rest crab. And it's a little cursed, but I like it. So anyway, great picture of me. I love doing some demos. We'll do a lot of those today. And that's just a little bit about me. My name is Bailey Hayes, and I'm a gopher. This is my curse gopher. I appreciate, actually, that her ears are rather large. So we kept that. I'm the CTO at Cosmonic. I also code and rest, but we're for the sake of this. Let's call me a gopher. And I'm a Wasm Cloud Maintainer. I'm a WASI co-chair and also director of the Technical Steering Committee of the Bicode Alliance Foundation and just, you know, longtime Wasm enthusiast. So today we're going to talk about how we can take our spaghetti code and untangle that into dreamy fettuccine. And we're going to talk a little bit how to do that. You might guess, since we're both Wasm Cloud maintainers, that we're going to use Wasm Cloud to do this. We're going to show off some demos and more demos and, you know, the mostest demos. So I hope you enjoy. And we're going to do it in the style of a cooking show. Yes, thank you. Let's go. The chef's here for your enjoyment. So let's just start off with some honest things here. Yeah, and this is totally a terrible pun. But most code that you write is boilerplate and copy pasta. You've got to boil that pasta somewhere, right? And I'm sorry, like there, we said it. I'm guessing no one's actually surprised or offended by this, but if you are, just go look at your last big project you wrote. Everything you have in most project is a whole bunch of boilerplate and copy pasta. Every single piece of it. And we're just going to, like, rather than just pontificating on that, we're going to go ahead and just go straight into like, well, what does that actually look like? What does that look like, Bailey? So we wrote a really simple application to show what we're talking about. This is a really basic Go app. It's got Gochee doing our HTTP routing. It's a CRUD rest service that, when I call the HTTP endpoint, it increments a bucket. And so that bucket is a key value store. So you can see I've got a dependency there for DynamoDB. And so this is a whole lot of lines of code for what is a counter incrementer that is all it does. And so it is the simplest app that we could come up with that has some, you know, some of the typical aspects that you see in cloud native microservices today. And so if we take that and we just look at what we made, well, over like 90% of that is copy pasta and boilerplate. It's over nine dependencies I've brought in. They have absolutely nothing to do with the logic of incrementing a key value bucket. And every single time one of these has a vulnerability or a patch update to fix a bug, we've got as a developer to go and bump that version. So we've got a dependabot, we've got a CI system set up. And so this is very much something that is burning you right now as a developer that you have to deal with. And so that's really frustrating. Yeah, like really, if you look at this, there are like out of those nine dependencies, just think about what's there. This is literally the dumbest app we could think of. And it's nine dependencies. If we started to do anything for real, that dependency tree would just keep increasing consistently. And I even, if you look at the code previously when I wrote this all up, there's not even the configuration stuff that you have to do that's specific to Dynamo and specific to your HTTP stack and all those things. None of that is even in that example application. So even with all that, that was the dumbest app when we have all these dependencies. And so you've probably seen these diagrams before from service meshes to service meshes. They are necessarily complex, right? We want to break up our pieces of our stack so that we can update them independently so that we can have a well-defined API to interact with them. Those are the things that we want as developers. But when we get a hair ball like this, a hair ball of spaghetti, it doesn't taste so good, right? It's really dense, it's really gross, it's really hard to take one strand out of that and be able to understand it and refactor your architecture. And so that is one of the things that we are trying to solve. Yeah, everything here is all about the things knowing how they're architected. They have to know they're connecting to a cycle. They have to re-emphasize. If anyone here from Amazon or Netflix is in the audience, which I don't know if there's here, but there's definitely here at the conference, it's not an insult to that. The complexity is needed, like Bailey said, but it really comes down to everything here has to know where it's running, how it's architected, what's available to it. And so that is why Wasm Cloud as an application framework exists. It's a platform for building distributed applications. You can do this simply with batteries included. It's built on, it's a CNCF project, so it's Sandbox project right now, but we're hoping to move to incubating this fall because we have a number of different folks who have deployed this into production, including ourselves. It's built on many other CNCF projects, including NATs. I'm gonna read off here. Cloud events is a standard. We use OCI. We use open application model for creating declarative manifests and then open telemetry, which is also part of the CNCF, is another key part of our stack. And Wasm Cloud is really built to run and orchestrate all of this for you. Like it says here on the slide, it's all about having this stateless thing that can fail over automatically. All of this is given to you, given to you inside of Wasm Cloud by default. And really with the advent of basically components, what's landing right now, we're even more excited about the future because Wasm Cloud's been doing this for years. We've been doing this for about four years, honestly, at this point, where we've tried to detach these non-functional requirements, all the spaghetti code stuff we're talking about and move it outside of your business logic. And when we've done that, we've discovered that this actually is a very nice pattern for developing your application. So Wasm Cloud makes it really easy to run across all these different systems, all these different components by leveraging the power of WebAssembly, but also just by leveraging a lot of these open source technologies Bailey was mentioning. So with that, we're gonna actually untangle the spaghetti. Now it's the cooking part. We explained all the ingredients in here, but let's talk about, and we're gonna do the little chef's thing. There we go. And we're gonna talk about how we untangle this spaghetti. So I'm gonna go ahead and share exactly what this looks like with everybody. So first things first. I'm gonna talk about, we're just briefly mentioning this. This is honestly something that can be a whole nother talk. But we have this thing that we call WDAM. It's Wasm Cloud Application Deployment Manager. Yes, it said like a bang like in a comic book. That's why it's called WDAM. And so this tool is available. I'm gonna be showing this inside of Cosmonic. Everything here is actually completely open source. You can try this open source. There's nothing proprietary about it. We're showing it on Cosmonic's platform because it's just easiest to show it that way. Cosmonic is also built on top of Wasm Cloud. Yes. And that is something that we can show off later for those who are interested. And right here, we have these application manifests. I'm gonna actually show you what this manifest looks like. If you're from the Kubernetes space, this will look very comfortable to you or annoying. Either way, could be both. And this is the open application model standard, like Bailey mentioned, and we describe everything we're gonna do. So I'm gonna use this to actually launch all the different components we're talking about here. Now, while it's launching, I'm gonna go ahead and show inside of this infrastructure. I have a couple different hosts connected here. So I have a Cosmonic managed one that's running. That's over in US East. I have this laptop connected right here. And then I have why I left my badge up here. I have that Raspberry Pi connected. We're not gonna be showing that in this demo, but if you want to, you can curl it right now and it'll hit there in display text. Please don't send dirty words. Well, I do have a filter in place, somewhat. So anyway, so that's what we have set up here. So I just deployed a bunch of different things for our demos and example. I haven't put these all together yet and I'll explain a little bit about it. Everything in these demos is going to be focusing around this actor we call blobby, little blobby tables. I think you named that if I remember right. I did. I wanted something that talks to a file system, talks to a blob store. And so we needed an abstract contract to refer to that. That's a lot of words. So I was like, you know, it's blobby. It deals with blobs. It could be a file system, could be a blob store. And so let's create a blobby that knows how to interact over HP. So let's create a crud rest service. And so Taylor then took that and then really made it production ready. Like you're not gonna see a lot on wraps here. We do full error handling. This is significantly more than the Go app that we showed. And how many lines of code is that, Taylor? I think total lines of code. And we're still in the process by the converting this fully over to like some of the new wit things which will make it even shorter. We're looking at 254 lines of codes. This is a full HTTP crud file server like Bayard was mentioning. And what I wanna point out here in the code, you don't have to know Rust to understand this. I'm saying, hey, I handle a request. That's all it's saying. You'll see nothing about ports. You'll see nothing about the stack that it's running. It just says, hey, I'm connecting to an HTTP. I'm receiving requests as an HTTP server. And then when we actually talk about the blob store that it's sending to, this is all that it looks like. It's just saying, hey, I'm sending to a blob store. Like I don't care what blob store is underneath. You've probably seen a lot of this. If you were in the last talk, I know you saw it. It's just like, I have a blob store. I don't care what blob store is at the end of this. I can just write to it or read from it. And that's what this code looks like underneath the hood. So we're taking this and you can see this show up. There's an HTTP server and a blob store that it's looking for. I want you to imagine at this point, right, that we're sending in a kitchen. We've got a bunch of different ingredients laid out across the table and now we're gonna start doing some assembly. Yeah, and we have the stuff in the oven right behind us that we'll pull out to show you. Okay. Our souffle. Anyway, so we're going to take blobby and we're gonna just do the most simple of the examples first. We're gonna connect this as just an HTTP server through our wormhole, which is just an ingress point into Cosmonic. Simple as that. So I'm gonna connect that. And this is what we call linking. So what's going on here is I'm saying, I need an HTTP server. What can give me an HTTP server? Well, in this case, it's the ingress stuff that we provide. We'll get to do a lot more of this as we come up. And then we also have just a blob, like a pretending like our file system's a blob store. And I'm gonna actually specify where on my system this is gonna basically be rooted at. I'm just gonna root it inside of my temp directory. So I'm able to provide configuration and all those details at runtime. And so now I have this application running. Now, sorry, I have to go back and forth. I'd normally have this off to the side so you didn't have to, but I'm gonna just show, I'm a lazy guy and I don't wanna type it all out. So I'm gonna first start, actually let me impig in this. Okay, can everyone in the back see that now? Okay. So I'm just gonna create a very simple HTML file. Put it out on desk. Woo-hoo, that's not that exciting. Let's actually get to the part that is exciting. So I'm gonna go ahead and put this up, use it like a file server. I'm gonna upload this index.html file up to the file server and give it the content type index.html. Okay, great, we got a 200. I'm doing it with the V-flags. You can all see that it's real. I'm not faking this, this is all live. So I just uploaded this file. And now I can actually curl it back and get and know that the file is there. So I get 200 and I get my file back. Okay, that's not that impressive yet. So we'll just show that this is an actual application. I'm gonna go ahead and delete this file just so you know it's not there. I'm gonna try to curl it back and you'll see we get a 404 because it was deleted. And then I can put it back again for our next example. Crud service. Woo-hoo, there we go. So that is the first application. Very simple, straightforward. But it's just a simple but real application that you could use for many different things. Now this is where it gets a little bit more exciting. So let's go ahead and run this with like it was a web server. Just serving up that HTML file we just created. I'm also gonna do something just to show how this all works. Remember how I said like it doesn't matter what the HTTP server is? That's what I'm gonna do now. So I'm gonna actually delete the link between those two things. So I am dynamically on the fly swapping out from HTTP server, my ingress to an HTTP server that's running locally. Because it's running locally, I do have to tell it like what kind of port and things do I wanna listen on. And so I'm gonna do that right now and have it listen on port 8080. We're dropping from an HTTP server that's out in US East and now US right here, right now. US right here, US Seattle right now. So I'm gonna go ahead and go to HTTP local host 8080. Oops, sorry, crap, HTML. And so there we go. So now we have it serving up. Now just to what I can also do, and I forgot to do because I was linking this live, I'm gonna actually delete this. And once again, this is a great example because I forgot to do something. I forgot to turn this on to just normal like web server mode, I just gave it an address. So you know what, I'm gonna actually just update this and say, okay, address 0.0.0.0, 8080. And I'm also going to turn it to read only mode so that it's only reading out to true. I'll create that link. Okay, so I just reconfigured it once again, not having to restart the application and not having to move it around. Doesn't matter where it's running. And now just to prove that this is working the way I am saying, I'm gonna just create a new file. Hello there. And I'm gonna try to upload that file to the file server, to this, basically this web server, which you wouldn't want to normally do in most cases, right? Hey, 405, that's not allowed. So I just changed this from a full file server to just serving content. Just with a single chain. Once again, no code changes. No, nothing else has changed here. No redeploys. Yeah, no redeploys, nothing's going on there. Okay, so let's do something a little bit more crazy. We're gonna go ahead and come over here to the API again. I'm gonna say, okay, I'm done doing this locally. Let's go ahead and terminate that. And I'm gonna reconnect it. So now once again, reconnecting it back to something that's out running in the wild. And then I'm going to change this out to something else that could be another real world application. Now I made this once again just simple so people can follow along. But let's say you need to have encryption at rest with your data, or you have some sort of key or signing thing that's going on. Well, in this case, I implemented a provider that uses hashacorps vault as the storage. Now you wouldn't do this in real life. You wouldn't actually store it in vault. But for purposes of this, I'm saying let's say we're encrypting it at rest or whatever it might be. So I just wrote this. I didn't have to make any changes to my underlying host or my platform. Nothing changed there. And I'm able to come here and say, let's not do that anymore. Let's actually hook this into vault. So I'm gonna do a token. Luckily this is just a local thing. So I'm not worried about sharing my token out here in the world would not do this normally. I'm gonna go ahead and set this token and link it all together. So now it's linked up. So now I'm gonna do the exact same thing where I curl up a file that new file I created, the hello there. Okay, and I just send it out. So what just happened here is I sent it up to an endpoint. We're running in a managed cosmetic thing in US East. The actor itself was running inside of there as well. And then down on my machine, I have vault running. So it sends it over here into vault and stored it in vault on my machine encrypted. So we're starting to see how this distributed thing starts to come into play. And we can actually go look if we look at vault. I will go ahead and grab the data just straight out of vault. And you'll see obviously this is just raw bytes but that's hello there with the new line character. You can count up the bytes if you don't believe me. So if you're paying attention, that would spend three different types of deploying an application, three different demos. And so we're starting to get some complex aroma into our gourmet. So let's step it up one more time. Yeah, one more time here. So like Bailey said, these are three entirely different styles of applications all with the exact same building blocks. But let's do one more like semi real world use case here. Once again, this one is just simplified for ease of showing how it all works. But let's say you need to do content validation. This is a common thing we see from like, there's lots of document services that you could have DocuSign, Adobe has document stuff, all these things and you could have to cryptographically verify that the image or the document is a real thing or you could want to have a signature on that document. All those things could happen after the fact. Now once again, that can be an entirely external dependency to what they're trying to do. All that you're trying to do is store the data. So we're gonna go ahead and actually connect this to this file system hash blob store. So I'm just storing it locally on my file system again. But I'm gonna go ahead and specify where I'm doing that just so we have it. And now that's all linked up. Now we're gonna go ahead and create a new, that same file that we created before we're gonna upload it to this blob store. Can I copy that? Okay, we've uploaded this thing, it's now there. Now what I can do is I can take this, take it and you'll see that I still have the normal file there. Okay, so I still have hello there. But I also calculated in this case, just simple shot 256 sum. And I can get the shot 256 sum. So once again, this is a simplified version but it is really easy to extend how you would see this in a real world usage. I could take the same blobby building block and build something that entirely hashes does whatever it needs to do with an incoming file and stores it somewhere. And my business logic that actually does that part never has to do anything. So you're now at, how many Bailey? Four, right? That is four, but we haven't delivered dessert yet. No, we have not gotten to dessert. That was four applications and think about like even if we just were to stop here and not give you dessert, which we do have dessert. We're going to, you've now seen four different applications with the exact same building blocks. You didn't see any change code. I didn't deploy anything else. It's just all the exact same blocks all put together. So good old blobby is your WebAssembly component. It itself now is a composable component that other people can build with. In our case, we're running it a lot like you would think some of those microservice pieces that were in that initial spaghetti hairball. And I think that's really powerful, but you know what else is really cool about WebAssembly? It's polyglot. I can build from many other languages, including my favorite one, and I can now make globby. What is globby? I mean, I like my Rust, Bailey. What's this? Good old globby. Globy is the exact same thing as the Rust one, but better because it's written in go, way fewer lines of code, actually, A. And it is using a lot of our new WebAssembly interface types definition. It's a component, and it is also using, right now, these are prefixed with our WasmCloud. That's our API. The WasiCloud core hasn't moved through the phase proposal process, but we're basically built on the exact same interface as that, actually literally exactly the same, I think, as of today, so that's really exciting. And so globby is therefore better than globby. And all of these things, like Bailey said, are running as components. So we can put these all together, and like Bailey said, we're still, component model, if you haven't realized, is still very bleeding edge, so we're still converting this all over. We're active contributors to the WasiCloud stuff that you may have heard about. We really want to do this, because we've been using these similar contracts for years now at this point. So we're gonna go ahead and show you that this actually works. I'm gonna hook it up to the wormhole, like we had before, and then I'm gonna hook it up just to the normal blob store that we had before. A little bit of drum mold, because this all just started working. So we'll go ahead and try to put that file up again. We'll hope that it works, because you know, the demo gods could finally. It's the moment where you pull out the souffle, and you see whether or not it rises or falls. The souffle has not fallen. We now have an uploaded file, and I can actually go ahead and curl that file back, and it should still work like we're expecting it to. And there we go. So now we just took a, it's the same application, so it's not a, we're not doing a different application, we just took that key component, we replaced it with something that was an entirely different language. This is the kind of future we're really looking for with components. You can do these things right now with WasiCloud, but like components makes this just infinitely easier, because once again, these contracts that Bailey mentioned are just basically the WasiCloud interfaces. So as soon as everything's like rolling out and stable here, you'll just be able to take this and say, you know what, like, eh, I don't like running it over here. I'm just gonna go run it over here. It doesn't matter because it will have those same contracts to use. This is a lot of freedom and flexibility that we've always wanted as developers, but we haven't been able to really get to until this point. So with that said, let's start a little bit of just wrap up around, like, what we covered here, what was going on. So what does all this mean, Bailey? Well, you can swap out anything. You get to build on the latest standards. You can, when you are doing this swap, you're avoiding bugs, you're avoiding vulnerabilities, and I can recompose and re-architect my entire mesh of all my different services that I provide, easy and at runtime, without having to recompile my code. And once again, just emphasize what we had said before. This can happen both at the code level thanks to the component model and at a distributed level because of Wasm Cloud. So it's combining these two technologies in a way that is very, very powerful because now we have stuff underneath the hood and as these things come out, we'll actually talk some more about it. We needed to actually fix it. We discovered some bugs and how it works. That's how bleeding edge we're doing with this. So we couldn't even show some of the stuff we wanted to show with how we can do some really interesting things of swapping out at a code level. These things that allow us to basically layer stuff together, that's the thing that's provided by the component model and eventually we should be able to do that dynamically as well. So if we ever write a bug, which is common for all of us, in the layer that translates, the Wasm Cloud specific logic that happens in here, we'll be able to just transparently swap it out without breaking anybody. And then because it's distributed, we can run these things at different levels. This badge right here, the reason I brought it is there is one of these providers running on this badge. This badge actually sends signals out to code that's running in Cosmonics Managed Host, which then sends a message back to here. So when I click this button and it changes text, it's actually doing something where it goes to another, like my business logic is living in an entirely different place. That's something that people need for the types of applications they build at large corporations. You have to run stuff in different places sometimes. And this really simplifies it because the business logic is not running on here. It's not taking up some of my paltry 512 megabytes of RAM. It's running and taking up things elsewhere. And so that's why these things become so important for us. So how can we get started? How can we tell people to get started here, Bailey? Yeah, well, I'd love for you to come taste slash try out Wasm Cloud. It's a CNCF project, as we said before, and Catch Me, Taylor, Brooks, all of us are walking around and we'd love to post a little tasting. But also, if you would like to sprinkle a little bit of bacon on the rest of your component model entree that we've been building, I really recommend you joining the Bicode Alliance Con, that's why I called it Bacon, otherwise known as Componentize the World Event. And that is tomorrow morning, going throughout the day. We're gonna get together, keep working, work through some of the rough edges that we talked about, but I think it'll be a really good time. Yeah, scan that QR code if you're interested in joining. It's free, it's good to RSVP, so people can plan. So yeah, come out, join our community. We have a Slack and then also that is another QR code to our GitHub org. So with that, do we have any questions? Can we pull up Globby's source? Yes, I think we can, let me see. We can jump over to Jordan Rash. Yep. Shout out to Jordan if he's watching. We appreciate you. So there's nothing super WASI Cloud specific. Right now we have these here because once again, these are the exact same interfaces, but we're still working on the actual WASI Cloud standards like solidifying. And so we have those in there, we're still working on converting everything. But this is right now what was in our current actors in just a little bit, because you were at the workshop yesterday, we actually had, I can show what the workshop looks like. Yeah, that's another great place to get started too. Yeah, so this workshop that we did, which was building a simple KV counter example, the thing I wrote and go to show off as an example, these things you'll see there is absolutely nothing WASI Cloud specific here. If you look at all the imports here, there's nothing that has anything to do with WASI Cloud. This is what Globby and Globby are gonna look like probably in the next two weeks. So we're gonna have, you just have the wit bind gen that's reading in the stuff. It's using WASI HTTP, which is exactly what you'd expect. And our world has the import of the key value type. And then we're using that key value type to increment things down here. But there's zero WASI Cloud specific logic. And so you'll be able to take these components I've been showing and just move them over. Providers are WASI Cloud specific, but even they will eventually become WASI. They're still gonna be probably WASI Cloud specific, but they're just implementations. And so really it's not, the idea is to avoid lock-in. We care deeply about that within this project. We don't wanna lock you in. We love if you use our stuff, but also we know that like reality is you're either gonna reuse it in multiple places or you might have a good reason to move it somewhere else. Why build with WebAssembly? Portability. And so if you add a bunch of vendor stuff here, you lock people in and you lose that portability. So I want people, I encourage them to come build on WASI Cloud, but also, you know what? If you come up with something that is like the smartest, bestest ML inferencing thing ever and you wanna run that right next to your data and you run that as a user defined function in single store, I wanna be able to support that, right? That's what developers ultimately want. They want that flexibility. They also want to be able to run their code anywhere they actually need to run it. And so that's why WebAssembly and WebAssembly components are perfect for this use case. Yes. Hey. Good question. I actually, believe it or not, I'm qualified to answer this question. Most of the time I wonder if I am qualified to answer questions. So a while ago, I helped create a project called Bindle. You may have heard me talk about it. That was one of the first attempts we had tried to do to do this. That was actually even integrated into WASI Cloud. The community's been working together on a standard called Warg, which is also a very good nerdy term. I have to give props to that name. Land. Props go to land. Yeah, land on that. So and yes, as soon as that starts to solidify, we're gonna land it. Right now though, we're just focusing on getting the stuff into OCI, which is, I mean, a standard everybody knows and pretty much everybody supports. And so for now, it's OCI, but we're tracking that work carefully because we wanna integrate that in and we're gonna have to leverage it. We need something that can tell us when I was talking about that dynamic thing, oh hey, I have this WASI Cloud specific logic that I've put onto your component so that it runs right inside of here and I need to update it. How do I know which things implement those interfaces and which things I can pull down? That's what a registry like Warg is going to do and we're going to use that in the future. Any other questions? Yeah, yes. So that's actually what we do. So when you look at, and that's the thing, you have a trade off between the dynamic linking part, where you want to be able to dynamically put something in, but you can version these. And so for us, we actually have. There's the WASI Cloud actor component. That's the composed piece. So it has a version. It's also signed. So we know that you can't change it after the fact. I can't take some component that's internal to it and then swap it out with something else, sneakily and evilly as part of some supply chain attack. But there's also part of the component model specification that also includes version in all of those interfaces. And so what Taylor's about to talk about is on the WASI Cloud compose side. Yeah, so we're going to have something that's called WASI fills. This is actually, if you heard Luke's talk about virtual platform layering, this is going to be one of the first big ones I think out there that we have around how we get this to work, all these custom things to work inside of WASI Cloud. And so this RFC, it's inside of WASI Cloud, it's 497, you can just search for WASI fills. And this one has various worlds. And if you'll notice, we're actually going to require strict versioning on it. So when we say down here, we say all of these things have to be strictly versioned inside of a, inside of basically an OCI thing for now until we get work and stuff. And so when you package this all together, we know that these parts over here for the layering part are together and they're a single piece. And then over here is your actor and right now you have to literally fuse that together. And so that gets a unique ID inside of WASI Cloud. So there's some technical details, we could probably talk some more with you after, but things are going to be stable. This is something like Bailey mentioned, you can package your, you can make sure you're versioned with files, you have versioned things when you send them. And then things like Warg require you to have basically stable IDs, whether through tags or shaws. Yeah, and Taylor, you mentioned the word WASI fill. If you're familiar with polyfills, it's sort of a fun take on that and that all of these standard interfaces are defined through WASI. And so, you know, it's like a WASI fill because we're not just polyfilling like through JavaScript or through Rust. We're doing it actually with another WASM component. We're composing those together, that's the trick. Yes. Do you want to answer that? Yeah, I mean, I think you should talk about the invocation signing. Yeah, so one of the things that we do, well, number one, there's the built-in stuff with WASM, right? Like if there's no, if we can't satisfy an import, we can't run the WebAssembly module. So that's there. But WASM cloud is a very deep security model. Every actor and provider that you run is signed. So it has a unique cryptographic identity, which is part of how it gets routed everywhere. It also is every single thing that gets sent across the system is signed. And so if you try to send to something you're not allowed to or you try to link to something you're not allowed to, you get denied. Even if you manage to get, for example, the link, that line drawing, which I don't think you can, but even if you do, like after that, you try to send it, it's gonna say, wait, you're not authorized to do that. Like you're not signed, you're not allowed to do that. So we have that at multiple levels that helps prevent any of that. Like did I connect it to the right place? Because it's either gonna tell you, sorry, you can't connect to that or it's gonna tell you you're not authorized, depending on the situation. Yeah, I guess earlier I said, why use WebAssembly? It's portability, but I guess also, if you're in the WebAssembly space, it's security and sandbox ability. I should totally highlight it, though. That is absolutely one of the key goals of AsumCloud as a platform. I think right there we're at time, so we can continue any conversations in the hallway track out here, but thank you so much for coming.