So, okay, I'm going to use the set of slides. The way to get started with Firefly is using its command line interface. One can spin up a local development environment in seconds and immediately start building an application against it. We'll cover the command line interface in detail during the workshop. What I wanted to cover in this course part is how the architecture looks like when running Firefly locally. That way, when we use the command line interface, we know exactly what's taking place under the covers. We're going to use two members. On the left, we have member zero. And on the right, we have member one. Now, since we're going to be doing local development, we're going to have the members, both members, running side by side on the same laptop. That way, we can build and test complete end-to-end flows. Each member will have its own Firefly core running. And also, each of these Firefly cores will have its own database. The blockchain component is used to run transactions on the blockchain and also to listen to events from the blockchain. What we have in between the two is the actual blockchain. Then we have another component that is called public storage. So this is used to share public data in between the members. Now, a quick clarification when I say public is always within the domain of these members. Now, the public storage uses peer-to-peer communication. So that means that these components can talk directly to each other from one member to another. The private data exchange component is used to send and receive private data in between the members. Just like with public storage, it uses peer-to-peer communications, which means that they can talk to each other across members. Finally, we have the client application. This is where their development will be focused on. Not that Firefly will orchestrate all of their own chain and off-chain logic and storage. The application simply has to be written against a very simple RESTful AP, like the Firefly. When running Firefly locally, the command line interface will spin up a number of other containers. These containers will have each of these items that we just listed now. Specifically, for the case of the blockchain, what we're going to get is a traffic ganache. For the blockchain interface, we are going to have ifConnect. All of these projects are available in the repositories for more information. Now, for the public storage, we use the interplanetary file system, or IPFS, and mutual TLS data communications is used for the private data exchange. Finally, Postgres is used for the database. Okay, so that was a very quick summary of how the architecture looks like when running Firefly locally using the CLI. So I'm looking forward to seeing the rest of the examples. We'll see if that's too unique. Cool, thanks Gabriel. Is it possible for me to share my screen? Great. Okay, so great to meet everybody. I hope everyone can see my screen. Okay, please tell me if it's doing anything funny. My name's Nick. Okay, super, thanks, Sophia. Yeah, my name is Nick Gasky. I was involved very heavily with Hyperledger Fabric Project many years ago, and really excited to work with the broader community on all things Firefly. So I'll be one of your main points of contact, and weekly or bi-weekly dev meetings in Rocket Chat and separate one-on-one Zoom meetings. So we really welcome everyone to the community, and really excited to have everyone on this really exciting technology. So this is the hands-on workshop. We're gonna actually install this stuff on our machines. We're gonna run some code. We're gonna look at those core interfaces that Gabriel just talked about, our Ethereum shim, the public storage IPFS, the TLS-secured private data exchanges, the Firefly core, and all of this functionality that's encapsulated and abstracted into a really simple REST API. We'll show you some running user interfaces and applications, and you'll get a sense of how easy this is to use and how extensible and how powerful it is. So the first thing I wanna draw your attention to, and I posted this in the chat, but I'm gonna post it one more time just so that everybody has this, is this getting started on Firefly cheat sheet that we have right here. Go back to the chat and just make sure everyone has this link. So again, I'd like everyone to please visit this and start taking a look at all of the different dependencies that we need. As Gabriel mentioned, the first thing, kind of the beating heart that's gonna make your life easy using Firefly and interacting with these different interfaces is the command line interface. It's a powerful, powerful stack of functionality, and it just takes a couple commands to stand up a full Firefly stack and then to actually start exercising some of the available methods and commands inside of Firefly. So this is the first thing that we're gonna need everyone to do is actually follow along with this section right here, the references and dependencies and the overall Firefly CLI section. So two non-negotiable dependencies that you have to have in order to get this CLI cooking on your machine. The first is Go. It will work with older versions of Go, but we do highly recommend kind of the more cutting-edge LTS version version of Go, 16.5. The other thing that you need, which I have to imagine 99% of folks have is Docker and all of you probably have Go as well. So I'm gonna sort of drag my feet for a couple of minutes and let any folks that don't have this installed go ahead and sort of start doing that in the background. And I'll also mention, as we're doing this, this is meant to be as interactive as possible. So oftentimes, things go wrong. We're trying to compile and build stuff locally. There may be just ambiguity in your own point of view. So this is the greatest session for you to raise your hand, speak out loud, throw any questions in the chat. If you're completely lost and completely broken or you really would rather have a business conversation or something, let us know in the chat. We have a lot of folks here inside of the room and that are hands-on deck with Kaleido and with Firefly. And we're more than happy to talk to you in sort of one-off or private settings or to answer your questions inside of the chat. So just want everyone to feel as comfortable as possible. There are no such things as bad questions and nascent open source projects or in technology in general. So don't be shy. We're friendly. We're here to help. And we really would love to get to know everyone and interact with you as well.  Okay, so I'm going to start showing you guys how this is going to work sort of in real time, the things that you're going to be able to do. The first thing we'll do is we'll actually check, right? We're going to check and make sure that we have Firefly installed. This command right here, the go install or the go get, this should have only taken about a minute on your machine right there. So I'm assuming that all the folks that had go and all the folks that had Docker have already gone ahead and issued this command and hopefully you have an executable FF command that's available on your machine. If you have that, you're going to see something like this. So this is going to show you the available commands and the available flags right here. What we really care about is just kind of three core commands inside of Firefly. We care about this init, which is going to be kind of a high level wrapper about the configuration of our stack. Namely, we're going to give it a name and we're going to give it the number of members that we want inside of our Firefly ecosystem. We're going to do this with three because obviously if we're just using two members and we're doing these bilateral transactions with two members, you could argue that they're private, but they're not private from anyone else inside of the system. So what we're going to do is we're going to stand up a Firefly stack with three members. We'll look at broadcast transactions where everyone gets the data and then we'll look at some of those private transactions where instead of using IPFS, we're using that TLS sort of peer-to-peer protocol right there to directly send messages to individually enumerated participants. So init is essentially just the config of your stack right there. Start is kind of the more exciting command. This is going to bring down all of those core Docker images onto your machine. This will give you the Ethereum adapter. This will give you the Firefly core. This will give you that Gnash CLI for local, lightweight, super fast blockchain development. And it'll also start up those corresponding containers as well and provide you with some local host endpoints where you can see a user interface for convenient interaction and inspection as well as an embedded swagger API.  And then the last one that we see here is stop. So this will just stop the containers. And if you want to start from scratch, you can use Firefly Remove. So those are kind of going to be your babies right here for step one, but you'll get very familiar with in the shorthand. So I'm going to pause there. I'm just going to check the chat intermittently and make sure there's not too many questions going on here. I see Nico's doing a great job helping folks with sort of if you're running on Windows or you need to stand up a VM or you're running on Linux. So thanks for that, Nico. And then you have Peter and Andrew and all of our subject matter expertise. So it looks like chat is the greatest way to put your questions in. Okay, so without further ado, let's go ahead and stand some of this stuff up. So feel free to participate alongside with me or you know, this is a recorded demo. So you can just follow along. You can watch this and then you can use the recording, you know, as a guiding artifact if you want to do this after the fact. Okay, so let me give myself a little more space and I'm going to go ahead and create a stack called data transfer. So now it's going to ask me for the number of members. Of course you can choose two members if you just want to get started and you just want to see the core flows. I'm going to go ahead and choose three again. Could you zoom your command line windows? Yeah, yeah, of course. Sorry about that. Thanks, Nick. Are we getting closer? Is that a little better? Yeah, that certainly looks better to me. Hopefully for Anna as well. Super. Okay, yeah. Apologies to folks. I'm going to throw it in the chat and Peter or someone will yell at me and we'll make it even bigger. Okay, so again, this is just the wrapper for my Firefly stack. This is the config. I gave it a name of data transfer and we're going to do three members right here. So cool, we're happy. We can see the composed file right there telling me where it is. And now it's telling me that if I want to start this stack, I just say FF start data transfer. So again, I'm going to steal some more room. Remember, this is going to take some time. This is going to go ahead and download those Docker images. This is going to stand up your local ganache interface. This is going to instantiate a smart contract. It's going to do a lot of things, but what it's doing is it's giving you that core component architecture. It's giving you all the goodies that are inside of a Firefly stack and inside of a Firefly node. So we'll be able to see approximately how long this takes on my machine. If I have to give you my best educated guess, I'd say about a minute right here. But this CLI, which was written by Nico, who's on the chat, it's very interactive. It's very informative and it's going to let you know sort of what's happening as these containers come to life, as a smart contract is instantiated, for example, as new organizations and new members are onboarded into the system. You'll get all of those notifications. So at the moment, it's just pulling the Docker images for me. But now we can start seeing some more interesting information manifesting inside of the terminal. And again, I'll reiterate it probably 10 or 20 times, but just please, please, please, please don't hesitate to throw any questions inside of this chat. You can feel free to use our Rocket Chat. We're just at Firefly-Labs on Rocket Chat. We're doing a better job as a team of getting very interactive on that and putting all of the discourse about the Firefly project, about any errors that we see internally, any developmental progress, all of that's going to reside fully transparently inside of the Rocket Chat, inside of Firefly Labs. So love for anyone and everyone to please join that and interact with us through that medium. It's a little bit of a blast from the past for me. I spent a ton of time on there interacting with sort of the fabric folks. So maybe I need to close one of my terminals. Okay, let's go ahead and try this again. FF start at a transfer. So what we should see if this comes up properly is it should expose us, you know, all of the local host endpoints where we can get to that user interface. And again, you know, this, we would love for this to be perfect. This is a live demo. I'm shameless about doing live demos.  So, you know, this may be not go 100%, but, you know, we will do this in real time with you and this will be sort of a symbiotic relationship as we're looking at, you know, all of the different permutations and all of the different edge cases that could occur. So we see, you know, a little bit of sort of a possibility for an error. If you do see that as you're starting up a stack, you can always just do FF stop, you know, stack name FF start where you can take the approach that I just did. Just say FF start again with your stack name. If you have those images, if you have those containers and, you know, all of them are running, you're going to get success. It may be the case that perhaps, you know, maybe one container started and it exited, right? And that's not going to serve, you know, all of these end points. Before I think, Nick, as you hit this, I think you actually hit an issue which was fixed and we try a loop that got popped in this morning. So hopefully the latest release won't hit that issue. Just for background to chat while people are all typing on their machines here. What's sort of happening under the covers here is we've we've embedded Docker compose inside of the command line. And then in the CLI, Nico led the development of this, who's here with me in the room. The CLI does a whole bunch of orchestration on top of that. For example, you're going to have addresses that need to be generated. So it generates addresses and it injects those into the configurations. When you do fire flight in it, it lays out a file type system inside of a .firefire directory in your home directory. And underneath that, you'll find all the configuration files, the YAML for the core, the YAML for the data exchange, the key files and stuff generated for Gnash, et cetera, all of those inside of there. And then it starts everything up. And you can imagine there's a sequence here. It's like a launch sequence. You've got the database has to come up and be there. And the blockchain has to come up and be there. And the smart contract that's backing the private data exchange, a very simple example, but kind of like that foundational piece that needs to be installed. So that all happened and next environment. And it all stood back up again. And then it has to restart the firefire runtime so that they'll register their event streams using eave connect that will then listen. All this happens under the covers to reliably for events. And then the final stage is the network map. Each of those nodes has come up. It hasn't really joined the network yet. It actually needs to advertise itself to the rest of the network. And actually, the area you saw on the screen was that the CLI was trying to do that while one of the fireflies was still coming up. And it got a, oh, this firefly isn't actually running when you're trying to do it. So you shouldn't see that because it will get retried into the covers. But that's the sequence of steps that's happening under the covers as part of the CLI. And it was really important for us when we were thinking about this to try and, you know, it's a journey, but try and make it so that you don't have to understand every single one of the components inside out to be able to get up and running. And lots of developers can just focus on the sort of, the externals of firefly, which is the internals of the application, right? The development of their full stack app. So anyway, sorry, Nick, for the diversion now. No problem. And I'm going to actually restart it so that we can ensure that all three members are successfully joined to the network in the member map. So what we want to see inside of the UI is we actually want to see three network members inside of here. So I'm going to go ahead and restart this stack right here. And hopefully we'll get a happy result. I said stop. We want to say FF start. Yeah, you may need to remove it. I'm not sure if it'll, or you can manually register the board. I think just FF will move. Or as Andrew said, you could just go to the, if you just go to the swagger, let's, let's do this, Nick. Let's keep your hands tamed with a little bit of a dance here.  I stopped it. Okay, we'll start it back up again. Let's go ahead and start it. And this is good. This is the sort of, you know, the, the, the command lines there to give you an environment that you can, you can kick the tires with. So this is nice to like do a little bit of tire kicking life. So the, unless I mean, I'll probably waffle on a little bit about the API. Well, we're looking at it because what you'll see on the API is there's a lot more gaps than posts. There's a lot more things you can look at the, the sort of paddling feet of the swan, you can see every single one of those, but actually as a developer, you don't need to use, you don't need to actually perform all of those, but the UI is able to show you transactions, events, data, operations, all of the, all of the model. So if you've got 5001 API up, Nick, if you scroll down to network, the slash network prefix down in namespaces, they were going network, right at the bottom there. So, so you've got underneath network, there are nodes and there are organizations and you're running a node and, and nodes are owned by organizations, which is just a fundamental identity in the system. So in order to kind of exist to everybody else, you have to advertise yourself to everybody else. Well, what's an advertisement? Well, it's just a broadcast. So the system eats its own, eats its own dog food here and uses the broadcast mechanism in order to distribute the, the, the information to everybody.  What this is a convenience to say, look, you know who you are, just broadcast yourself to the network. And that payload there, that's a message. It's the same payload that you get back if you were to send a message that was like an application level message. But in this case, it's a message that's gone out on the Firefly system, namespace. Namespaces, we, we thought it was really important to think about multi-tenancy from day zero because most of these business networks are thinking about like an app store of lots of different applications. So being able to have lots of different applications on the system from day one was important. It's a Firefly system namespace. So this particular message is a broadcast message that happened on the Firefly system message to say, system namespace to say, hey, look, there's an organization. And, and then if you go to a query on organizations, you do the get there, Nick, on slash network slash organizations, you do try it, send, scroll past all of the filtering options that you'd expect on a nice West API. And we should see that, oh, there we go. There must have been something else that's, that's the, all right, new organization. But this is the, this is, this is what you'd see an organization that's propagated through the network. So if you look on your environments where the CLI run all the way through completion, it looks like it may not have configured some of the connectivity here. The, the, you should see an organization for each member. And if you were to click into the UI and change the namespace in the top right hand column to Firefly system, and then click on messages and click on the timeline, you'd see the publishing of all of those, all of those, those organizations going through the system as broadcast, just like anything, anything else would be. All right, I'm going to start over one more time. We tried, I tried this before we got in the workshop. So I know it works. So I'm just going to start from scratch.  If I fail in this session, we'll just turn it over to Andrew or Nico for the last 20 minutes. But again, we've seen this, we've seen this working successfully.  So we'll try this one more time on my machine. If I have bad luck today, we'll just use one of the other Kaleido and Firefly engineers to take you guys sort of to the finish line here. So I'll go ahead and remove that stack. Yes, I do want to remove it. And we'll go ahead and start from scratch where everyone else likely is. So let's say FF in it. We'll call it Nick test this time for good luck. So, and we'll say three for the number of members. This is also a shorthand you can do rather than, you know, using the interactive terminal right there. So, and then we'll say FF start. Yep. I wonder, do you, do you want me just maybe do a little bit of a tour of my, my UI, some of the stuff I was talking about earlier. Yeah, that sounds awesome Peter. Let me share my screen here. So this was one where I just ran, it was a two member environment, but I ran just immediately before we started this morning. And I've got the little sample running, but what I was talking about there is if, if the top right hand corner here, you change from the defaults namespace and you can create namespaces yourself as well. And you just change to the far fly system namespace. And this is my favorite view in the UI here. This is a view of messages in a timeline. And the thing on the left, this is your organization. This is stuff that you've published the network with the organization of the node that you're, that you're in. And then this is stuff in, this is all in reverse timeline order that newest at the top that's come in from other people in the network. So I'm there as a port 5000. That's as node, the first node. I can see that I broadcast a definition of a, an organization to the network. I had a blockchain identity. It gets allocated a UID within the firefight system and it has a short name, which is required to be unique. But it's a few, few cases where we found it really is important for these networks to do some things and choose to have some things and having just a unique name for orgs is something that's been really, really popular in the, in the networks that we've seen evolving. So you have a short name, but really what matters is the identity of that organization. And then you've got a node that gets defined and this is interesting, right? Because the node is, it's not an identity in its own right. So it has an owner, which is owned by that identity and it has an ID as well. But the reason why the node needs to be broadcast to everybody in addition to the, the organization is because of course we're not just communicating via the blockchain. So there's this DX section. Now the DX section is an example of plugability in the system. This is really important. So you're using a implementation of a data exchange, which is mutual TLS with HTTPS. And that implementation through its plug-in has specified this is the API where you can ask me who I am and get data from me that you can broadcast to everyone else in the network so that they can connect to. So on this node one, when the Firefly Core asked the data exchange, the mutual TLS data exchange came back and said, based on the certificates, I've looked inside of them, the organization name inside of my certificate is member zero. My certificates, because we're just using a completely peer-to-peer system here, there's actually lots of options inside of the mutual TLS data exchange, but at the moment we're just using deliberately self-signed, because it's a great map for the way a decentralized network would be managed with identity, that you advertise and say, look, here's me, here's me, this is my certificate. And here's the off-chain endpoint that you can use to talk to me. You can obviously broadcast a different endpoint in your configuration to your own IP address. So this can be a, you know, a nap-resolvable hostname all the stuff you'd expect.  So if you wanted to build the NQP one, this could be a whole bunch of NQP endpoints addresses. This is completely puggable what this broadcast information is, but the way that the broadcast works is really important because this is being broadcast to the system via IPFS and it's being broadcast with the blockchain signature identity of the owner. I know this is really like simple, straightforward stuff for blockchain, but this is an example of the coordination, but anybody using a system needs to understand that you've got this great system to propagate things with signed authorization and signed identity that you attest to this data. So in this case, Node 1 attested to Node 2 that that data was valid. And Firefly has all the plumbing to check the hashes of the payload. Check everything matches up with the signatures that are on-chain, et cetera. All of that stuff is baked into the Firefly Core stack, but with the plugability that actually that blockchain can be any blockchain you like. The mapping, and this is a really important one, the mapping between an on-chain identity and something like a DID. That's a puggable interface. The only plugin implementation of that one right now is there the same. So the identity that you see in the message is the blockchain Ethereum address in this particular case, but that's a really important thing in these enterprise systems of how do I know the signature on-chain maps to a real identity off-chain because identity is not an address. Identity is something bigger like me as an identity is different to my name, Peter, right? That's a very different thing. So that sort of mapping is a key part of this. And then if I go to 5001 here, I'll go to 5001, and I look at the same timeline view. I can see, and I switch from the private where I was doing private messaging, I can see the events as they came in on Nesto with the difference of which ones were private and which ones were public. And I can see that same data that's described, that was published by the other endpoint. Now, I do want to just talk really briefly. Some of you might have noticed something, which I'll talk to Alex about off-line. The order was different on this pain than the other pain. Now, how could that have been? That's because the UI at the moment is using just the list of messages to display this, so they're not in the blockchain ordering. On the API, the thing that actually matters is that you have a list of events. And the events get propagated to applications through a a WebSocket interface, but there's more plugins coming for that. And the sequence of those events is what matters, not the sequence that things sort of exist inside of the database. So that's the reason why you saw that. It wasn't that the system didn't manage to do the ordering, that's like a core construct of the system. It's just simply that the order that the UI is displaying them is not that it's having this sort of order that they're delivered to applications. I'll pause there in case there were some questions. I wanted to go back to Nick. Super. Thanks, Peter, for bridging that gap. And of course, as soon as I stopped sharing my screen, everything worked perfectly. That's how it works. But in any event, if you do see little periods of the failure for all of the orcs to register, take down the stack, restart the stack, and you'll be good right there. So I've successfully restarted it. All of my orcs have joined. And now what we want to look at is we want to look at some of the accompanying program, specifically sort of a turnkey, just one-click CLI program that'll do a public broadcast to everyone, and then a very nice powerful React-based user interface, which will let you experiment with private messaging. If you have more than two members inside of the system, you can enumerate which members you want to send those messages to. So just for posterity, let's go and make sure that all of these are looking as they should. So we originally were seeing one network member because it failed to broadcast and failed to do that registry, but now across my three members, we see that everyone has that peer-to-peer communication and I even sent a test transaction in in the background. So what we're going to do now is we're going to transition, assuming that the CLI is built for hopefully the majority of the audience that's interactively following along, we want to transition into the Firefly Samples repo right here. And it has two folders. It's very, very straightforward, very clean and lightweight, but also very powerful. It has the private data transfer CLI, which like I said, this is just going to do a broadcast.  So the first thing we'll do is we'll just do the CLI and we'll send a basic hello world message. And when we're while we're doing that, I'll show you one interesting thing. We can we can actually look at, you know, some of the lower level logs. We can see the true existence of these Ethereum transactions hitting our ganache. And, you know, we can see some of those JSON RPC methods that everyone's familiar with. And we'll be able to see, you know, transaction hashes and timestamps and all that good stuff from Ethereum transactions. So if we look at our running Docker containers, what we'll notice is that we have an ETH Connect container for every member has their own unique ETH Connect container. So when I kick off this, you know, this end to end CLI program, it's going to be org number one, member A, this container right here, the first organization side of my stack. They're going to be broadcasting that message.  So I'll go ahead and copy this container right here. We can open up the logs and then over here on the right side, we'll just kick off this program.  They're just very simple. You do a quick NPM install and then the programs will run. So it makes your life really easy. So we'll take a look at the logs for this container right here and then we'll go ahead and start sending some transactions into the network. So here's the logs, nothing overly exciting right now. When we start to kick off this program right here, I'm just going to do an NPM run start from the root of this private data transfer CLI folder.  And we start seeing, you know, all of those familiar Ethereum things, right? We start seeing, you know, the, you know, the JSON RPC calls, right? Estimating gas, sending the transaction. We see the acknowledgement of the other nodes inside of the system that they've received this message. And we can now, you know, very closely correlate, you know, all of these things that have been abstracted, you know, to our trust anchor, to our ledger that's kind of sitting in the beating heart as a connector inside of the Firefly Core right there. So just wanted to point that out for folks to see. So that's just kind of the out of the box, you know, click NPM start and boom, it's going to send some transactions into your network. You can go into your user interface and you can see those transactions. You can do what Peter did right there.  You can open up the broadcast. We can see the strings that came through because this was public. It was available for node number two right here. We can see the data hash. Essentially, any piece of metadata or any piece of detail that makes sense for your business process, this is going to be exposed if you're privy to that transaction. So we see that one come in. Now let's go a step further. Now let's open up this user interface and start talking about privacy a little bit. So similar to, you know, building that CLI folder right there. All we need to build the UI folder and fabric samples right here. Again, you go into here. You're going to clone this repository.  Once you've done that, you just do an NPM start and it's going to expose a wonderful user interface for you hosted on port 3000 on your machine. So I'll go ahead and stand this up for the UI component now. So let me go back a directory and then we'll go into the UI component right here. So similarly NPM run start and fingers crossed since I'm doing a live demo, but this should ultimately serve on my local host 3000. And what we'll notice as this manifests on the page right here is I have a toggle. I can switch context now. So I can act as org zero or member A inside of this system. Feel free to use your own nomenclature. But what we have is three members, each of whom has that application that we looked at over here 5000, 5000, 15002. And we can toggle context right here so that we can, you know, do invocations to the blockchain, right? We can do message broadcast to the system. We can do private messages inside of the system. So let's just look at, you know, a broadcast where everyone's going to get this message, right? Welcome to the Firefly workshop, right? We'll go ahead and broadcast this into the system and this is going to go out to everyone, right? We're going to see that it was sent from myself. If we go and toggle the different components right here or the different members, we're going to see that they received it. They received it from my address right there. This guy's going to have the exact same string. And this is, you know, a very, very easy public message. And I even see that I sent this to the rest of the network. Let's drill down another layer now and talk about what's really important, though, and that's privacy in the scope of this broader ecosystem. So rather than broadcasting to the whole network, and again, there are clean APIs that will make your life do this, a common simple REST API that, you know, is not reliant on a user interface. This is emblematic and representative of how easy it is to program against the Firefly APIs and build out a nice powerful UI like this that Andrew and team, you know, worked on really, really quickly too. I shouldn't, you know, sort of toss that aside. The development on Firefly, you know, is really accelerated. There's easy interfaces, easy REST APIs, and easy components to wrap your head around. So rather than broadcast to the whole network, I'm just going to go ahead and choose, you know, a single recipient. So I'm grayed out right here because I'm the sender. I don't want to send anything to myself. I already know that information, but maybe let's send it to org number one and their address right here. Okay. Really private data. Okay. We'll do that. We can go and submit this to the system. We get that immediate asynchronous response, right, that the message has been sent, that it's into the system, and we see that we have this right here, right? We can see that it was submitted. So let's go ahead and now switch to org number two right here, and we see that they've received that message, right? They have line of sight into this really private data. We can go into their user interface over here, and we see that as well, that it was a private transaction, but it is available for this organization, right? They were privy to this. Just like, you know, you can make this analogous to, you know, something in using Tessara inside of Ethereum, right, using that private four parameter and just enumerating the public Tessara address of who you want to get that private transaction and who's going to be able to execute it or make sense of it in the system. And if we go back here, it should go without saying that if we go to org number three, member C, who I did not make privy to this transaction, they don't have any line of sight into the inputs, right? They're not going to be able to make sense of that private payload. They're just going to be able to see that, you know, maybe something came out into the system. So that's the UI and the CLI that you get out of the box in the fabric samples repository.  But this is your core navigation over here on the left. This is going to, you know, give you all of that macro or granular information that you need. You can toggle between list and timeline right here. You can go, you know, over the course of a week or over the course of a month and you can change the namespace to the system or to default as well. One final thing that I'll point out here as well, and I'll save five or 10 minutes for our engineers to, you know, maybe take some other questions or show pieces that I've forgotten to show. But if you just remove the UI and you do slash API, which we did show earlier, it's one everyone to, you know, just know at your core that this is there and ultimately you're going to want the APIs, obviously.  So slash UI, slash API, these are both served after you successfully stand up a stack once you do an init and a start using the FFCLI. And again, you do a Docker PS, you can see all those containers. If you're into, you know, the actual blockchain transactions, we recommend that you look at one of the blockchain connector containers such as ETH Connect for Ethereum. Okay, 10 minutes left. I'll pause for a second and just ask a question to Peter and folks. There's another repository that we have. It's the data exchange one built with Visual Studio and also has sort of a nice flow and some exposed API. So I wonder if it's worth going through that or if we want to focus a bit more on any of these pieces inside of the CLI. Yeah, I think that was close. Yeah, absolutely. I think Nick had a few thoughts. Yeah, I just wanted to add a comment. I know there have been a lot of people that have been trying to get this running in the background here and running into a whole variety of issues. There's like 40 people on this call, which is probably 10x the number of people that have tried running the CLI before today. This is bleeding edge. And so we just appreciate you bearing with us as we are launching Firefly. We're really excited for this to be collaborative. So if you are running into issues, we definitely want to help out. I will drop a link to our rocket chat in the chat if you want to join and chat directly with us. We would love to help you get around these things and also thank you for reporting stuff that you're finding. As you saw from Gabriel's diagram, there are a lot of moving parts to this system. And so there's just a lot of things that may be unpredictable in different developer setups. We want this to be super easy for a developer to get started really quickly and just be able to focus on building their app and their business logic. So excited to work with everybody here to help make that happen. Oh, thanks. There's the camera. Hey, everybody. So yeah, I'll drop a link to rocket chat and feel free to open GitHub issues if you're running into trouble to help you guys out. Thank you. And on your suggestion, I will pull up the homepage of the MTLS data exchange and then Gabriel maybe could talk a bit about that. Yeah, and this one, as you're pulling it up, I'll just speak to it since I've used it a few times. This one's uberly convenient. Gabriel has abstracted a lot of the heavy lifting for you and it'll automatically generate a couple nested folders and some PKI artifacts that you need for authentication. And then it gives you, you know, a unique swag or interface for each of the members. So highly encourage everyone to use this. It works swimmingly with Visual Studio right out of the box. So over to you, Gabriel, for sort of the more deeper explanation. Sure. So when we store private data in one of the Firefly instances, it actually goes into the database of that Firefly core. And if we then want to send private information to another member, we need to be sure that we do it through a channel that is end-to-end encrypted. And this is where Firefly uses the Mutual TLS data exchange. So basically it relies on this component through applying interface and it basically delegates the responsibility of sending that message across securely to the other member. So for this to work, the CLI, what it did when everything was being provisioned is that it generated a number of certificates. This is private keys and public certificates. And so it uses those in each of the members so that the members can basically identify themselves and each other. So when data is being sent from one member to another, we use those certificates and those keys to encrypt the information and make sure that it securely makes it to the other side. And then we can know for a fact who that information is coming from and then the Firefly core will process that information, add it to the internal database and then continue with the coordination of the other elements. Is there anything you wanted to add, Peter? No, that was a great explanation, Gabriel. So I guess we're at a few minutes to here. Were there any questions that had come up on the chat that we wanted to surface and talk about a little bit? I think thus far the chat's mostly been around troubleshooting. We acknowledge we need to do more testing on Windows. And I think a couple of things for us to look at as a takeaway here. And I guess I'm really pleased to see so many people trying this. Certainly for everyone who's been involved so far, it's a pretty significant day for us that this is launching something. And it's launching something that's... What makes Open Source special is you're not launching tech, you're launching a community. Everyone here who's been trying out the DayZero copy of the Firefly command line to get everything stood up. That makes you there on DayZero of this community. And I'm really excited to see where it goes, how we work together as a group, how we do, as Brian was saying, like at the beginning of the day-to-day, that blockchains had... And Modify Systems as a whole has got these great, absolutely fantastic projects. The projects are a very specialist and niche in a particular area. And this project's trying to be a bridge, be a link between them. And for those technical folks on the call, I hope we've got people from a whole bunch of projects who are thinking, does this fit with my project? What's the relationship? Is this something that would allow us to reach a whole bunch of people who aren't going to be working inside of our box but suddenly would allow our box to be available to all those enterprise developers who just want to use this stuff and coordinate it together and build solutions on top of it. And I'm really excited to be just at that beginning and we're going to hopefully be working together with a real spectrum of contribution coming together and leadership from all of these communities not least Bessu and Fabric who've already been really involved over the past few weeks as we've been discussing this within the hyperledger community. But also, we've been talking lots to Avalon and we've been talking lots on the identity side as well. So it's going to be really exciting seeing how we can bring this all together. Nick, did you have anything to close out on this one before we... No, we just... Yeah, I have a few thoughts, I guess. Really, really appreciate the broad attendance and for folks sticking around even if things get a bit bumpy. That's how nascent projects tend to work, but we're here to get this mature and get this hardened hopefully with your help. I'll just reiterate, we really, really do want to hear from you in our meetups on Rocket Chat if you have requests for updated documentation or if you're a good Samaritan and maybe you even want to write some documentation. We're all for that. And we really just sort of want to be sort of co-stewards of this project with the community and with everyone. So we're here to help, we're here to build together. And again, we're as accessible as could be. So please don't ever be shy if you need to get in touch with us. If you have thoughts, if you have issues, if you have suggestions, our eyes and our ears are wide open. So just thanks to everyone and we're really excited about this project through the rest of 2021 and well beyond.


