 What we're going to do now is just a very quick demo just to look at what Firefly does, what some of these pieces look like in action. And you talked a lot about how these sort of typical organization flow is to have a lot of disparate pieces, maybe a blockchain, maybe some off-chain things that all need to be tied together. And a lot of the work in the enterprise ends up being not actually working on the blockchain, but in tying all these things together. So what Firefly does is provide a very robust framework for gluing all these things together and for allowing you to plug in whatever pieces you may need. The general operations that come into Firefly are called messages and each message may have a number of bits of data attached to it. Firefly is then going to take those messages, batch them together, and the batch may contain one or more messages and data, and then it will pin them with a blockchain transaction so that you know exactly when the event happened. It will hash the data and the hash of this batch is stored on the blockchain, which in this case I've shown as Ethereum, but as we were just discussing could be quarter, could be fabric, could be anything else that you plug in. Then the actual data may be stored locally in the database and may be stored in a private S3 cloud and may be stored in the distributed file system IPFS and basically each of these items ties back to this batch in Firefly. So I'm going to step through all the different components and show you kind of what messages look like, what data looks like, what transactions look like to give you a feel for how this would actually apply to an enterprise data flow. The first piece that anyone would encounter when working with Firefly is the Firefly CLI. This is going to be the easiest way for a developer to get set up building an enterprise application on Firefly. And we'll go through a lot of this in the later panels through the technical overview and the workshop later this morning. But just wanted to give a quick look at what the console looks like. You have a lot of commands that will be familiar to anyone who's used Docker or a similar command line tool for creating Firefly stacks that, you know, encompass all these pieces, it's starting them removing them, all that. And then I have a stack running here. That's actually just a set of doctors that represents a three party system. And I will show you first the Firefly UI. So the different components I was talking about messages data transactions, I've run a few items through it here and I'm going to run a few more to show you how it changes, but it comes out of the box with a full console for exploring all these things and seeing what each member has received. So I've set up a three party system here I have one UI from number one. I have a different UI from number two. And I can step through all the different elements of the Firefly data model. And it also comes with a fully self documenting API courtesy of open API and swagger. So each node will kind of expose all these APIs and I'll walk through a few of them in a second. So those are kind of the core pieces I suppose the CLI, the UI, the API documentation. And then we also have a set of sample applications, which I'm going to use to demo actually how this works. So this is a sample application that is just a very, very simple private data exchange right this is the classic enterprise use case where you have three organizations in this case. They want to share data, but some of the data may need to be broadcast to all the members. Some of the data may need to be between only two of the members or some other combination. And this application is just a very simple demonstration of what that looks like on Firefly. So I'm going to start with a broadcast message. I'm sending this from the first member but every member is going to get it and I can actually show both of these at the same time I think so you can see both members. So I'll switch this to look from another member's perspective. If I send a broadcast message. It's going to go out it's going to be batched it's going to be hashed and the hash is going to be pinned to the blockchain. And then you see it was received over here on number one as well I switched to number two. So number zero number one number two all got this hello everyone message. Now it looks very simple at the surface level but I want to take a little bit of a dive to all the things that just happened underneath the covers. So I mentioned that we have the data first of all gets packed into a batch. We can look at the API to see a new batch that was created. It's probably easier to see on the Firefly UI as well. The message here was broadcast message. And then this broadcast message is also going to be tied to a transaction. This transaction actually gets pinned to the blockchain. And I can show also in the. For this local stack. So we have a local Ethereum blockchain, you can see a transaction just went through to pin that so that we know exactly when the data was stored. And then this transaction is linked back to the actual message here. And in the UI, I can see the data that was attached to that message. I can also do a directed message and choose only one or two recipients to receive my message. So for this one, I will say hello to org one. And or one is going to receive it, but work to cannot see it. And of course, all the same things happened here. We have a blockchain transaction that happened on ganache and stored a hash of the data on the blockchain. I can also show. I talked about how each operation we have plugins for different blockchains for different external storage. So all the operations that happened behind the scenes in Firefly for this we had an Ethereum transaction. We had an IPFS transaction for the public events. We have just simple HTTPS broadcasts for the for the private events. But I can see here now on on the member that sent the data. It's, we have a timeline view of all the data that's been sent from this first member. This was the broadcast that I sent. And this was the private message. And if I go to the same timeline on member one, I can see the items that were received. And of course, I can see the ones that were received by member two as well. So going back to kind of show the architectural we have, we have a message that may come in as a broadcast or a private message. It gets batched in. We have all these different plugins. And in this case, as we mentioned a few times we're using IPFS for the public data. So anything that's a broadcast message that's accessible to everyone is going to go through the IPFS plugin and that data will then be distributed through the peer to peer file system so anyone can access it. Anything that is private data will simply be stored internally in the database and will be only shared with the members that it was directed to. So the first single one of these items is paired with a blockchain transaction. In this case on Ethereum that tells you exactly a hash of the data so you can pair the data to that transaction and tells you the ordering of it. And you have an immutable history. So you can pair those off chain events with this on chain events. That's about it for the quick demo. We're going to dive much deeper in a few minutes for showing exactly what the stack looks like. We're going to do a workshop a little bit later to kind of walk through this, show you the CLI, the UI and more depth and really dive into how these things work together. But I suppose at this point Sophia, I can try to back over to you. Yeah, Andrew. Well one thing thanks for the great demo. I was wondering since we have a couple minutes if you had the code handy just to flash up. So, you know, I think it might be really interesting for the developers on the call to realize how little code is involved with being able to do everything you just demonstrated. Yeah. So we do have this firefly samples repository. And this is a great, great resource for kind of starting to figure out how these pieces fit together and how you can actually use them. The one I was demoing here is what we've called private data transfer UI. And like you said, it's a very small amount of code and that's kind of the whole goal for this project. We have a very simple sort of rest API wrapper here. This project's written in Node.js and TypeScript. But all we're doing is hitting these firefly APIs that I also kind of flashed with this documented swagger API. But the actual UI code for the application here is very, very simple. It's in React and it's just a couple of components. You connect a web socket to receive the incoming messages and then you perform some of these rest API calls when we send a private message or send a broadcast. You can direct it to whichever recipients you want. You can send a broadcast to all of them and then you get data back on the web socket to know when your message is confirmed on the blockchain, et cetera, et cetera. So yeah, it's really a very, very small amount of code in this repository to write an application that touches a half dozen different services both on-chain and off-chain and kind of integrates it all together.