 All right, all right. So hello, everybody. My name is Valim Bauer. I'm one of the maintainers of Project Harbor. So if you don't know it, Project Harbor is a container registry with a pretty few advanced features. And today, I'm going to talk about how to dynamically proxy Helm charts as OCI artifacts, what it is in detail, and why it makes sense for you to adapt as well. But before we go into the details, there is one important thing you should take away from the next four minutes is that what should you take away? No. So you should take away that OCI, all the things, is very important. And why it's important? Because it's easier than you think, right? You can use it also for your own internal artifacts, very efficiently and easily. And I'm going to demonstrate it with our proxy for Helm charts. So what is the problem? And as you maybe know already, Helm supports two types of artifact transport mechanisms. One is a traditional way. And since version 3.8 or whatever, it also supports OCI artifacts. And the problem here is that most of the public OCI artifacts that you find on the internet are in the traditional format. But the majority of the registries is in OCI format. And a lot of people adopting OCI formats for inside their organization. And they have developed workflows for that. And so we have a clash here. And it would be very nice if we could adopt it to use OCI everywhere. And can we solve the problem? Yes, we can, right? Currently, people do it by just manually fetching artifacts and then converting them and pushing them to registry. But you can also use it dynamically. And this is what we built. This is the architecture, very simplified. So we have the OCI proxy in the center. On the left side, we're talking to the traditional artifact transport mechanism like you find on the internet. And on the right side, we have the OCI format that we provide. And this you can use then for directly, to address directly each artifact as an OCI artifact. Or you can combine it with Copeo or Harbor and then replicate all those artifacts as OCI into your own registry, which is very convenient if you're in an air-gipped environment or on an edge environment. And from the user perspective, it's very neat. Because in the case of Helm, you just address every chart as an OCI chart. And this is how you specify it. In the first part, this is the URL of your proxy. And the second part is the URL of the chart that you want to proxy from. In this case, it's JetStack. And in the third one, we address the artifact that you want to proxy. In this case, it's certainly a third manager. And in the last parameter, we specify the version. And this way, you can address the classical artifact or traditional artifact in as an OCI. And so this way, we can basically dynamically proxy all artifacts to our own registry or for our new use case. And we have made the project public. So you can use it as a starting point for your own endeavor. Or you can use it as is for proxying inside your organization. This is the QR code. And this is the link if you just Google for Helm chart OCI proxy, you will find it. And the takeaway from all this effort is basically two things. First, OCI is becoming the factor standard for artifacts. And the same with what S3 became for objects or for files. This is going to be happened for OCI as well. And so you can adapt it yourself. You can build proxies for your own artifacts that reside in your organization that it may be whatever. And it's not very difficult. It's very easy to implement something like this. You can use our project as a starting point. You can also use project oras as a starting point, which is also a very powerful tool that you can use for this. And yeah, you can build upon it. That's it for my side. Please use the project and contribute or comment. If you want to talk to myself afterwards, if you have a question, you can find me at the booth, at the Harbor booth. I think it's in the community, P2. Otherwise, yeah. That's it. Thank you.