 Well, yes, I was team Martin Fascio and I am a Spire maintainer and I've been lucky to be part of the project since the beginning, so we will share some project updates. So, let's start by sharing some numbers to have an idea of how the project has been evolving during the last year. So, I will show some numbers since last KubeCon in San Diego. So, we had seven releases that included more than 20 features and around 40 bug fixes and improvements. That were done in more than 230 merchant pairs and all that was done by 36 different contributors. So, it's really nice to see a lot of contributions from the community and see how this is growing and growing over time. This really shows that the project is really healthy. So, let's get right into some of the recent accomplishments done in the project. So, we refactored the Spire server APIs in a set of more resource oriented APIs. We realized that the original APIs that were organized in the node and registration APIs started to show some structural problems in terms of how the APIs were organized. For example, when adding some new functionality, it was difficult to find the right place to add it, maybe simply because it didn't actually fit well in the node or registration APIs. So, after a lot of design work and feedback, they were refactored in different APIs depending on the resource, like agent, bundle, entry or resvit. And we also took the opportunity to improve the consistency across the APIs in terms of things like pagination and filtering of fields. So, one other thing is that a lot of work has been done to update the Spire documentation. So, adding examples and tutorials for the most use cases and critical use cases included, well, Kubernetes, OIDC authentication, a lot of different use cases using Envoy, nested Spire, Federation, the use of telemetry inspire. So, we have now a lot of guides that can help you get started with the most use cases. So, yeah, that is what we just heard from Kersley that he enjoyed looking at the documentation. So, well, back in April, we had the Spire 0.10 release where we completed all the work needed to have support for Jot-SVITs in nested Spire topologies. And the other thing important to mention is that over the past few months, we have been working on improving the client libraries that we have in Go and Java. So, regarding the GhostPV library, we saw that the GhostPV one started to show some signs that it needed an update because it was not as flexible as we wanted. It was missing some key functionality like Federation and Jot-SVIT support. So, earlier this year, we worked on a refresh of the library, we're thinking it from scratch, and we worked on the V2 which provides both low and high level interfaces to handle the common use cases that includes establishing mutually authenticated TLS between work-close that are powered by Spifi. It also makes it easy to obtain and validate both X509 and Jot-SVITs. Well, it also provides all the resources needed to federate trust between trust domains using Spifi bundles. And all the functionality needed to perform things like bundle management, Spifi ID handle, or SVIT verification. So, you can do that now with a tiny amount of code. Also, a lot of work has been done in the Java Spifi library to provide, again, new functionality through new interfaces. And all this has been done in a more modular way that makes it easier to have a more testable library. So, let's take a look at the recent releases of Spire. So, the most recent release is 0111 that we released, I think, at the end of September that included an improvement in the AWS PCA upstream authority plug-in and also the option to disable write limiting of node attestation requests among other improvements and fixes. In 011, we introduced the refactored server APIs that I just talked about. Also, an improvement in the UNIX workload attestor and the Kubernetes workload registrar was extended to support tune modes that are the CRD and the reconcile modes. In 0111, the main new feature was the addition to support VOLTAs and up-tune authority. And in 010, we had a bunch of new things and improvements, including the support for Jot-SVT in the state of Spire, introducing the upstream authority plug-in. There were other improvements like the reduction of database load in certain configurations and the ability of Asians to proactively rotate the workload SVT when there was an update in the registration. So, let's talk a little bit about what is keeping us busy now, what are the things that we're spending time on now. So, for many reasons, we have been kind of deferring 1.0 for some time. There were some reasons for that, like the refactor of the server APIs. We thought that having a well-established set of server APIs in 1.0 would be a good thing rather than releasing 1.0 and then do a big refactor. So, that was one thing. There were other things that are maybe less technical but still important to decide in order to have a clear path towards 1.0 and also after 1.0. Like process decisions including the release cadence, compatibility and how we will manage versioning going forward. So, there have been a lot of things to decide and to work on to be able to finally have 1.0. But at this point we are getting closer to that and we really think that we should be able to have a 1.0 reason. So, there are a lot of proposals being discussed at this moment, which is something right. One of them is a proposal for TPM node attestation that is based on our approach following a draft specification from the trust computing group that leverages the ID certificate to authenticate each device. There is also an ongoing effort to add support for AWS, KMS and Manasya sign-in keys. Since this would be the first key manager plugin that depends on an external service. So, one of the things that are under discussion is the exact behavior on failures including timeouts and retraces strategies. So, that is also being discussed now. And there is a proposal for updating the Inspire data store to have a simple pluggable solution that would be able to support both SQL and key value stores. So, again, a lot of discussion around that. So, Augusting will be a bit short in time, we have about three minutes left, three to four. So, well, there are many, many different scenarios where installing Inspiration is not possible and that obviously is a problem in Inspire where the workload running in those environment can't access the workload API. So, there is a proposal under discussion to address that problem. Right now, it's focused on providing support for the different serverless services provided by the major cloud providers. Like the primary use case, but the idea is to come up with a solution or a set of solutions for the different scenarios that could allow to be able to use Inspire in those environments where you can't install a nation. And then quickly, we had the forced rotation and revocation as pending roadmap item for a while. But now there is a concrete proposal to scope the work needed to provide a quick, reliable and automated mechanism of like recovering from key compromise. So, the proposal defines some steps to accomplish that and also introduces some new APIs in order to achieve that process. So, that's under active discussion now. And there is a proposal to add the certificate, certificate transparency support Inspire through a new plugin type. And this, this is being discussed also. So, let's try to go quickly through this. So we, we already talked about the things that are keeping busy as now but there are some other things that we have in the horizon, like the implementation of the break last mall. It's, it's well known that Spire is a, since it's a critical piece in any production system that relies on Inspire to provide identities on workloads. So, if, if Spire is not able to properly provide new SBits or renew existing ones, that will result in service interruptions. So, a break last mall would be a way to provide makes a mechanism that allows fire to continue providing identities, even in the states where a failure would prevent the Spire from issuing as bits. So there is currently a request for comment issue for that, although we haven't actively discussed that yet. So that's something pending. So the health check system Inspire can be, can be improved. We recently added the back endpoints to get information about the agent and the server, but there is room to improve the current way to, to check the health of Spire server and agent to make it more reliable and complete. We also, one of the things that we have in the remote is to, to review the error messages to have that we have to make sure that they are not only descriptive of the error, but also that helps to have a resolution for the condition. So we have a lot of work to do in order to product unites Kubernetes deployments to adhere to security best practices. And we also plan to look at how does the course by exposed service facilities to plugins and plugins exposed services Spire core can utilize in exchange. In terms of secret less authentication to Google compute platform and Microsoft Azure, we have plans to expand the, the all I OIDC Federation integration support to those platforms. Augustine. Amazon Web Services is already supported correct. That's the reason why it's not in that list. So this is only for future future work. Great. I was seen where a time. Thanks for the update. This, this is a lot. There's certainly a lot of momentum going out for the project very excited fired up to see this slides will be made available and I had a few extra slides but we do need to move on to the to the next section. Is there a place you'd like to call out folks to come check out perhaps the spy repo or where can they find this information you've been talking about. Yeah, I guess that the spy repo and also looking at the roadmap but we have in the in the spire repo. Yeah, and obviously through slag, you can contact me. Fantastic. Thank you very much. Great updates from both the core of spiffy and the core of spire. There's a lot under development, a lot of new directions being contemplated in the future to further enhance the projects.