 Welcome, everyone. Thank you for coming. This is particularly strange for me as I have not seen almost anyone in three years. I have not spoken at a conference in three years, so definitely a time warp back to when I used to speak at a lot more conferences. So I'm just going to do a quick recap just in terms of where we've been over, I guess, now the last couple of years, which wanted to highlight a bunch of the work that's been going on within the project. That's pretty cool. First thing, of course, is now we have Quick in HTTP3 that's generally available. So that's been a ton of work by a lot of people. And very excited to see this now being used a lot more widely. Obviously, there's still a lot of server support that's going to be needed. So it'll be very interesting just to see, you know, how this rolls out within different cloud infrastructures and all those kinds of things. But I would expect to see much wider deployments of this technology over the next couple of years. That's very exciting. Very excited for people to try it out and give feedback. The project obviously continues to spend a tremendous amount of time on security and fuzzing. We still have lots of people that are updating our fuzzers, finding bugs. The folks at Google have been fantastic in sponsoring a third-party firm to actually go through our fuzzing backlogs. Because as you might imagine, there's lots of false positives in the fuzzing framework. So getting through all of that noise is fantastic. So we're burning through that backlog. This is an area of the project where actually if you're interested in helping, we always have a large number of fuzz bugs that aren't real bugs. They're just bugs in the fuzzing framework. But we're always looking for people to come in and actually help fix those. So if that's something that you're interested in, please come and speak up. And we would love to rely on you. Ah, Linux. Okay. Sorry. It was working. Is it showing at all? No. Let me see. Is that working? No. I'm not really sure what to do. Let me see. I'll try replugging. If not, I'm just going to wing it. Is it what? Sorry. There were slides. Okay. Thank you. Thank you very much. All right. So back on the security and fuzzing. So this also comes back into software supply chain. So, you know, I think a lot of the things that the project deals with at this point, which will be the theme of my next slide is, you know, they're not super exciting things, but they're very critical things. And as you all know within the industry at this point, software supply chain is getting a lot more scrutiny. Envoy is no different. So we spend a lot of time trying to make sure that we're not depending on projects, you know, that are not up to the standards of our own project. And, you know, this means auditing obviously to make sure that we don't have duplicate dependencies, looking at the dependencies that we are using and actually making sure, you know, that they themselves take security seriously. And one of the big efforts here is that, again, thanks to the folks at Google, we are replacing our, all of our HTTP codecs with Google provided codecs. We've used the HTTP-1 parser for a long time. That codebase is deprecated, so we can't use that anymore. And then for a very long time, we've relied on NG HTTP-2 library. And long story, which I won't go into on video, but the maintainer of that project has not been very amenable, you know, to working with us on a security perspective. So a lot of effort has been going into, you know, making sure that the supply chain for those critical components is up to our standards and that we can rely on that. So that is work that's ongoing. It's been ongoing for quite some time. And we'll continue over the next few months. One byproduct of that, which again is a boring, but very, very, very critical issue that's been open for a long time, is that historically for HTTP header validation, we've had different code for each of the codecs. And this has been a known issue for a long time, but this is, you know, minor, very small things like, you know, do you validate white space and all of those things, right? And there's all kinds of rules. And that has been implemented independently for each of the codecs for HTTP-1, 2, and 3. And as you might imagine, this has led to a large amount of complexity and a lack of understanding about whether it's actually consistent. So folks are working on what we're calling the unified header validator, which again, from a security posture perspective will be absolutely fantastic. So we'll run the same code to do all of this HTTP layer validation across all of the three codecs. So the combination of that as well as the software supply chain I think is going to get us into a much better place, which is super exciting. Next major topic, which is the, frankly, the often bane of my existence is CI and build and release. You know, it's just a continual thing that always needs fixing and updating. But we have a bunch of people led by Ryan Northley, who have been doing a tremendous amount of work on our tooling around build and release. And we are very close finally to being able to ship signed binaries and signed packages for various different operating systems, which has been a long time reclass of the project. People have long been unhappy that always ship our Docker images. So very excited to finally have that be built into the project. And I think that'll be coming hopefully finally in the next couple of months. Again, this is another area of the project, which has nothing to do with the low level C++ code. But if you like Python, if you're interested in this type of tooling, there's just perpetual work that is needed. So lots of work happening there. Obviously, people continue to work on WebAssembly. And I think in general, you know, frankly, this has gone a bit slower than I would have thought. I think there's been more performance issues than people realized. It's a very complicated piece of technology, but it is becoming stable. And I think they're fixing performance issues over time. So I'm excited for all the work that's been done here and all the work that will continue. Next up is probably you've all heard of Envoy Gateway. You're going to hear more about that today. And just the brief story there is we would like to make it easier for Envoy to run on Kubernetes. Envoy itself, as many of you know, is a Swiss Army knife technology, but is very complicated. The barrier to entry is high. So we would like to make it easier to run for certain common use cases. So I'm very excited about this project in terms of making it easier for folks to get started with Envoy. So we'll hear more about that today. And lots of work happening with Envoy Mobile. We have it shipped out to almost 100% of users at Lyft. Folks at Google are starting to look at it pretty heavily. We have various other companies that are starting to onboard. So pretty excited about the future of this project also, and we'll hear more about that today. And the reality is that so much work happens on the project at this point that I honestly can't even keep track. I mean, there's just so much happening all the time, and I'm sure I've missed many important things, but just want to give a big thank you to all of the people that do so much work. And if you look at the release notes every three months, you'll see there's just so much going on. So just a quick thing in terms of the state of XDS. I just wanted to point out, you know, that at this point things are becoming a lot more stable. We're obviously focusing on general API stability interoperability between things like Envoy and GRPC. Because of that, we're seeing a slowdown, you know, in the number of new APIs, which is a good thing. We're also trying to push everyone towards ADS for all new things, you know, instead of defining new APIs. So hopefully that'll also make things easier from an implementation perspective. And because of this, again, showing the maturity of the project is we don't deprecate anywhere near as many things as we used to, which is great. So things are slowing down and becoming a lot more stable. And on that note, you will hear it here first, although I'm going to do a policy update at some point soon, is we've basically decided at this point that there will never be a V4 API and we're never actually going to deprecate anything. So any APIs that you use, they will be there forever. We've had this discussion with the API shepherds and it's just becoming clear that the API is so widely used at this point that, you know, trying to remove code at this point or remove features is, it just causes so much pain. So and because the rate of deprecations is going down, I think we feel that this is an okay posture to have. So hopefully this will make people have less pain in the future when it comes to API updates. We will still deprecate fields and, you know, push people to doing the new things. But in terms of actually removing the code, you know, there's no plans in the future to do a V4 API, at least not right now, or at least not while I'm still around. And my final call to action is, you know, one of the things that I like to think about is Envoy boring now, you know, and we started Envoy seven and a half years ago, Envoy's been open source for six, and in some ways I think Envoy is boring now, you know, it's not as exciting as it used to be. It's not as apparent as many venture capitalists out there hounding us all the time. And which is good, right? I think we've had so much success and it's been so fantastic to see Envoy deployed in so many different ways that it is a bit boring now. But it's boring obviously because of all of your hard work, so thank you all. And my pitch, though, is that boring software still requires a lot of work, right? So it's my continuous pitch to all of you that we still need help, you know, around lots of different areas within the project. We need new maintainers. We have maintainers that work very hard, but people get busy and they move on to new things. So having new maintainers is fantastic. We need people to handle releases, so that's actually cutting releases, doing security backports, all of those things. These are not things again that require, you know, low-level C++ skills, but they're very important. We need people to work on documentation, just doing fixes and examples and all of those things. And, you know, blogs and all of those other things. So just my general pitch again is that I think there's this perception that Envoy is, you know, very low-level software and you have to be a networking expert to actually help out. That's not true. In fact, there's so much work that has nothing to do with networking. So again, my annual pitch to all of you is that we're always looking for help. I want to thank Tetrate for being our diamond sponsor for today, and thank you very much. So we're going to have a lot of great talks and there'll be time for people to chat and please come find us. So thank you very much.