 Our goal is to eventually provide a Bicode Alliance instance so that we have a set of building blocks of canonical components that everyone is able to extend and build on top of. But we don't just stop there. We want to make it so that we can collaborate across different instances so that maybe an individual company is able to host their own private components. And we can also foresee several different communities out there that build, for example, specifically Envoy. We already have a WebAssembly hub for Envoy. And with that, there's use cases that are very specific to their community. So if you can imagine, several other different communities might exist, like WasmCloud. And single stores use defined functions. So let's take an example of I have a company called Acme. And I also am working with in the Envoy ecosystem. My business wants to write an authorization library. I've got a lot of specific business rules in there. And Envoy gives me a lot of cool out-of-the-box HTTP filters, like open tracing. Now, both of these components will probably need another key building block. This is a hypothetical one. Everybody that's working at this level probably needs to be able to decode URLs. So let's provide a common component, called the URL, that both of these are able to build on top of. Now, once we have that, how do we know where we're working in, what defines an HTTP proxy? Luke introduced this concept of worlds earlier. So let's imagine that this works like a LEGO baseplate that we're able to build on top of and assemble these components that define the ecosystem that I want to be able to have a sidecar proxy that's running with authorization and open tracing. That's the entire idea behind our protocol and APIs for work. Now, those are the first two key features that we want to provide, but there's one that's incredibly important that Kyle's going to share. So we just talked about component orientation, working with the component model, and how that lets us build building blocks, and a little bit about sort of federation and the way these can interoperate between different registry instances. I'm going to talk a little bit about how we can, some ideas that we can steal from certificate revocation transparency and what that lets us do. So first we're going to go over a little bit of background. In certificate transparency, when a CA issues a certificate, it actually makes a record that it did so in an immutable log that requires it to make a public commitment to all of this. And you can check using the root of the log that any given entry was included. There's also a structure called a verifiable map which is used to track revocations. It's indexed by the certificate, so you can look up for a given certificate very efficiently, hasn't been revoked, which you can't do by traversing a log. O-N. So we can sort of generalize these into a data structure called a log backed map where we have this idea that the backing log stores all of the changes to the map. So for this certificate it was issued, for this certificate it was revoked, and the map essentially has the current state of everything, right? And that's how you look up what's it like right now in addition to what the history was. And this data structure is really useful and we're gonna borrow it in a second. So now the question is how can we make a registry that's as transparent as a CA and achieve package transparency as we're calling it? The first thing is that we make the state of every package a log with events that cover things from the initial creation of that package to adding and removing maintainers, releasing and sort of unreleasing different versions of the package and potentially annotating the log with other information and auditing data. Then what we do is we combine all of the logs for each individual package into an overall log backed map where at any given point in time the state of the map is the head entry of every package log. It's like an index into all of these little logs and the backing log actually stores a reference to every entry for every package. And that means that at any point in time in the system with these vertical lines here they represent the system at different points in time. There's a root hash, a signed root hash for the log in map that represents the system at that time and if you have that there's some cool things you can prove and it sort of encode the state. And for example, you can take the state at slice three and at slice six and you can cryptographically verify that everything that was in three is in six. So what does transparency give us? One of our scenarios is that transparency helps us manage vulnerabilities and incidences. If we have a simple registry that has just one package in it this LibURL package we were talking about before it has one release. It might look like this. And if you have another package this authorization package that's being used to have this custom business logic for our Acme company then maybe they have a release that's dependent on LibURL like we're just talking about. But if something goes wrong and we find a vulnerability in LibURL there's a potential that we'll be able to put an audit entry in its logs that everybody can tell we found something. And correspondingly we expect that you probably put that same or a very similar entry on the dependent package as the same problem. Now because the maintainers of LibURL are good people and they're doing good work they're gonna release a new patch and yank which is sort of our term for unreleasing marking something as not fit for use. The bad version. And the authc package will do the same. We expect that you would say okay cool here's our new version that doesn't have the problem. And when that happens both of them will be able to pass the next round of audits that come their way. And all of this will be observable in the log as planned. That gives us a really good insight into exactly what happened and how it was responded to. The other thing that we can do with this level of transparency is detect operators that are compromised and begin to behave badly that begin to act maliciously. When you download a package like this authorization package you get all of the records for that package as well as that root I keep talking about for the state of the system at the point in time you've queried it. Then what you can do is, and these are now the bold lines you see here that I've just added are represent these proofs that we can construct fairly efficiently to show that all the package entries that we see here were in the log that everybody else is seeing them to if they have a root that's compatible with ours. And this is part of this idea that we have about making it so that if a registry lies about anything it has to lie about everything. That's sort of the fundamental idea here to change the state of one of these package entries I have to lie about the entire state of my system. And that's really easy to catch. So let's say that the operator is compromised. And so now it's somebody who got the keys to the kingdom. They can sign things on behalf of the operator of this registry. So what they might be able to do then is start lying to you. So the next time you ask them you say, hey I wanna know more about this open telemetry package. Give me its data. You get all the logs for it. And you get a new root for the system. But maybe it lied about what used to be in the log there. Maybe it's actually tried to change history on you. In order to do that it had to commit to a new root that has this lie embedded in it. And what we were able to find is that while that package entry is included in that root it's part of the lie and those are consistent. What isn't consistent is the old root with the new root and the old root with this new package element. And the client can easily detect the malfeasance that's occurred here. So we're really excited about sort of bringing state of the art in transparency to package registries in a way that I don't think we've ever seen before. And so we obviously gained a lot of inspiration from many other existing projects. But it doesn't stop there. Warg itself is gonna be an open API built on open standards. And so what we hope to see and kind of expect to see is that many of these existing projects will implement Warg so that we can bring an entire set of projects and ecosystems into a world where we can build with components. Now our entire tenets behind all of this is to provide components, give a way for interoperability across registries and federation and to provide package transparency. One of the key reasons why everybody is so excited about WebAssembly is the principle of security has been something that has been a key part of the language and later the ecosystem. And so this is really just an extension of that. We wanna make it so that everybody has a bucket of Lego bricks that they're able to build on top of that creates an entire new ecosystem. So thank you. Thanks.