OK, hi. I'm Nigel, and I'm here with my colleague David, who's going to be taking you through some of the other content. I work for IBM, I'm based in the UK, and I'm actually a maintainer on our open source Egeria project. Egeria is part of the LFAI and Data Foundation, it's a graduated project, and we've been involved since the inception of that project. The purpose of Egeria is all of our metadata, so that's what we're going to talk about today, and what exactly is the problem that we're trying to solve through a solution like Egeria and other software solutions that are out there in the metadata space. Now, some people will know a lot about metadata, some people may be not so much, so the first thing to think about is what do I mean by metadata? So, what we have here is a picture from Brighton where I live, this is a famous pier. You may recognise that, or maybe you don't recognise it, it depends if we're in the UK, maybe more people recognise it if I was over in the US, less people would. So, what metadata gives us in this context is all of this additional information, this is from Apple Photos, and it's telling me things like what's the location where it was taken, what's the location where it was taken, what device did I use, what were things like the shutter settings that were used. And also, maybe things that I've curated, like tags I may have added, that might help me in my searching for photos later. And the important thing about this as well is, over time there's become a lot more standardisation about the format of that metadata, so you can use different photo apps with all your photos, and you can kind of get a consistent view across them, so standards is actually really important as well. Now, if we look in the organisation, this is actually a map of a lot of systems within a bank that we've worked with who are actually still involved in the project. And this just shows you all of the different systems that are collaborating, different flows of data, different service calls, it's complicated, and it's got more and more complicated over time. This has been going on for many, many, many years. And when we're trying to do our data science, we're trying to develop new AI algorithms, what's really important is that we actually understand not just what all these data elements are, but also things like the flows between them, who owns them, things of that nature. And when we look in these enterprises, what we actually find is that they're using a lot of different tools. So they may have tools from one vendor which works very well for their development teams, and very different tools that maybe are used in their data science teams. And what we typically see is, although there might be metadata, for example, about database tables that are being used in the data science space, they're probably in isolated silos. So other tools, maybe in development for example, or business reporting, they don't have access to that same metadata. So there may be repetition, there may be inconsistencies, these tools are not working together. And we can see one example of that here. So this is a scenario where we've got one person, Callie, and there's a whole lot of personas we've got in our documentation you might get used to when you refer to it. This is one of our personas. And she's actually using public data from a local government data source, and from the employee directory, and she's going to try and join them, and she wants to send birthday cards. And what's actually happened here is that she didn't understand enough about the information that she was using, because if, for example, in the UK in many countries, you may have two dates associated with a date of birth. There's your actual real date of birth, and then when it was actually registered. So you've picked the wrong field, you've sent, in this case, birthday cards to people on the wrong date, and it's obviously not their birthday. So you failed in your objective. That's a very simple example. That's just birthday, probably not too upset, but you can imagine many cases where using that wrong data is going to get you into problems. The other thing about metadata is there's a lot of different types of metadata that you'll see in an organisation. It could be things like the technical metadata which describes the fields, the columns, the tables, store procedures, etc. Within a relational database, but then you may also have an enterprise glossary you've used where you're trying to describe in a consistent way all terminology that you use in an organisation. So how you describe a customer or how you define a renumeration in some way, and you want those to be consistent. So there's an implicit linkage if they're using them to describe. And of course you've got your policies maybe around how you control data, how you worry about things like archiving. And so what is important to recognise when we're managing metadata is the linkage between those, and that's a critical element of managing metadata. So there's lots of opportunities if we get this right. This allows you to do things like look for a new business, become more efficient, become more agile, and be able to do that across many different parts of the organisation and meet compliance, etc.  David Weinberger, British, I think mathematician I think, metadata liberates us, liberates knowledge. And actually we can think of examples like going back to the Second World War where actually metadata was so important in understanding how different sort of organisations communicate. Tim Berners-Lee, data is a precious thing and will last longer than the system themselves. That is just supporting the fact data is really important and metadata tells you what that data is. So there's a few more quotes that you can read as well here. And with that I'm going to ask my colleague David to talk just a little bit more about Ageria itself and metadata. Thanks Nigel. My name is David Radley and I'm an Ageria maintainer and work with Nigel for IBM. He's explained the business problem that I think you're probably familiar with. I'm just going to check how many people here work with data and metadata. If you put your hand up. All right, so most of the people and the others I assume are interested in this area. Okay, that's good. So what I'm going to do now is the title of the talk was about building an ecosystem around governance of data and metadata in open source. We talked about the business problem. What I wanted to talk about was the vision. How would we really like it? And then we'll talk about the software that can enable it, which is going to be Ageria in our case. So talking about a sort of a new dream, a new manifesto for metadata and governance, because the maintenance of governance of metadata for all of this data, which is vast now and diverse, it needs to be automated a lot. So I've got this robot to represent automated, but also it needs to be provided to the business user appropriately. So it needs to be nurtured in a very special way to make sure that the data is appropriate for the different roles in the community. So that's one of the things that we think is very important. We want the availability of metadata to be everywhere. So we want it to be knitted through our tools so that metadata discovery and maintenance, for example, is the bottom one, is around every tool that accesses the data so that metadata is taken out, sucked out and can be seen. So this is sort of making sure that the access is open as well. So not only to see this metadata, but we need to know what it means. We need to sort of codify it in some way to have open agreed standards around the elements of the metadata. But also similar to this sort of bespoke sort of consumption, it needs to be personalised. It needs to be appropriate. A dataset for a data scientist needs to be prepared in a certain way, which is different for a dataset, say the owner of the data will need a different view of that. And the consumer of the data for application development would need a different view of that data, though fundamentally that would be a dataset at the technical level. So my quote at the top was, you may say I'm a dreamer because this is the manifesto, but I'm not the only one. We're in a community, the open source. I hope that someday you'll join us, which is the whole point of open source. And the last one I've made is because metadata can drive you on was my change to the last one. But it seemed quite appropriate because we're all talking about metadata that we want to understand in an open way and having community around it to agree the standards that we want to go forward with. So Ageria is an open source project, as Nigel said, a Linux foundation. It's trying to make real that vision. So it enables the sharing of knowledge. We have a distributed federated model and we have agreed open types that describe the various types of metadata. Everything that we think is important around an information ecosystem, from its governance, from policies and the semantic meaning of things and the technical metadata, we have agreed in some open types, which I'll talk about next. And this is the open types that we have here. So these are really the core of Ageria. This is how we have a common language that enables one tool to talk to another repository using this common language. Because traditionally integrations between these metadata services and repositories have been, maybe it's difficult to know what you know what it means in one repository. You know what it means in the other repository. But can you get consistent mapping between what it means? It's very difficult because they've each got a slightly different nuanced view of what it means. So the way we solve that is they both map to what a agreed open standard, which these are these open types, not technically a standard for the standards person here, sorry. But it's an open, these set of open types that Ageria has that are very well understood. So we say it has to mean this for you to map to it. So we have a way of communicating using these open types, which is probably the main way, the main value that Ageria has. Of course, many vendors would have a set of types for these things. And there are many metadata standards, but often the metadata standards are on an industry basis, although for a very small area of metadata, this has got a very wide, it's describing, it's looking to describe everything. And we've made a pass of it with some very expert people to come up with this first pass of these open types that we hope is good enough. And we've improved them slightly with versioned them with time as well. It's backward compatibility with these types. And if you don't think these types suit you, then you can extend them or add new types. And so it's a growing organic thing. But the more that we can agree on, the more that we can, the more that we can write tools around those agreed things. That's the sort of idea that we have it in the open type model. We can then write code around it and exploit those types and know what it means. So, the more we can agree the better. If we all have our own language for everything, it makes it difficult to communicate. So, a common language is the first step towards communication across cultural boundaries. And I was thinking, we all know that the data warehouse guides and the data scientist guides and the people who own the data and the DB admin have very different languages. They're very different cultures. They're different people. They've got different motivations, different roles. This is allowing us to have a common language to cross those cultures. I could definitely recognise that within organisations. These different ways of thinking, different motivations for different groups lead to different cultures and different hopes and dreams and motivations for each of these groups. So, these are the main areas for the open types. We have the base types for systems and infrastructure. We have technical metadata like assets, APIs, databases, topics or events, metadata discovery. We have reference data, collaboration things. We have policies in the governance. We have a semantic world. And it seems that the most important part is actually the linkage between these areas because these are often, as we just talked about, separate areas. So, we actually have within the metamodel of Nigeria lots of linkages. You don't need to learn this, but it's in the slides if you download it afterwards. But one that's quite interesting is that you can associate a meaning with a technical metadata. So, a column that is a national insurance number, you can actually associate with that with the meaning in the semantic layer. This is a slide showing that some parts of the organisation may already know what something means and other parts don't. Because of this, the silent nature of existing infrastructure, it's difficult to connect those two people, one has the question and one has the answer. So, Nigeria comes in and through this idea that we talked about, that it has the common method to be able to, the common way of representing things in metadata, these open types. And it covers, it can be deployed on all these different types of platforms like data lakes in the cloud and IoT spaces, application development. I'm just going to quickly go on. This is an example about how looking at metadata, how metadata gives value to me. So, the bottom layer, this is a string and we don't know really what it means. Some things like to see some numbers that might be interesting. The first thing we can do is put across structural metadata to get the technical metadata. So, database columns, for example, or just splitting them up. And then the next level that we can go to is put in, actually relate them through to meanings in the semantic world, the glossary terms. And then create a semantic model relating how managers and employees are related with ISRO and hazard relationships. So, this is a really powerful way of bringing the language of the business and being able to work at the language of the business and then map it down to the actual technical ones which look a bit like gobbledygook if the business person has to deal with that directly. We also have the ability to classify things. Here it says sensitive, we have confidentiality levels that you can place against the technical assets or you can place them against aspects of the glossary terms and the like. So, the data needs to work harder. So, we've got, as we have this data and it was very safe within a little silo surrounded by an application, it had its own protection. As we now bring it out to be able to be used for analytics or governance to get a coherent view across the data so that we can meet compliance regulations like GDPR, like where's all your customer information. It could be split between many different silo's information behind many different applications. As we take away the protection of those applications, we need to re-add it and re-secure it across all the data that we've now exposed potentially. So, that's why this making data available is very close to the governance program. We need to work out how we want to govern this data probably based on its meaning rather than that it was DB2 or Oracle or whatever. There can be some factors around particular databases that are sensitive as well. So, that's the idea that potentially these turtles or tortoises, they lose their protective shell and they're looking a bit embarrassed and they're a bit exposed at the moment. So, we need to be able to put something back in. So, Ageria, as it's taking away the shells effectively, needs to add something back to be able to protect them again. So, we've got a big tortoises shell now called Ageria and it now has to look after that metadata. So, it's got concepts like zones for assets so you can actually deal with things that are sort of at the right level. You can have development aspects of a zone. You could have a production zone, you'd have an archive orientated zone, you could have sandboxes. There's different approaches that it takes as well as effectivity. You can use that this is, Ageria is a metadata layer. So, that's why we're talking that it needs to be able to store the policies and the rules at which we have places in the metadata force to be able to keep the data safe again. So, in operation, Ageria, it can live in all of these different spaces. Like we saw in the other picture, it could live in the cloud, on-prem, closest to it with IoT. Here, we have Ageria platforms. So, the way you run this is that you have a platform and that's effectively a process. Instead of writing lots of different bits of software, bespoke POS software for all the different ways we wanted to use the metadata, for example, as a view service or as a discovery engine or as a metadata repository, what we've actually done is encapsulated that in configuration. So, the platforms there and your configuration describes what the type of server is. So, you run these yellow blobs, these orange blobs, as servers that run on the platform. And they're all configuration orientated by default. Those will be in files. Are we just about? Am I just about finished? OK. OK. So, that's how well the Ageria platform and servers are about. Nigel is going to go on and talk about, I'm going to a demo, and he's going to talk about how you can get involved with the community. This was sort of an overview of some of the general ideas about why we think Ageria is an important place to be able to manage your metadata and govern consistently. And it's demo time. So, the challenge always is how do you represent the stuff that you've been working on? It's kind of middleware, right, and metadata. It's so important to us all. But what does it mean in terms of actually visualizing it? What could we show you? So, what I'm going to show you today is some Jupiter-based notebooks that we have. So, this is deployed, can be deployed locally, but typically we've deployed through Kubernetes. It's a Helm chart. You can go out, look at our documentation, ageriaproject.org, which is on most of the charts apart from this one. I think maybe it's just a bit dark. And that gives you instructions for running what I'm going to show you now. And in fact, if you look at the foils later, there's a few links here. I'm not going to talk about these, but if you pull down the charts, that gives you a few links to the specific demo. So, we're going to flip on over to the web browser, hopefully. If I press the right button. Always the hardest part. Mirror. Okay, let me just exit. Somewhere. Here we go. Okay. So, what I've actually done here is, I've started up this demo before the presentation. It doesn't take very long. It takes a few minutes. We might look at that later. But we did this based on this organization that we've got called Coco Pharmaceuticals. It's a medical research company. It's gathering results on a weekly basis that it has to manage. And so they have a certain infrastructure. They have a lot of personas defined. This is all in the documentation. And this lab that I will show you, which will actually be... Let me just check if I've run this one. You can step through. And I'm just going to go to one I created earlier. Bear with me one sec. Asset management building a data catalogue. Okay. So, this is going to take us through a scenario, which is actually using a gerus. It's actually running in the background. And we're going to focus on these two people here. We're going to concentrate on Peter. And we're going to concentrate on Erin. And they're going to actually catalogue some of this new data that they've got. But first, let's look at the infrastructure that Coco Pharmaceuticals has got. And so they've got a number of different what we call platforms in Kubernetes. These are running in different pods as containers. But within each platform, we have a gerus servers. And these are what effectively service the requests that are associated with different lines of business. So, for example, a manufacturing organisation has got one virtual server. We've got our users on the data lake, which is CocoMDS4. They've got their own server. And this is what Coco is going to use. So we're going to run through this notebook step by step. The thing that, OK, what I haven't done is configured it. So let me just run this again. It's funny. It's always the thing we're doing live demos, isn't it? That they don't work. So let me just go to the top of this. And I thought I'd run it. Let's try again. So we will be there in a sec. What we have is actually have a notebook that configures all of the servers, which should have run, but obviously hadn't. So it's running now. And this issues lots of REST API calls. So you can read through this in your own time, but that's actually configured the servers.  This is all Python scripts. You can go and look at the Python code. You can see what's actually happening here. OK, now we're ready. So now we're going to go back to this demo. OK. And this time it should be fine. OK, it's starting. This will take probably about two minutes. So what we'll do is, whilst that's running, we'll talk a little bit about the scenario. So Peter's going to add some data sets to the catalogue. A data set we record is what we call an asset. This is the thing that really provides business value. So it's the thing that we really, really want to manage. And so asset has attributes, of course, like owner, through these relationships that we have. And so the Python code in the next section, which I'll run once the service started, is going to actually add those assets into Ageria in the data catalogue. So this is actually running the REST API services directly. We also provide Java client libraries. So you can get sometimes more validation by using that than calling the REST API directly. We're hoping to actually wrapper up some of the libraries that we've got here in a shared Jupyter Notebook, maybe into a Python library at some point. And actually, if anyone wants to contribute to that, that would be really useful as well. At the moment this is running on the cloud. And it's just taking a minute. So we should be there soon. So when we look at an asset in this case of a file, what we're actually going to create is a whole lot of different elements here. We've got the file system, we've got the different folders that they're in, and the actual data file. And all of these will appear in Ageria as linked entities so that we can navigate the relationships between them. And we should be there very soon. Okay, there's a problem. I don't know why that's not working. Okay, that is going a little bit problematic. So what I'm going to do, let me flip back to the charts. And if we've got time, we'll come back to the demo at the end. I think that's probably the best thing to do. Okay, so let me just talk a little bit about community. We've got one project here, Ageria, which is in LFAI in data. But we're part of a much larger organisation. These are all the, not just LFAI data projects, but other projects in this space. And we can see lots of potential for linkages between them. For example, there's the Open Lineage project, which is really interesting. There's projects like Marquez. And Open Lineage we see a lot of other projects integrating with. So there is a presentation tomorrow, which you may be interested in, which is from our project lead for Ageria, which is Mandy Schessel. So she's going to be presenting on Thursday afternoon. So I would definitely recommend that if you're interested in lineage. And another part, of course, is what you can do, how you can play. So we have releases monthly. That just happens without fail. It's something that we do. We worry about things like security. The talks we've had here around S-bombs have been actually really interesting. It's something that we've talked about doing. We haven't done yet, but we need to. We manage all our dependencies. We try and minimize attack surfaces and things like that because we are focused on making this an enterprise solution. We also have things like different storage back end. So you can have a metadata repository with Ageria. And you don't have to. You can also link to an existing metadata repository. But we've been looking at XTDB, which is very scalable. We can do things like time traveling with that. Areas that we're also looking at at the moment include making tutorials and education better. Building connectors to multiple technology. We're doing a better JDBC connector at the moment. There is a user interface, which you can play with. I would recommend going back to the notebooks. If we've got time, we'll quickly touch on that. And our repos. So github.com, ODPI, Ageria is our main repository. We've got about 30 or 25 or 30 in total. So if you can star that, if you like what you see, that's always really good for us too. And if you use Ageria, if you take a look at it, give feedback. We've got Slack channels. We've got mailing lists. We've got the issues, of course, in the repository. We have an Ageria docs repository, which is actually what builds the ageriaproject.org website. And people that are new to the project often are the best people to actually comment on some of those documents because they make obvious statements about what's missing. So we absolutely would love your contribution. So with that, how long do we have left? Do we have time to flip back to the demo for a bit? I tell you what, why don't we start with questions and I'll look at getting the demo working whilst we're taking a few questions. Are there any questions anyone has on the virtual side or the physical side? I mean, the way that most people would get involved with this would probably be thinking about what technologies they were interested in connecting in and then be looking at creating connectors, Ageria connectors. There's a lot of detail which we haven't gone into. We're looking at the sort of very high level here, but looking at creating those connectors would be the way that you would get a new piece of third-party technology into this ecosystem. And we're accumulating connectors and I've written a couple and we're getting a JDBC one being written at the moment so that will cover a lot of connecting in sources. We've done one around Kafka events and Kafka, we're working on one for schema elements around events. We can do APIs, we can take in open lineage. So there is a lot of these connectors. We have a connector framework which everything in Ageria is written around. Everything is pluggable. So it's been written in a very rigorous way, a very architected way. The way it was written initially was the person that wrote it wrote the audit log first and then the connector framework. So this was a very rigorous layered way to create Ageria code base itself and as well as the open type system and the protocol that goes around that that facilitates their communication. So we have that layer and then we have this consumption layer around accessing the metadata in the different tools or different personas. This sort of which I had is the different coloured dodots. So you can, so data science sort of way of accessing metadata or a discovery orientated view of the metadata. So that's a little bit more detail about the technical side and where you might get might as an organisation might want to get involved would be to assess whether there's existing connectors that you could utilize, whether there's new ones. If you like this idea of it not being owned by one vendor because that's one of the big advantages of having it in open source it's not owned by one that we all own it. So it's not a Microsoft versus Google versus an IBM sort of standard. This is something that we all sort of can own as a community and so that people tend to feel less reticent to adopt it because it's a bit easier to adopt that sort of thing because it's ours to begin with. So that's a bit more detail. I don't know if that's triggered any questions or it's written mostly in Java. We do have some Python bindings. So if you're looking to contribute there are, there is UIs. So JavaScript there's a React UI. So we've got node and react around that user interface area. So from a developer point of view someone wanted to be involved with the community, contribute code, that could be an area, either the React area, JavaScript area, the Java area or the Python area. They're the main ones. So that we do have Kubernetes as Nigel talks about. So these charts are based on Kubernetes. I don't know if you saw I was reinstalling the charts as we were doing that. So we have a Helm repository and there's instructions. We've built these things called dojos, which are education sessions. So day one is called getting started. And in getting started it will walk you through using these notebooks and getting you to feel for what Nigeria actually can do. And then we have a second day of dojos and that's actually working more at the sort of Java API level and walking you through building an application or a little plugin that works alongside Nigeria and shows you how to build your Java code. We will have more dojos. We've got one on governance that we're working on and one on production cases that we're working on. And so, yeah, I've been doing some of the Kubernetes deployment. Some of the people that we've got deploying are obviously deploying in Kubernetes. It's still an area we're working very much on. So if anyone wants to contribute, that's a fantastic area for contribution to, especially in this sort of community that's so much going on around Kubernetes. I started working on Operator. And what that means is it just makes it easier to manage these systems because you can clearly define some of the constructs that we have in Nigeria and do operations on them in the normal Kubernetes way using custom resources. So that's kind of quite an exciting area of development as well. So as you can see, what we've done here is we've restarted the lab completely with about three minutes to go. So we're probably going to run out of time on this step, unfortunately. We have got a link in the presentation to agiriproject.org on there. It talks about our community, how to get involved. We have weekly calls. We have the webinar programme where we educate people on a particular subject. Come along to GitHub. I'm Planet F1 on GitHub. David's David underscore Radley on GitHub. David Radle, sorry, on GitHub. So come and take a look at the project. And if you want to try this demo, I'm happy to point you in the right direction. If you get any difficulty with it, it will teach you a little bit about how to make those REST API calls, how to actually make use of Nigeria, and also look at some of the UIs with Nigeria. So the question was what kind of policies can be defined for data security and are there any examples? The way that we define the word policy in our open types is actually it's a verbose definition. So maybe all confidential data must stay in the building, or something very verbose. And then we have, in the metadata, we define rules associated with it. So security-orientated rules might be around PII sensitivity. As you need to treat PII data differently, to be able to comply with GDPR. So GDPR has a whole series of constraints about the way that you need to manage that data, and those could be articulated in rules, on what we would call rules that live under a policy. So that might involve obfuscating if we're the metadata layer. So we're not the one that's actually implementing the rules. So you could look the rules up and then run them either in sort of enforcement road if that's the way that you want to run things or just to say how valid is my, how compliant is this data and use those rules to describe that. Did that answer your question? I don't know. Yeah, they probably can't hear my... There's a bit of a delay, so I'll let you know. Okay. Anything, any other questions? I can see you're all rearing to start coding Igeria PRs. I think everyone wants to go and start working their S-bombs, because that's been... Everyone is doing that these days. So thanks everyone for coming. I hope it was useful to you. Igeria, we're on GitHub. Metadata, come and take a look if you're interested and thanks for coming today. Thank you. Thank you.


