 It looks like I'm the next one. Let me share my screen. Cool. So I basically want to announce a new project which has reached milestone one and is ready for production use. So this is called the Adobe's decentralized protocol compiler. And I'm going to post the link in a little bit. So this is meant to be universal language for specifying protocols. And by this, I mean that it's universal in the sense that it is both agnostic to the programming language in which different implementations use the protocols, as well as it is independent of the way the protocol is serialized on the wire. So it should be able to support any serialization. So that includes all the IPOD technology that we typically use, all the serializations that IPOD supports, but also any other protocols like protocol buffers, flat buffers, legacy protocols like BitTorrent and exotic protocols, whatever. So the big point here is that the language is meant to have a very simple and flexible type system that can describe any preexisting and future protocols and is also meant to enable writing protocols that are very easily extensible with maintaining forward and backward compatibility. So very briefly, from the front page of the project, you will find all the documentation linked in. The first piece of the information is the roadmap for the project. We have completed milestone one. The roadmap captures essentially quite a lot of the scope that we plan to cover. I will talk a little bit more about the first milestone in a second. So the first milestone essentially is establishing the core type system, which is an extension over type systems that you typically see in protocol compilers like the IPOD schema compiler or protocol buffers. It has a few more types because it is meant to be complete in the sense that it can really describe any protocol that exists or that you might want to write in the future. So it is able to co-generate client servers and coders and decoders for anything you define in the type system. And in particular, it supports defining services and methods and it's completely type safe. So it can generate services that you define. So services, you can think of it as very much like in protocol buffer compiler. It can generate go code for clients and servers. And the generated code is completely static, so no reflection and is zero allocation for the most part. And soon it will be entirely, hopefully, zero allocation. So very, very performant code. So everything is very modular. So the networking stacks that are generated, for instance, for services, you can plug in different backends. Currently, we have a backend which uses DAG JSON over HTTP because this was what we needed for the first client of this project, which is the Delegated Routing Protocol for IPFS and Hydra. But if you scroll later on when you have time, if you scroll down the milestones, you will see some of the future scope of the project. So there will be lots of features that people find necessary, so transformations between different protocols, which is a generalization of the familiar IPOD schema representations, as well as features that are expected to be needed in the Filecoin Actors space, like passing lambdas across network boundaries. So an example application is one blockchain wants to give a callback. So a smart contract wants to provide a callback to a client. And we aim to be able to sort of describe lambdas over a different sort of chain. So different chains might describe lambdas in a different way. And all of this should work quite seamlessly in the language in a uniform way. And you can sort of read about the big picture as you kind of like go through this roadmap document. I will briefly show you the type system that we currently have and just kind of highlight how it's different from IPOD schema or protocol compiler schema. So you will find the standard types that you generally expect, so primitives, as well as classes like any or the nothing type, so composite types like links. Links is, of course, like a special protocol lab type that doesn't exist in other type systems. So these are content links. But at least map structures. There are some new additions which are necessary for sort of forward-looking features. So we have a singleton type, an inductive type, and a union type, which I'm not going to go into details now. You can read it in the documentation. But these are very, very powerful types. Some of them are inspired from the modern type systems coming from languages like Julia and Rust. And of course, there are functional types, service types, and methods. So the documents that are linked in describe how to use them, what their semantics are, how they are represented on the wire. In the repo, you can find a full example of how to define a service. This example is defining like sort of an early version of the delegated routing protocol. So it's a real example, slightly simplified, so it's digestible. At the moment, the compiler doesn't have syntax parsing. So you would have to define your schemas using basically by defining the AST of your type definitions in Go. Soon we're going to have syntax parsing. This is sort of not essential. It's just a matter of time. And so this is just roughly what it looks like to define a complete service and a little bit of Go code that basically tells the compiler to generate Go code for this service. And you can also find in the repo, when you run these codes, you end up with the generated code, which you can also view in the repo. It's pretty large, mostly because it's fully static and quite performant. That's it for me. And I'm going to just send you a link in the chat in case you want to read more and feel free to reach out. If you want to use it, have questions. There is a channel in Discord in the IPFS sort of realm called Adobe's Protocol Compiler. So you can ask questions there or submit issues in the GitHub repo. Cool. Thank you.