 Welcome both you, those of you who are in person and those of you who are online. We're really excited about our talk today. It's a little, well actually it's pretty much the typical kind of talk you and I tend to give. Little bit serious, little bit not. So if you watch some kids' shows, you might get this reference Bindle's Bundle, but they don't fall down. I actually have to read that because I can't even say it. I am Matt Butcher. And I'm Taylor Thomas. So, oh, you're first. Oh yeah, since I'm on left, I'll go first, I guess. Yeah, so like we said, my name's Taylor Thomas. I'm a director at Cosmonic. So I work with Liam. And I'm a core maintainer, Crustlet, Bindle, Waggy, bunch of other OSS things. If you've been in the Kubernetes space for a while, I'm an emeritus maintainer of Helm. I'm also a rest station. I do lots of rest. As many of us here in WebAssembly space probably do rest because it's the nicest language so far. And there are my various social media handles here. You'll notice that there's a little bit less unity than Matt's over here. So we'll let him introduce himself. Yeah, I'm Matt Butcher. I'm a principal engineer at Microsoft. If you've run across Deus Labs projects, that's the team that I'm on at. Microsoft, we've been doing a lot of WebAssembly work, a lot of Rust work, and kind of stretching back into Kubernetes land. And I'm taking a Sophos pretty much everywhere online. So let's go through our agenda. This is gonna be, this is a quick overview. I always like to have this so people know where we're going. We're gonna talk all about what Bindle is, then go over to two specific case studies, or a case study and a real example of how this could be used in action and then kind of discuss, well, why does this even matter? So first off, if you're curious, there's the link to Bindle, big and bold so you can get there and take a look if you're curious about the actual code. But I'll let Matt take it away from here. It's helpful if kind of in the back of your mind you're thinking about package managers like apt-get and homebrew and things like that, or dependency managers for programming languages like Cargo and NPM, or even things like the OCI distribution spec where we store our containers, or even better, let's just stop for a moment and think about your silverware drawer. So you got a silverware drawer, right? And many of us have these nice little divider things where we can put the forks, the spoons, the knives, keep everything separate. And we've got one storage area where we keep all the things. But when it comes to using that drawer, we use it in different ways, right? I get up, I want cereal for breakfast, I open the drawer, I pull out a spoon. You know, I'm gonna have a spaghetti, I might need my spoon, fork, and knife. I decide to host a fancy dinner, I know this is hypothetical. I might need like all those little forks and those other spoons that I normally don't know what to do with and where they go. But all those things go in the same drawer. So for a long time we've been doing storage in sort of a way where we store everything in separate drawers. You know, imagine going through to set the table and going through six, seven, eight different drawers. We wanna talk about aggregate object storage. Aggregate object storage is when you figure out a way to create that silverware drawer for your data in such a way that it makes sense to have it all in one place. But where you can kind of pick and choose and grab the things that are most important to you at that moment when you need them. In Wasmland, most applications are not sort of the monolithic applications. What we're starting to see is the way that they're getting combined from individual Wasm modules. It can be pulled together in different configurations and then executed. So it makes sense in a way that we wanna keep all of these objects stored together. But given the runtime constraints, right, when I start up the application and I know what the physical environment looks like, I might wanna pick and choose a little bit. So I open up the silverware drawer and say I just need the spoon and the knife for this one. Or I open up the silverware drawer and scoop everything out and lay it all out. But the point there is that with an aggregate object storage system, it's the runtime that selects which things we need at a given time. And when we're preparing everything, when we're deploying things, we can deploy it together and at runtime we can pull that silverware drawer open and pick the things we need. So let's talk about what are the different parts of Bindle. There's some terminology here that you're gonna hear multiple times if you go throughout the rest of the talk and it's important to understand what they are. So we're gonna talk about invoices and parcels first. These are the two key parts of a Bindle. Everything together is a Bindle. Lowercase, if we're being really nitpicky about it. Yeah, who would think engineers are pedantic? But so an invoice is basically the bill of materials or the parts list. Everything that's contained within the Bindle. It describes everything that should be in there and the relationship between those items, which we'll talk about in a second. And then a parcel is an item inside of a Bindle. So that can be literally anything that can be turned into bytes. It does not care. So they don't care what things are in them. It just cares that they're labeled correctly and have the correct SHA. Which the label is kind of the data saying this is the data that I'm expecting and it contains the SHA-256 sum and any additional information about that specific item. So that's the first two parts of a Bindle. Yeah, so really quickly that in the silverware drawer analogy the invoice is like the insert you pop in the drawer that has all the right compartments and the parcels are the things that you drop into those compartments. Yeah, and actually like that's not to completely over make an overall analogy here, but it actually holds up really well there because the invoice is the empty tray. You put it in there and you say, I'm expecting these things. No, the next thing is groups and features and this is really where you get into the meat of Bindle versus other object storage mechanisms. Parsels are really organized as trees rather than flat lists. If you're not familiar with OCI and anything with containers, that's basically a list. It's a vector or a slice or whatever you want to call the data structure of images that are stacked on top of each other. But the way we express this kind of silverware drawer thing is through trees. And so parcels can be organized into groups and these groups can be optional or required. There's a default group that's built into every single Bindle, but any specific parcel can also require a group. So if you enable a specific parcel or a feature that you need, that can say I need something from this group. And then individual parcels can have arbitrary features attached to them. So these features can be turned on or off to require more of the parcels that you need to assemble your application. So those are the big components. There's invoices and parcels and then those things are glued together using groups and features. Which are expressed in the invoice. And we'll come back to that with some examples in a moment so that you can kind of understand why to us this is a really big deal. But before that, let's talk about security because it seems like all the time in the news right now we're seeing articles about supply chain attacks and various ways of trying to inject malicious code throughout the process. Now we wanted to try and tackle problems like that right out of the gate with Bindle because it is our experience that if you layer on security later it's effectively not layering on security because people will opt out of it. So Bindles from day one are immutable. Once you push a Bindle that invoice is signed and then frozen and it cannot change from that point on. We attach signatures to those invoices and a signature is generated by checksumming all of the parcels that will go underneath it and then signing that whole thing together with information about the invoice. And then from that point on we can verify that our item is immutable. And it's important to note there that signatures are actually the only thing that can change on an invoice. They can never change once they're attached but you can always attach more. So it's not something where you've signed it and now you can't do anything else. Yeah, and the reason for that is because we wanted to have roles for signers. So a lot of times we've been talking about signatures as something where it's like, oh, somebody signs it, we're done with it. Right now it's signed. But when you think about signing we don't necessarily trust the developer in some occasions. So we might want somebody else to sign it. Or we might not trust the place where we downloaded the package so we might want to know that the developer signed it. So we introduce this idea of roles where you can say, okay, I am the developer of this spindle and I am signing it with my key. This is what I intended it to be. Now we upload it to the server. The server automatically signs it and says, when I got this from developer X these are exactly the things I got from them and I have verified that they are so. And we added even another one the idea of having an auditor who might be a third party or a trusted party consider like your internal IT department or maybe a security professional who can say, I audited this spindle and I have certified by cryptographic signature that it is indeed doing the things that it says it should do. So we liked adding that idea of roles on top of this signing thing so that we could augment the idea of a software supply chain to say, yes, the same mechanism can be used to sign all of these things. And then it's up to you to say, all right, I only trust stuff from this auditor, right? Or I'll trust anything from this server or I like this developer, this developer and this developer and I'll trust anything they sign but if they didn't sign it then I want an auditor to audit it. And you can start building up those roles however your org wants them or however you personally want them. We just provide the mechanism so that signatures can happen. Oh, first case study which case study is a little bit of a misnomer in this case. This was more our thought experiment that kind of helped us develop out Bindle. So we came up with this simple application called Chow Time, sort of mental exercise here. And Chow Time is an application that helps you find the food you want that's close to you, right? So it's like, you know, six o'clock today and we come out of the conference venue and I'm like, oh, you know, I could really go for something good. I'm not totally sure what I want. You pull out the Chow Time app and say, I'm hungry and it says, well, you know, you had noodles last night, you had pizza the night before, you know, maybe you would like. Tacos. Tacos, yeah, tacos. Find the nearest taco trek here. And then it says, okay, the four nearest taco restaurants that are rated whatever are within this radius and here's the one that we think you'll, Chow Time thinks you'll like the most. So you can imagine an app that works like this, right? Knows a little bit about your preferences, knows a little bit about your history because you've been using it every day and can make some recommendations based on what it believes that you want. Now we could imagine a couple different ways of implementing this, right? We could use machine learning algorithms that might be fairly intensive compute-wise, but would be very accurate. We could also imagine a fairly basic statistical model that'll just say, hey, you know, you ate pizza last night, not gonna suggest it today. No real machine learning necessary there. You can also imagine different data services plugged into the backend, right? I could have a small local database of big chains from around the area that would comfortably fit, you know, on a watch-size device or on something small. Or we could imagine huge, massive data sets that include lots and lots of all the area restaurants plus comments and five-star reviews and all kinds of things. So here we have a couple different ways to build the same application. And when you think about how you might want to run it, you might wanna run it in different modes, right? If you don't have any cell service, you might prefer to run that kind of faster version with local storage. If your device is underpowered, you might not wanna do the machine learning. So in these cases, we could imagine a single front end where different modules here can be plugged in on the backend to give us different configurations. And here's the important part in the thing that's super exciting about WebAssembly is that it's starting to look very much like we'll be able to build applications like that conveniently, you know, with WIDX, with the component model, with type interfaces and things like that. We're getting awfully close to being able to do things like that and determine at runtime. So Bindle's problem here is how do we solve the packaging system such that I can grab an invoice and that invoice says, hey, here's your chowtime application, here's the main entry point, and here are some different options you can turn on or off. You can use this full database, you can use the skinny one. You can use the machine learning one, you can, or just basic user preferences. And the application at runtime, or you as the user perhaps intervening at runtime, could say, this is the one I want now, on everything local and everything fast. Or, no, I really want you to find that excellent restaurant for me because I'm trying to impress people, so use the full power. But it's a runtime consideration. And Bindle is attempting to, through that aggregated object storage system, provide a package manager-y kind of experience that will basically facilitate all these really cool technologies that WebAssembly is introducing. We talked about this. I think I did. Sorry, we talked right through this one. Yeah, there you go. I'm way ahead of you. I'm way ahead of you. I'm just gonna go on to mine. So yeah, we talked about all that. Now let's talk about it with an actual practical thing. This is an example in WasmCloud. This is not real in WasmCloud yet, but it's an example of how this could help with a real world thing. So let's go ahead and take a look. Everyone can see that well enough. I put it pretty big. Okay, good. If someone can't online, just let somebody shout out here in person. So we're gonna go ahead and I'll actually clear so you can see this. So I expressed something that's called, we published things in WasmCloud that are called capability providers. Okay, and they're published in a form called a provider archive, which is right now just a tar ball that's in OCI. Now these providers are actually connectors that bridge the gap between missing or even stuff that will never be added to WebAssembly and current things. That could be like a key value store. It could be an HTTP server. It could be any of those things. And so you have to provide host specific binaries for this to run inside of your system. And so all of these are all bundled together. So I took this and I turned it into a spindle to show what kind of thing this could do. So let's go ahead and I'm gonna just show what an invoice looks like for our KV Redis provider, for example. So this is just using a key value store that's backed by Redis instead. Okay, so there's a lot of stuff here. First, we'll just work from the bottom up. First, you'll see these signatures here. So when I created this, I signed it with my signature. It's available here. You can see the signature, use it to validate the public key I signed it of the key I signed it with and then the role I signed it with, which was the creator. You'll also see that the host key from my Bindle server is also signed it, which is really nice because as you pass a Bindle through various servers because even proxy servers need to sign it and they sign it as a proxy key role. And so you can see exactly where the Bindle has been all the way down the chain. So that's the security features we were mentioning about. But you'll also see here that we have these groups that are all specified. So we have binaries, test and the JSON web token. So there's a JSON web token that's bundled with these things to validate that they are what they are. And then you can choose one of, let's say you had some test binaries that you could use that were just mocking out a Redis or using a local Redis that it spins up. And then the normal real binaries you're gonna use. So all of these are actually specified in here. I think there are 14 different parcels in here but you'll see that I specify like, okay, this is part of the JWT group. This is part of the binaries group and it's from Windows. And you'll see that there's features here where I'm specifying, okay, I have, this is for the x86 arch for Windows. So all of these things are shoved in here for all the different OSes. And then you can, I mean, I'll show you the tops. You can actually see what a parcel looks like at the, at the, or sorry, at Bindle. You'll see here we can also annotate or add other information along here. So I created just a mock example that uses a Bindle server and just pretends that it's a Wasm Cloud host which is, for all intents and purposes, a node for this decision. So like I'm going to run this provider on a host somewhere. So what I can do is it'll automatically select right here. So this is just using, like I said, Bindle underneath the hood. I'm going to say, I would like you to load the key value Redis store, please. Do you want to show a parcel real quick? What the parcel looks like? Yeah, right here, I did, right here. So these are the parcels. So this is the shot, I forgot to mention the shot. So here's the shot and you can specify the media type. And then you have a name and size. So it's expecting those size and shot to match everywhere it goes, along with the feature set. So what this is going to do is it's going to find out my architecture in OS and then automatically select the appropriate binary and only download those things. So you'll see here when I run this, that it fetches the claims because it always needs the claims. That's why it says right up here, it's a required group. And then up here you'll see that you can have one of these groups that's required or not. And so it says, okay, I have this claims one and I'm fetching the Mac OS binary for you to use. It didn't have to fetch all of them. So if you're doing this in OCI, you will fetch every single artifact. And in most object storage, you're gonna download every single artifact. But now let's say, oh, I'm running in a test environment. Please just give me a test window. So I just mocked this by passing a test flag. So that would obviously be set by whatever system is using it. But now I do it and you'll see that it's changed to use, I mean it's a mock thing. I didn't actually show everyone in there, but you'll see that it's the test bundle or the test binary rather than the other real official one which we see up here. And so this allows you to save bandwidth. It also allows you to select and assemble the specific things you need for your circumstance. So in this case, it's super simple. It's like, do I need a test one? Or do I need a real binary? But with the example in chow time, you can see how this starts to expand bigger and bigger. Well, what if I need this or this or this? Or if I pick this, then pick one of these two things. You start to express this huge graph of features and then you only need to pull the things you need. So this is very, very efficient and useful. So that's kind of what we'll hopefully see here in the near future with things like WasmCloud but also how this can be used across various WebAssembly projects. It is worth pointing out that we don't necessarily intend that a user would assemble that file by hand. Yeah, no, this isn't a hand editing tumble. That's not, it actually even uses JSON if you want to. You gave it that option in this. But there's multiple tooling things that can be used to generate this inside of code and whatnot. So let's get to that question of why does this even matter? The first thing is that this is very good for distributed systems. And like we've mentioned before, particularly with WebAssembly, I can run a heavy compute module if I'm running on a big machine or a light compute module on a smaller device. And like I said, there's bandwidth saving as well. The software supply chain security aspect is another big thing there. It's not the primary reason why we created it, but like Matt said, if you don't put security in at the beginning, then people, and layered on later, people just opt out of it. We've seen that with Kubernetes, we've seen that with Docker. So it's built in security. And this is an if statement, but I think it's a strong argument to make. I think we've already seen some things. We'll see more if the future of Wasm is this swappable components idea. Bindle provides that storage layer that allows application developers to express how that application can behave with any situation that it's in, whether that's this heavy compute, whether that's other specific requirements for your runtime or platform, it can do that. Was that any I missed? No, but I think it's worth, kind of as a kind of wrap up statement. I led with asking if they're prompting with this idea that we've got different kinds of package managers, right? We've got some that are for operating systems where an operator determines which pieces and parts they wanna pull in when they install something. We talked about dependency managers for software developers where they're saying I wanna pull in these libraries while I'm building my software. Bindle is really sort of attempting in some ways to merge those two ideas. Because sort of the core intuition with the way WebAssembly is shaping up to work is that WebAssembly modules can be built ahead of time, but then depending on how we want to compose them, the operator has decisions to make, right? The ChaoTime example is a good example of that, right? And so if we do this well, and if WebAssembly works out the way that we're all hoping it will, then we can build a sort of package infrastructure that meets the needs of the developer at development time. And then when it comes to deploying, it meets the needs of the SREs, the DevOps team, the operators, right? And when we think about where we are in the cloud native landscape, we can see this pendulum swinging back and forth between the kind of developer-centric models and the kind of operator-centric models. And we probably all heard sort of the rumblings that developers are unhappy with how much they have to know about Kubernetes to even be able to deploy an application on it. So what we're hoping is that if we can start solving this problem on the component layer in WebAssembly itself and even on the package manager here with tools like Bindle or something else that works in the same vein, right? Then we can carve out that right sort of center point where we can separate the operator concerns and the developer concerns, and we can build a tool that's really gonna meet both groups where they are. And this we think is one step in that particular direction and one reason why I think WebAssembly is just one of those tremendously exciting opportunities for us. And so the steps from here are to give this a try. We want people to try this out. We want people to give us feedback. So Bindle is actually a specification first. We wrote the spec... I've never had so much fun writing a specification. It was a specification first. The Rust library you see at the link I shared at the beginning is just the Rust implementation. You can implement a client. You can implement a server. It just has to meet the things that are inside the specification. And so we really just want feedback. We wanna make sure the spec's right. We wanna make sure the software's right. It's functioning as needed. Do people find it useful? Do they have better ideas? Any of those things are what we're looking for. So thank you very much for that. We'll go ahead and open up the floor for questions. Anybody wanna start? Go for it. So the question for those online was, what's the difference? Is there, does Bindle support OCI? Or is there, what's the relationship between the two essentially, right? Oh yeah, you're gonna repeat the question. Make me, a lot of what you see in Bindle is definitely inspired by OCI. I mean, the idea of, you know, the content addressability of it and hashing and shying things that way. And we do believe that you can store a Bindle in an OCI registry if you can figure out how to store the invoice and the parcels both in there and then fetch the invoice out. But it is not based on OCI in the sense that it has a separate protocol. It uses separate formats and things like that. Likewise, we think that you will be able to back Bindle with all kinds of storage, object storage, file, well we've done file system, we've done some basic database kinds of implementations. But no, the primary difference between the way that OCI is designed and the way Bindle is designed is that OCI is designed to be a linear list of layers that you take, right? And the tree structure of Bindle, we couldn't quite map that onto top level OCI distribution artifacts. So the invoice was sort of born out of that need to be able to express tree-based relationships with groups and feature flags and things like that. Did we explain the difference between groups and feature flags? Yeah, the groups and features. Yeah, the important thing just to note is that a lot of people are like, well, what if we're still using OCI stuff? We've thought about that. I think you're going to see things from stuff like we're doing in Wasm Cloud and whatnot where you might see some OCI compatibility stuff to make it easier for people who wanna try this out. We have a question online, which is how do Bindle rules correlate if at all to things like the update framework rules? It seems like they're similarly inspired. I honestly cannot say that we looked at like tough or any of that. We looked at, Roddy and I looked at tough and in Kodo and yeah. I think with the signing stuff, I remember that. But I don't remember looking at like and I'm not sure if we really defined it from there or not, but... Yeah, there is a lot here inspired by the way that tough defines different roles. In fact, the very presence of different roles and I'm actually kind of looking forward to hearing opinions from people who are well into tough. Our interest was just slightly different than what tough does, right? In the sense that tough is all about how to do the updates and ours is really more about package, how to certify that an immutable package looks like X, but the roles were inspired very much by the way tough does things. We hope that this was our first pass at a lot of this stuff and we hope that we will learn a lot from the work that tough and also the work that Intodo did. Intodo does software supply chain and when we were working on CNAB, we did a lot of work looking at the Intodo specification as well, brilliant specification. The two of them together I think just nail a lot and so we are trying to learn as we go from those two and from other similar security specs.