And then Magnus said, we have some news about Batman vs Superman. And for all you U.S. ladies, no Batman vs Superman, he's Batman V Superman. The V is for Versus Bitches. So anyway, and if it ain't let me know, okay, if it isn't let me know then I will make a public apology for calling y'all bitches. So anyway, apparently, Tuesday will be in Batman vs Superman. And I got the news in this article, and let's read the article, shall we? So as ever since Jesse Eisenberg was cast as Lex Luthor in Batman vs Superman, dawn of justice. Fans have wondered if another villain would appear as well. Doomsday has been heavily rumored, and now Badass Digest is confirming that he is in the movie. But the site also reports that Batman villain will also have a cameo. Badass Digest says that KG Beast, a Batman villain introduced in the 1988 classic Ten Nights of the Beast storyline, will have a small role in the movie. Batman news can confirm this report. Sources told me early last month that the name Antoly Knyastaviv, which is KG Beast's alter ego, was on a trailer in Chicago. They were filming in the subway, and Callan Mulvilla was spotted dressed in black with a tattoo on the back of his neck doing things that a bad guy would do. It's possible that the Callan movie is KG Beast in Batman v Superman dawn of justice, but that's just speculation based on all the information that I have received. And here's where things get really interesting, a small Easter egg that some may not want to know about before they see the movie. So close your ears, because I guess it's spoiler alert time.  Badass Digest says that while the Joker won't appear in Batman v Superman dawn of justice, his name will be mentioned. Apparently Superman already knows about the Joker. Between this news and yesterday's official casting announcement of Suicide Squad, Warner Brothers is really opening up their DC universe. Let me know what you think about this news in the comments below. That's what he says.  So let's talk about Doomsday. So with Doomsday being in this movie, what do you think is?  Super man, the man of steel, the son of Jor-El Neil before Zod! Do you think that's where it's going to be?  I just don't think that's going to happen. Maybe Doomsday will be introducing.  So anyway, I don't think that's going to happen. I think a fight might break out or Doomsday is going to be introduced. Maybe we'll be left with some type of a cliffhanger or something like that. Post your comments below. Let me know what you think of possible scenarios for Doomsday. I personally think he's going to be a, if he's the main villain, which I, it's, I mean, he's just as powerful, if not more powerful than Superman. I mean, he's got to be the main villain. And they're both of them. We'll have to team together.   You know what I'm saying? One million subscribers.