 Great. Thank you very much, Char. So I think I'm going to kick things off. I'm just going to give a quick agenda of kind of what we wanted to go through. I'm just going to give a very brief, very brief overview of what Firefly is, what the project is, how it's used, and kind of the brief snapshot of the roadmap of what we're working on currently. And then that will kind of segue into Peter talking about how identity works in within Firefly, and then hopefully from there we could kind of open it up and have discussion about it. So, my, my other disclaimer is that before about a couple hours ago this morning I didn't realize this was going to be a presentation. I think it was more of a conversation so, so that there's my disclaimer. I'm going to go ahead and share my screen, because I do have some slides to go through here, and we'll jump right in. So, just kind of want to give folks if you're not familiar with the Firefly project. Like I said, a very brief overview of what it is. I could talk for a really long time about this, but I'm going to try to keep this short. So, we describe Hyperledger Firefly as a super node. And it, we described that as a complete stack for enterprises to build and scale secure web three applications. So, what does that mean what that means. Firefly is not a DLT. It sits a layer above the blockchain, and it is a platform that you can build web three blockchain powered apps on top of. So, what, what does that give you as as a developer what's the benefit. When you look at the landscape of open source projects, there's a lot of projects down kind of at the at this low level of of blockchains, DLTs, all these, you know, tools for for doing stuff on the blockchain. That's great. There's, there's lots of, you know, there's, there may be lots of stuff at the top layer to you know where you have your user interface and there's there's lots of great open source frameworks for flashy cool web apps but if you want to build an enterprise web three application there's all kinds of things that sit in between those layers that you have to build. And one of the things as Peter was saying this is out of the journey of Kaleido at Kaleido as we built more and more web three applications we realized that hey that all these applications need it the same or very similar set of plumbing and pipes and connections to different things and messaging buses and event management and all this stuff that sort of sits in between these layers that lets you build a really robust enterprise web three app that can scale and is secure and it is ready for enterprise production. So that's that's what hyperledger firefly does it's it's meant to fill this gap to give you a common platform with a an easy concise set of apis that you can build an application on. So so it sits like I said a layer above the blockchain itself. And let's the developer focus on the thing that's really of ultimate value to their business which is solving their business problem. So the developers can focus on the logic of their of their business app. And they don't have to spend time thinking about, well, how do I actually get data from this, this one piece of our network architecture over here over here, Firefly handles all those things has connections for all those things. So, what's in the box. So think about Firefly in kind of providing three major categories of things that allow you to build apps flows and digital assets and I'll kind of break down what each of these are in just a minute. So that those are like the main sets of things that it lets you do and build those are powered by the Firefly core Firefly core is has an orchestration engine in it. That is sort of the the brain and the connector and the the organizer for for all of these different systems that it's connecting and what are all those systems well there's there's obviously a blockchain node. There is a shared storage service, there is a private data bus for privately exchanging data. Firefly core has its own database where it's keeping track of state of the network of things on the chain, and also its own internal state as well. So this, of course, is done with security, this is enterprise ready so there's, you know, there's security running through all these layers. There's also a really robust set of tools kind of have on the chart over here. There's a an SDK for Node.js. It's written in TypeScript so has great type definitions. There are more SDKs coming. That's the one that we have today readily available on npmjs.com. There is a command line interface that can be used to create a local development environment on your machine that will start all this stuff up and let's you play with it with just a few commands. And obviously there's there's a fantastic API for for all of this stuff. There's a web UI, the Explorer. I forgot to mention here at the top. The Explorer is a fantastic user interface that lets you see what's going on inside Firefly. And all of this is designed in a cloud native modern distributed architecture in mind. So it's meant to run in Kubernetes. It has Prometheus monitoring built right in. And, and, and it's great. So let's kind of break down kind of these apps flows and digital assets and describe a little bit more in detail what we mean on each of those. So, one of the really cool features that Firefly has is that it will let you build HTTP APIs from smart contracts so you can import a custom smart contract. If it's Ethereum, you could provide an Ethereum API and Firefly will generate on the fly an API for it so it lets you sort of rapidly build integrations and applications it also stores information about the about that the API on the chain and could broadcast that to other parties as well so you can inform other parties about a certain contract that's on chain and there's some really cool features there, including the ability to subscribe to events being emitted by those contracts to index those events and be able to query them and get state out of the contract as well all through Firefly's API. Firefly is one of the main use cases for it and this is a use case that is is growing there's a lot of functionality being built into it right now is to use it as a Web three gateway. What do we mean by that so, for example, if an enterprise has they want to build a an app power by blockchain, but they need to have a control point or a one point in their IT infrastructure that is can communicate with a public chain for instance communicate outside the business network that needs to be in a very specific area of the network Firefly can can fill that role so Firefly becomes the gateway to the Web three world in the same way that an internet gateway is a mechanism for applications inside a network to reach out to systems outside of the private business network Firefly can act in the same role for the Web three world. And this can go both ways as well so everything coming to and from the blockchain goes through Firefly and to a web three app. So this provides a lot of power for businesses. One of the other use cases, or, or sort of usage patterns I should say it's it's much broader than than a specific use case but we describe as a usage pattern is for consortiums or multi party networks as we refer to them as sometimes. So, and this was this was really like one of the very first usage patterns that was built out robustly in Firefly. So, a lot of the demos that you if you've seen the demo already a Firefly it was probably the consortium multi party usage pattern demo, where you have multiple organizations that are interacting with each other through the blockchain. They're broadcasting data throughout the whole organization hashing it pinning it to the blockchain. Maybe they're privately sharing more sensitive pieces of data directly between members, and they can perform transactions with with custom smart contracts as well. And so Firefly allows these consortiums of businesses to build a network powered by blockchain to perform business transactions with each other, all through the chain. Okay, and that that third box was digital assets so Firefly also comes out of the box with really robust APIs for tokens, which are one of the fundamental building blocks of a web three app of a blockchain app. Tokens could be fungible or non fungible there are our patterns for both in Firefly. And it is, it doesn't actually matter which specific token contract to use it could be a vanilla off the shelf open zeppelin ERC contract, whether that's ERC 20 ERC 721. It could be a completely custom token contract, and as long as it implements the ability to mint transfer and burn tokens, it, and Firefly also has the ability for token approvals as well. There are first class API is built right into Firefly, there's a fantastic dashboard that lets you inspect everything. This is a little screenshot of the the Firefly Explorer the Firefly UI that shows kind of what's going on inside this particular token pool, but there's great support for tokens right out of the box makes it super convenient. We've had a lot of people come to the project and try it out, just so that they can actually learn about tokens because Firefly provides just a really easy on ramp to get up and started running a system being able to to mint some tokens transfer them play around with an external wallet and just understand how different token contracts works and it's been really great. Okay, I'm going to go through these next couple slides. Maybe a little quicker, but one of the just briefly touch on the Firefly core and so the Firefly core is it's important, especially to the next part of the conversation as well when we start talking about identity so Firefly core is, we have, there's a picture of a brain in the middle of this diagram because we often refer to it as the brain of the system, and it's sort of the, it has inside it an orchestration engine that is in charge of making sure events are delivered in the correct order based on the ordering set by the blockchain so that the ordering is established by the chain. But then Firefly in the orchestration engine needs to make sure that everything stays in that order as the, the events are presented to the application, as things are put in the database, and it handles, it handles a lot of the heavy lifting of the grunt work of what an application or would normally need to build into their application to have a reliable, you know, stateless web three app and the Firefly core orchestration engine takes a lot of that for them. So it's coordinating between things that are on chain data that's being pinned to the chain or tokens or events that are coming off the chain. And it's also coordinating that with with off chain data as well, whether that's documents that are stored in IPFS, whether that's private messages that are sent directly from node to node, and all kinds of things like that. And I've touched on a couple of different places that the Firefly stores data. It has a, like I've said it has a database that Firefly stores network and chain state in. It also works with a shared storage system right now that the implementation for that out of the box is IPFS, and it also has a private data exchange as well. Firefly has, like I said, a lot of tools with it. Here's another screenshot of the explorer from the dashboard, touched on quite a few of these already the CLI API in the SDK so won't belabor the point but it has a lot of tools and they're really great. They make using it easy. And I think an enjoyable experience for developers. It's all like I said cloud ready modern distributed architecture design. One of the other really cool things about it and it will talk more about plugins here and just a little bit is that it's one of the points I haven't touched on is that it's a very pluggable architecture. Not only is Firefly itself distributed into many microservices. The the orchestration engine has a really robust plugin system that allows the implementation for any of those services to be swapped out so if if you're the out of the box implementation of shared storage is IPFS. But if you have a specific need to use a different shared storage mechanism, maybe it's, you know, Amazon S3 or some other, maybe it's some on premise data storage system that can easily be swapped out via a plugin to the Firefly core to talk to a completely different storage service that sits outside of Firefly core. So it's both a microservice architecture and it's also a very pluggable architecture as well. So a quick comment on kind of the roadmap of what we're working on, and then we'll segue into the work on identity kind of we're working a lot right now on enhanced support for public blockchains, as well as multiple ledgers and blockchain connectors at the same time, and in different usage patterns at the same time so I talked about kind of the gateway and the multi party usage patterns, allowing Firefly to to operate in both of those modes at the same time. In different namespaces with different sets of plugins. And so, so all three of these active development bullet points are very much related so I also commented on that you know there's there's a lot of work going in right now to enhancing Firefly's Web3 gateway capabilities and giving operators more control more granularity of how their, their, their Firefly node interacts with the rest of the blockchain world. Coming up soon, we're working on more samples, more SDKs, and it looks like I had a duplicated bullet point the Web3 gateway was supposed to be on the left side, sorry about that. Also, pluggable API security and pluggable identity management are coming up very soon. And so those are those are things that people are really excited about as well. And so speaking of pluggable identity management, I will end my my little slide where talk here now and I will turn it over to Peter to talk about that topic. That's, that's great. Thanks Nico so let me let me just share my screen. And just to give you a feeling for what Firefly is first hand. So if you stand up Firefly, and I do encourage you to have a look at some of the recent demos and we can send some, some of those, those through afterwards. Maybe what you get in about five minutes when you choose fabric or a private Ethereum chain or maybe even connecting to a remote public chain, you'll, you'll get a stack on your, on your laptop which is running everything you need. It's running all of the Firefly components, which is a micro service architecture part of making it pluggable is allowing different components to be different languages. It's running a bunch, bunch of different, different containers for you, including the blockchain IPFS. Like I say, you can, you can pick your pick your blockchain there and also a bunch of tooling. So you get a sandbox, which is sort of an exercise for blockchain constructs. So being able to play with tokens, create or launch your own phone, your own token on your, on your laptop transfer mints, mints and burn tokens, interact with smart contracts of any description on the blockchain itself so you've got some custom fabric chain code you've got a custom to see smart contract being able to generate a rest API for that and interact with it. And, and also Firefly helps you coordinate together the off chain pipes that exist pretty universally across enterprise deployments of a business use case on blockchain, whether they're well organized between the, between the parties as part of a sort of multi party application that everybody's running a copy of, and sort of the off chain pipes are standardized between everybody who's building in that solution, or whether it's much more ad hoc. The reality is that blockchain isn't great for sensitive data, going directly on the chain so you need to coordinate off chain transfer with on chain so that pattern again it's all built into into Firefly. And you'll also find you get an explorer, which, as Nico showed a little bit, gives you a bit of a view into into the system so I suppose that what you've done on on your, on your note that you drill into all the different things that Firefly can do. Obviously, if you are going to be doing things like off chain coordinated transfer of data between different organizations. What that means is you need to know who you're exchanging data with it's just, I don't need to tell this group that that's a reality of life in the blockchain space that a head string and a period address is not great for business to know who they're working with. So, so far fly does come out of the box. When you're using it in the multi party system mode, where you're assuming everybody else is running a fly nothing that's an important point because our flies and technology does not make that to say that assumption that does provide that as an option for you. So just with a sort of built in network map a system of identity just out of the box inside of inside of Firefly. So, just before we started talking I sent, I sent a message that came from another party in the system they need to see who it came from. Then I actually get to see the, the identity that came that that message came in on. So if I open up the message here. We'll see that we represent identity in fire fly using the DAD syntax. And I want to put it that way because we far flies itself, just like with every blockchain technology, not trying to be the full implementation of core blockchain constructs. Firefly is not a DLT. It lets you plug into fabric, Ethereum, even as called a call to support there, connect to all of those remote blockchains that you might be connecting to even things as varied as Bitcoin are connected are you know, fit into the pattern of firefly off chain pipes or maybe you're using, you know, just the open source mutual TLS connectivity peer to peer, maybe you're using a queuing technology like rather than queue or Nats or, or Kafka, or JMS provider but all of that can can plug in. And that was the reason for choosing DID to be the way that we represent an identity of something that you've received. In this particular case, piece of broadcast data that was pinned to the blockchain with the blockchains has action at the hash. All sensible solutions, the data itself didn't go on to the blockchain itself. In this case, the broadcast went into IPFS, but my firefly node is telling me it's done verification, but it's from this author. And what does that actually mean? Well, in this case, it's using the built-in identity system of the Modify system of firefly. And that is the only option today. I think that's a really interesting thing to get to in a minute or so when we sort of have the discussion at the built-in identity system. And so there's a, you know, a DID resolver that we just picked of firefly to say that this is the built-in resolver inside of firefly itself. And if you go to the network map, you'll see that there are these sort of constructs like organizations, nodes, and custom identities, which I don't have any of, which are a simple built-in with a sort of profile way of advertising your identity within the network, which is backed by performing a simple verification using a key. And I don't have an example of it here, but if there was a charlotte identity, like I created a custom identity, but it wouldn't just be the identity you would have had to be the key that you're using yourself to prove that you have ownership of. There would also be a verification by whoever you're saying is the next identity of the tree. So a very simple system, you know, a lot like a PKI system where there are some root identities in the system that are trusted because they just established themselves through sort of a gatekeeper construct, they came on board, and then a claim of verification system to generate multiple identities where you need one transaction on the blockchain from the parent to say they attest to your claim, and you need to claim it yourself and, you know, a pretty simple solution. What really makes this sort of interesting is with a fully pluggable architecture, why not have other resolvers, right? Why not have Firefly in much more sort of in that gateway mode where you're just connecting to ecosystems that exist, where some of the members are getting the acceleration of using a stack of technology like Firefly, other than members, you know, maybe built everything from scratch and really want to use the lowest level technologies. I'm being able to join that community and participate in it using sort of middleware stack that makes it much easier for you to connect to applications and core systems to us. Well, that would mean you'd need to work with whatever the identity system is of that group of participants. So that's why we chose DID. We're not choosing DID because we want to be a self-sovereign identity provider. We're not choosing DID because we want to be an accelerator for solutions, regardless of what technology choices they've made in the blockchain space. So that means that projects where there is a self-sovereign identity system or other identity system involved that's backed by DID, they're going to plug that in and say, don't resolve this inside of Firefly with the multi-party system built in thing. Resolve this using the plugin. And the plugin doesn't need to be, you know, just because maybe Firefly Core is Go, doesn't need to be rewritten in Go. That can be any existing system. If it's got APIs, if it conforms to the standard, it can be plugged in. So I talked quite a bit there, but I really wanted to give that flavor of sort of what it is, but also what it isn't for this community, because I didn't want to give any impression that what we've tried to do is, you know, that there's, I think there's a great synergy with projects like Ares and Indy and software, not a contention with them. This is about an accelerator that helps particularly focus on enterprise projects go faster in Web3. It's not seeking to replace any of the technologies, whether that's the BLT layer or technologies like IPFS and quite a bit of transfer and self-sovereign identity systems.