 Super. Thanks so much, Steve, Sophia, Brian. Really exciting day for those of us. Gabrielle and myself will be talking in this session. I guess we feel like we've been working on Firefly in some way, shape or form. The code DNA, the trail is over three years long for us. There has been a huge amount of activity recently, as you'll see, focused on what does it take for a project to go from solving individual fantastically accelerating problems for customers that we've been working with directly to being an open community that really works for. But actually what you're running on when you actually try Firefly is code that is based on what's in production for real customers. It's kind of us trying to take everything we've learned and distill it in a way that it's not, it's able to be used by everybody. So that's really exciting for us as engineers. We're so passionate about open source. We use it every day. So it's really exciting to be talking to you all today about the architecture of what we really hope is going to be a project that can help multi-quality systems go many times faster than they have. Across many more industries, across many more projects than if everybody continues to do everything from plumbing up. So with no more ado, let me start to drill down a little bit. To do that, I am going to start by zooming back out to a couple of the things and we can have in just for a couple of minutes on a couple of the points that were made earlier by Steve and by Sevier actually, because I'm going to start talking about from a technical person's perspective, this slide, really resonates with me from what we've seen in the industry. This feeling that when you come to a blockchain project, the thing that matters most and it is the kernel, it's the beating heart. It's the thing that makes your project different to all of those other enterprise projects that have come before. It's that smart contract code, that critically important piece of code that you're probably going to be reusing and building upon something that came from others. There's this feeling when you start a project that it's about that. Because it's the most important piece of the puzzle, it's the linchpin. The project as a whole is going to be about it. And once we get that right, we're golden. Once we've built that smart contract, we've got it audited, we've deployed it, we're sorted. It's there in chain code in Fabric, or it's there in Solidity in Ethereum, or it's there inside of Accordat. We're good. But actually, this middle column, it is so true. What we're doing in these multi-party systems, what anybody who's lived this knows, is you're trying to bridge sophisticated, decades-old IT organizations together. You're trying to bridge together core systems that perform the most important transaction processing inside of a large enterprise that's been around for 100 years. And you're trying to do that in an atmosphere of co-opetition, the reason why these projects are so valuable, building these ecosystems is so valuable, is because you're building ecosystems not just with your supply chain or not just with your customers and partners. You're actually building these as an industry with your competitors as well. So things get complicated. Data, right? Data is in an enterprise context by default, private, sensitive, regulated, probably comes under things like right to be deleted, legal legislation, that means you need to be able to prove who you sent it to, and everybody involved in that chain needs to be able to prove that they can delete it. Some of the data you may only be able to keep for a short period of time. Some of the data may be extremely sensitive. The transactions that you're performing, the fact that you're performing them, with the people that you're performing with, is itself really sensitive. And actually, in an enterprise context, the things that you would do if you were just building something completely, completely designed for end user to end user, decentralized blockchain programming, it's not exactly the same thing that you do in an enterprise consortium. So actually, what you end up doing is worrying about, well, how do I integrate with my core systems? What's this data going to look like? What is the tiny nugget that can go on chain? Where can we use the blockchain to the greatest effect? Is it having a complete unique instance of something like a legal contract or a document or something, the NFT space? Is it, well, actually, we're going to incentivize the transactions and we're going to introduce tokens and those kinds of things. Is it actually proving who said what to whom, in what order, in order to build on top of that a business process? And actually, that becomes the job, all of the surrounding infrastructure. And we've seen it done. We've been part of doing it. We've been part of trying to help projects that have got a few years in and struggled. And we've got all of this experience that we just, this community is about sharing that, coming together with the practitioners that are in blockchain, and have to use this thing. The integrators, the app developers, the mobile and UI beautiful experience builders, coming together to get to where the job ought to be. Let's decide what the business problem is we're trying to solve. Let's work out what our canonical data formats are. Let's work out how we're going to share data. Let's work out the sequence of events that we agree has to be true. And in an enterprise context, let's work out where everybody can do things differently. Because in reality, there's going to be non-deterministic human processing. There's going to be really like business specialist developed over many years, unique proprietary business processes, but your enterprise is secret source. You're not going to give them up just because you're joining a collaborative ecosystem. Work out how those interlock. And let's get to the point that we can build these in weeks and months across industries, create ecosystems where use cases can be built, trials thrown away, and you're not talking about ridiculous amounts of investment, time and engineering, and pressure in terms of project deliveries can be met. And exceeded with great user experience. That's where we want to get to. So that's all very grand, right? So what are we actually? What have we got? What is, and I know that's what we really want to focus on in this part of the session, what is this technology? And what makes it different to a blockchain? Has it worked with blockchain? Has it worked with other multi-body system technologies like Compute, like CQPs and Trusted Compute, et cetera? What is it at its core? And in the previous session, we talked about that a Firefly node is like a microservices architecture in its own right. It's a pluggable system where you run for your organization a mixture of technologies. You run a blockchain, obviously. But you also, you've got a private database that's pre-integrated with this indexed fast, gives you your view of the network, which is by definition in any enterprise context, can be different to anyone else's view in the network. And that's not some strange database technology that you can't use. That's pluggable. That's your core SQL database, right? That's just integrated with your enterprise context. You then got messaging, events, those of you that you're using are messaging, events, those off-chain transfer technologies that we all know as a pluggable service. And today you'll be using one, Gabrielle's going to talk you through the technologies you're going to be using today in the lab, and you'll be using a very straightforward one. But that, again, is pluggable so that you can plug in your NQP-based system if that's active NQ Artemis, if that's your core enterprise system, your typical IBM messaging bus, whatever it is. That plug point is there in the system to be able to integrate that between the members because these ecosystems are just as much about sharing private data as they are about sharing the on-chain transactions as part of the system. So how does an architecture from a technical level support that will in the modern world, go through modern, dockerized, microservices architecture? And that is something that takes really deliberate thought. It takes really deliberate thought and it's probably the biggest thing that we've been focused on in seeding the community is getting that plug-in system right. So I'm going to now really start going to a bit more depth and we're going to drill into what we kind of call the periodic table of elements inside of Firefly. And we're going to start looking at some of the architecture pictures which were available all as part of the open community and I'll show you where to go and find them afterwards and come to the bi-weekly meetings that you'll be hearing about in the community session later, engage with this architecture push on it, throw the rocks. Let's make it implogable in the way that it needs to be needs to be pluggable. So starting from this picture let's talk about what a node is. It has a core. The core is written in Golang for the latest generation. We actually had a previous core that's being used in a lot of projects which we've open sourced it's there in the repository and that was TypeScript previously and we made the deliberate decision as part of seeding this that we thought a go pluggable architecture was what was needed for the kind of problems that are being solved with this technology. So this core is responsible for orchestration. It's responsible for plugging things together. So it has an orchestration tier, it has an API that it services externally which is what your applications connect to and then it has the core components inside of there that orchestrate the big things that are done in multi-party systems. Expect to see these get added to over time. Andrew was showing one of the most important patterns data management, broadcast and private transfer of data and we're working at the moment on bringing from the first generation to the second generation, asset management integrating those fungible and unfungible tokens to get involved in that architecture conversation but Jim Zhang who can't be here today but is a critical member of our community here is leading the drive of getting the wide architecture together for plugging tokens both NFTs and value transfer into this things like delivery versus payment. So that's a core responsibility. It's sort of one of the patterns that at the front of this you get an API that is a developer you can use in those 10 lines of code that Andrew showed you. You're there, you're working, you've got that pattern working for you. Those are exposed externally and then the legs of the swan swimming underneath are the connectors which are microservice run times that connect to the back end core infrastructure and we made a very deliberate decision I'm going to draw down a layer at this point. We made a very deliberate decision in the formation of the plug-in architecture to make it microservices based and this was actually driven by a real world practical necessity. So the core is Golang and inside of there we have a whole bunch of very small shims. At the moment these are actually compiled into the framework because of the stage that Golang is at with live-week plug-ins but they're built so that as the project evolves and as Golang evolves these will actually be able to move to being completely independently built bits of go. But they're also very small bits of go that run inside of the core. They're just shims. They conform to an interface in Go which allows them to be initialized with the configuration that's standardized as part of the core. To be able to advertise what capabilities they do or they don't provide within the bucket that they're in. So there's a public storage plug-in like IPFS or they're a blockchain plug-in like Basu or Fabric or Corder or they're a database plug-in like Postgres or MySQL or MySQL implementation like Couch or MongoDB. Then there's bidirectional data that can go in either direction where actions can happen through that and events can come back. And this plug-in interface allows any transport to be used into and out of this Golang shim. And then the connectors themselves can be written in any language. They run separately. They can have a different HA model to the core Firefly HA model which is what you'd expect active-active database backed and highly resilient modern, minimum-swee deployment architecture for the core. Well, that's really hard for some of the things that might be doing done in some of these connectors. Event management, for example, is very hard to do in that sort of N-Way-Scaled kind of way. So these can have a different HA model but really important they can also be written in completely different language. So today you're actually going to be using connectors that are that involve a TypeScript Node.js connector. It's going to be one of the connectors you're using for the private data exchange. And that's embraced. And it's actually necessary when you look at the different communities. So Cordo for example is a Java-centric community. The native RPC interface for Cordo is Java serialization of objects. It only makes sense to do that in Java. That can plug-in, does plug-in is actually already one of the things that's quite advanced. It's being finalized to move over from generation one to generation two. But that's being proven that that can be done and you can have the brain working in a different fundamental language. So this means it can actually scale. Like projects like Docker were able to do with their plug-in sorry, like Kubernetes were able to do with their plug-in infrastructure. So that's really important we think for building the kind of multi-part and system framework that is at the moment just not there in the industry today. So that's kind of like one deep life and we're going to pull back up again now and we're going to talk a little bit differently about the ping-pong. The relationship between all of this sort of plug-able architecture that is the node and the underlying technologies, the umbrella of underlying technologies that plug-in. And we're going to think about a use case as simple as the one that Andrew was showing earlier. The ping-pong backwards and forwards of data. And we're going to look at what's the job that gets done from scratch in any kind of project today and how does Firefly help. And that I think will really help us then talk about why the architecture of Firefly is the way it is, how it relates to things like blockchain and off-chain compute and deterministic multi-party compute. And some of you may have been thinking earlier you're diminishing blockchain. You're making it just this sort of thin thing that you're undervaluing it. Well, we value it so highly inside of the Firefly community of engineering. And I hope at the end of this next section you'll see why even for the simple cases we need this kind of framework that Firefly is and how it does extend to a cases where you've got super advanced sophisticated on-chain logic that is actually part of the system as well. So we're going to make that transition now and we're going to do it with a diagram we affectionately refer to as ping-pong. So this diagram we're going to zoom into is showing what from a developer's perspective should be trivial. I assert this should be trivial. You come to blockchain and you want to do something meaningful inside of this diagram we're showing not actually just what would need to be done inside of Firefly but actually what would need to be done if you were building this from scratch three stages we're showing I've got a digital asset, a piece of data maybe maybe this is the scan of a diamond that is part of digital twinning it to an NFT maybe this is a document that's just been signed physically by somebody sitting in a port trying to get their boats to leave. I've maybe this is a request for a proposal but I want to advertise to a whole network. I've got one of these and I want to I want to say that it exists to the whole community and I want to broadcast that out and maybe some of that data can go directly onto the blockchain but in most enterprise scenarios we find that that's not always true that there's at least some data that can't go onto the blockchain directly. Really simply I want to write this document to the blockchain we've had that said to us so many times we know that's how it feels I just want to put this document in the blockchain how do I do it? Well that's sort of step one and we'll talk through what that really actually means for a port developer today just starting from their principles I want to push that out to everybody that broadcast button that Andrew did earlier the next stage we're going to look at is I've seen that that thing over there that organisation I know who they are I've got their identity but they have this thing they've published enough data to me through hash or real data or whatever it is that I know I want this I need to ask for it I need to go to them and I need to say well you know that scan of that diamond that matches up with my record I know I've got that diamond I want to ask you for this proof that you've got this super detailed ultra fine scan of it I want a copy of I want a copy of that send it to me I probably don't want to tell everybody in the network that I'm making that request of you and I definitely don't want to send any proof data or whatever it's some proof of authenticity that I have on my side that's going to allow you to authorise me to send it to me I don't want to put all of that whatever everyone else can see and that that means I probably want to send this to you as a sort of private exchange but you still probably want to know it's from me so surely what I just need to do is I need to send you a private message through the blockchain well okay that's great how do you send a private message through the blockchain with all of the data that needs to be aggregated together maybe five different bits of data need to go with that message so that it comes across and then that first organisation that advertised that they have that data to hand they're going to look at what came across to them from this other organisation they've got to inspect it it may be deterministic it may be this super agreed process that everybody runs that's like if you meet these criteria then you can respond it may involve reaching into your own private back-end data stores to make that decision it may involve a human being looking at a queue and saying yes let's not diminish how real that is in the kinds of business processes that we're trying to get from taking multiple weeks down to minutes in blockchain for things like post-trade settlements and all of these processes with lots of documents flying about UPS claims flying around the world there's human decision making involved in this to authorise it and then they're going to send the data back again to the other side and in this example that doesn't need to be pinned to the blockchain it just needs to do that with really fast efficiency because blockchains regardless of whether you're using a private blockchain or you're using a public blockchain and architecturally although the focus in enterprise which is kind of why we're focused there but the focus in enterprise at the moment the real world production adoption is in the permission chains but there's great evolution happening on the interlock with public chains but even in a permission chain you're not talking about the same super super fast throughput because you've got to get agreements on that transaction from a set of parties even if it's a fabric channel and you've reduced the number of parties to a smaller number it's still going to be something slightly more sophisticated than just pushing that data to somebody so there are going to be cases where you want to do exchange where you don't even want to use the blockchain at all I know in a blockchain context in the money party system that's a little bit hard to hear like why wouldn't I pin everything we're pragmatists this project is about real world engineers being pragmatic and getting things solved and yes, real enterprise projects have cases where they want to send data off-chain between parties without pinning it to the blockchain it's true, it happens it's not something that certainly in this project that we think should be said that's wrong you're wrong because you want to do that no, you understand your business process you understand how it fits together yeah, that's perfectly acceptable okay, so really we just talked about three super simple steps I'm going to send you I'm going to broadcast the network something you're going to see because you're following the network that it exists you're going to send me a request that's going to be audited that you send me the request and I'm going to send you back some data let's look at what would be needed to do that from base principles from base principles well, I want to pin it to the blockchain then what I need to do is I need an API inside of my application my app is not blockchain the app itself, the user experience the mobile, the core integration with my backend systems that's unique to me not everybody else in the network that thing needs to be able to upload the data that's going to be pinned to the blockchain it needs to be able to say do it that means it needs an API and almost certainly we found it's almost universally true the amount of transformation that's needed with that data to get it sort of into the system means you want it to be stored in your own private storage so you're going to have a database that isn't your application core database it's not the database of your ERP system that you built 30 years ago this is a separate database that's for the blockchain it's for this multi-party system you're building and you're going to have to transform the data to get it so you can have a database inside of this and then you're going to say look I want to broadcast this but because it can't all go to the blockchain you've got to actually take two separate actions you've got to upload that data to somewhere that is suitable for downloading, it's a 100 megabyte payload where am I going to stick that and that means you need something like the proprietary file system that can be shared between everybody that isn't the blockchain which is a place to put that data that doesn't fit the blockchain model you're going to have a blockchain node and you're going to work out well how do I do a blockchain transaction and if you're starting from base principles it doesn't matter which of the three communities you're in you're going to be there for a few weeks working out how to make just that work so almost certainly you're going to either build or take off the shelf and that's why Firefly sort of integrates with and actually is embedded for the Ethereum community one of these already and we're exploring the right thing to do with Fabric and Ethereum in terms of the relationship between these interfaces and the core Firefly you're going to need an API that knows just how to do transactions on the blockchain how do I do nonce management how do I aggregate signatures from a whole bunch of people assemble them together and work out the right thing to do to be able to submit the transaction if you're in Fabric so you could build that thousand lines of code yourself or just for your project you could use something robust off the shelf and then the other side it gets even harder that was the easy bit because you've now got two things that arrived separately you've got to aggregate them together to aggregate them together and this is actually one of the most important roles that we think in terms of real engineering that needs to be in a coordination system an orchestrator this is actually one of the most important roles of the project like Firefly can take on you need to take things that are why even different orders and assemble them together in this particular case it's actually reasonably straightforward with IPFS because it's going to come across the blockchain interface you're going to detect it through events for the blockchain just a minute blockchains don't have a nice interface for event listening in most cases that's super easy for your web application written in TypeScript so you're probably going to need a blockchain interface here as well so again Firefly is trying to import those and we have the production ready one for for Ethereum on the other two there as well so you're going to detect that it happened on the blockchain and then you can go and fish for that data inside of IPFS you can aggregate those together assuming everything was good you can then dispatch that and then you can actually call your logic and now we're in what is the reality of any enterprise system there's logic that's off-chain it isn't all of your logic that's off-chain but you wouldn't have an application of logic off-chain even CryptoKitties has off-chain capabilities it's just the truth there is off-chain applications and this thing has to have a great user experience it's got an update it's got to be suitable for business users it's got to do integration at a business API layer with a message bus that's integrating as an ESB to your core your core insurance system your core healthcare system this off-chain stuff is not trivial it's really important so you need to have the right triggers coming out of the system into you so you can do something and in this case what we're doing is we're just saying in our application I'm interested in that I've made some calculated assessment the publishing of that is something I'm interested in and I'm going to request it well at this point more technologies come in because I'm going to request it not through IPFS because that would be leaking all of my request data to everybody even if it's encrypted that can be hard to justify from all kinds of regulatory perspectives so probably what I want to do is I want to send that data privately to the one place I'm sending it to I'm responding to a request for a proposal and I'm going to send my response well that's a private exchange with just one organization to another organization but if I want it to be audited that I did it at a certain period of time maybe there's a waste maybe there's a waste and I have to do it before somebody else maybe only one person in the system can do this lots of data matching scenarios have that kind of waste involved I need it to be pinned to the blockchain so there's no ambiguity over the fact it came from me it happened in a certain order there's a global order with everybody in the system even though the only people who have any ability and in future sessions we'll talk about all of the stuff we've done to mean that the blockchain transactions are completely obfuscated there's not even a link between transaction 1, 2 and 3 on the same topic don't even have a link between them there's some great stuff that we'd love to talk in detail there fundamentally this is private exchange you're pinning it to the blockchain whatever happens on the blockchain even if it's more sophisticated like there's some kind of coordinated transfer of an asset that's happening inside of that generation 1 we have that built in that's evolving for generation 2 you're coordinating those together you don't want it to be visible why you're doing it you may not be willing for it to be visible who's involved so you need a data transfer attack suddenly every single multi-party system as well as the blockchain network has to build an off-chain transfer network and that's got to be integrated in 2 anyone who's been involved in one of these big enterprise multi-party systems will know for sure that this thing exists it just is there it's in almost all of them there's some way to transfer data peer-to-peer between the organisations that's then more challenging on the data aggregation side because it comes in to whatever that technology is that's your active MQ of Artemis or whatever it is that you're using Rabbit or whatever and probably you've got a layer of Venture and Encryption that's happening inside of that that's certainly what in Collider we did Kafka was the technology that we chose to use inside of Collider for enterprise projects which is just the technology but you've got this runtime you're going to be working with that whether it's centralized or decentralized whatever it is you've built it, you've got that there and you're also going to have your blockchain node but these work in very different ways messages are going to be batched and transmitted and arrive in completely different order to the blockchain node you just cannot rely on those things happening you still have global ordering in the system so one has to be kicked and here's the magic that's what blockchain can do that no technology in the whole of my career in messaging and integration has ever been able to do it's gold dust that blockchain can do this there's one sequence I guess it's in the name blockchain, it's a chain of events it sounds trivial but it's magical absolutely magical we can all agree on one order of events but because that order of events isn't the same order that the data arrived you need aggregation so you've got to work out how do we aggregate these together and this is the really hard bit that we've put a lot of engineering cycles into as a group what if something doesn't arrive how much of the world stops does the whole world stop they missed one packet of data can I not process anything from anybody anymore because I missed one piece of data can I not process anything from that particular party because I didn't receive that data well actually the way a system should work the way systems work outside of the multi-party system blockchain space is you have an ordering context a topic a block but things on other topics aren't blocks now doing that while preserving privacy and not leaking the same identifier into all the transactions that are on the same topic while doing batching because batching is an inevitability with these technologies you have to batch otherwise you can't get the throughput you need that's suddenly a really hard problem we've seen it implemented many times over and it's just not valuable for the world of the systems to be implementing such heavy lifting complex stuff over and over and over again so we hope Firefly is going to be a place we can come together and get that right and take it away from the poor developers who are trying to meet project deadlines and solve like I just want to exchange data so then we're now going to look at the final part I've made some decision offline that says yeah I off-wise it and I want to transfer data back again and in this particular case it's just messaging it's just messaging I just want to send the data but here's the thing I probably want to send multiple pieces together I'm multiple steps into my business process I've got 10 documents that have been signed along the way as part of this proposal from people some of them came from me some of them came from other people in the system some of them were broadcast some of them were private I need to assemble them together I want to send not one packet of data I want to send a package from me to you and that package is not just going to involve tiny bits of data it's going to involve documents so and this isn't unique to blockchain for sure but you've got this problem in this multi-party system where you don't just want to send one thing you want to send multiple things and some of them are big and some of them are small some of them are blobs some of them are structured data with schema some of them are agreed canonical data formats surely that should be simple as a developer well turns out do it from base principles it's not simple at all you've got completely different transfer technologies that work in completely different ways they arrive in completely different orders like if you've got a rabbit-n-q message on its own you're going to get away like that you do 100 megabyte transfer well tens of thousands of messages on the the event bus might arrive before that 100 megabyte transfer makes it through the large data transfer pipe managed file transfer is what we've intended to call it in the past to arrive there so you've still got the data aggregation problem on the receiving side in order just to deal with this so I spent a bit of time on this one because I think it's really important to understand the types of problem that Firefly is there to solve the fact that you won't find in Firefly super complicated smart contracts is not a sign that those aren't incredibly important they don't fit the model it's just that that's the innovation that we're embracing happening all over the place in the blockchain technology those communities that are building you know ERC-20 my goodness the years that it's taken the trial by fire that it's taken to get that writes fantastic it fits the model bring it on board we're not trying to reinvent that wheel Firefly isn't trying to reinvent that wheel but it is trying to say as a developer writing a web application full stack the backend in TypeScript with Node.js I've spent a whole of my 10-year career getting fantastic at building enterprise software I've been through the microservices revolution I've been through Java Spring Boot and I'm here I want to use blockchain I know how to use the database surely in a day I can do what I need to in blockchain that needs to be true that needs to be true and we really hope and through the lab today you'll sort of feel it a little bit that Firefly is there to make that true for you and the architectural heavy lifting that we're doing which is in the coordination layer the orchestration layer between the on-chain and the off-chain embraces nondeterministic logic embraces manual business processes embraces how hard it is to agree data formats and schemas between a whole bunch of people the hours of meetings we've been in like just talking about are we going to spell address in our canonical format with address line one two and three or with address as one line and everyone's going to like that stuff that's important we need to spend the time there the plumbing cannot be the be all and end all of these projects let's get it right let's make it available just as a commodity service to be used as part of building rich business function that's the goal and the plugin architecture is really important in the core to mean that this isn't just Golang source code that plugs in here this is big projects this is Hyperledger Avalon can plug in this is all of Besu can plug in and all of Fabric can plug in this is all of Corder can plug in this is all of IPFS can plug in this is Postgres can plug in but also Couchbee DB can plug in this is the five different messaging technologies you know NQTT based technologies can plug in and also like core enterprise messaging NQP based technologies can plug in this is I've got ten different ways to write logic zero knowledge proof logic can plug in here off chain secured provable compute with trusted compute frameworks like SGX etc they can plug in here and great communities we're really good close lengths with a community called Node Red which is about how do you build fast really, really prove out event driven programming models with an event driven graphical interface low code building of code that kind of approach can now plug in to blockchain almost every other industries talking about or technology sense talking about you know process automation automated process automation and flow and simple flow and somehow as of yet in the multi-party system blockchain space we've not made it easy enough to have a flow engine to just be able to plug in on top of something now FireFlow right now today doesn't have that business flow engine inside of it and that's a deliberate choice at this stage in the project because that overall modeling step you know composer started with that this deliberately has started what's it started with the developer, the developer's experience matters is where this has started but the idea is to allow that flow layer then start to form on top so I'm going to for the last five minutes of my session before I hand over to Gabrielle who's going to bring this back down to Earthforce you're going to see what you're actually going to be running in a few minutes when you run through the lab the last few minutes I want to just take a little bit of a step back and talk about the project as a whole and some of you know as an engineer inside of a group of engineers there's things that you want to know like is this a community that I sort of agree with is this a community that matches how I feel about how things should be fitted together and that evolves that culture evolves with the community but it's important I think a community to share like what's their mindset when they're coming they're coming in as we start this community building process so I want to talk a little bit about this so we care passionately about blockchain and other multi-party system tech we care passionately about it we don't dismiss it it's not just a time-stamping service we care passionately about it and we agree that in any real-world system that making the ability to consume that logic easy for none blockchain engineers through REST APIs built-in patterns built-in operations for common enterprise patterns that's the way that you get success by not caring about the inside of the engine block that you care so passionately about but by understanding that not everybody when they consume this thing is going to open up the engine block I don't open up Postgres when I use it I use Postgres all the time I don't open up MongoDB when I use it I use MongoDB all the time that's the kind of mindset thinking about the sort of transaction layer data is going to be a mix of public and private it's a reality for this project that that mix is there that's core DNA process orchestration we're really trying in this project because we've done it with real-world projects that we're working with directly in seeding this we're saying yes there's a lot of traction in just you know STO projects in blockchain and other core projects where there's really proven on chain logic but even in those projects in an enterprise context and in all of the other types of projects in supply chain, healthcare, insurance the list goes on the it's not just about tokens there's lots of other use cases that are about process orchestration multi-party process orchestration we need to bridge these worlds together it really matters having an event driven program model that works for these other scenarios but not at the cost of losing things like digital assets tokens and NFTs building into the model and actually one of the reasons why that isn't right there today in generation two even though there was a version of it in generation one is we we feel it's really important to get this one right and that means more discussion so there's a jump into this community like I said Jim Zang's leading it we care really deeply about this one coming right the fact it's not there today is not reflection that we don't care about it it's actually how much we care about that one and then the last pillar is to say identity really matters but here's a really interesting thing about the enterprise use case it's there's two different types of identity that matter in any enterprise use case there's the identity that's visible in transactions between organizations that organizational identity this organization signed off on this this organization approves this because this organization signed off on that it's one type of identity there's also another type of identity that is here is inside of my organization my 300,000 employees they come they go they come on board they off-board we've built the processes for those we've built the identity and access management systems the active directory or whatever we've built that it's not changing just because it's doing a blockchain project the mapping of human beings in an enterprise context down to one chain identity is not a one-to-one thing so that's something that we care about in the project and you'll see a lot of a plug-in for that and some great stuff in the sort of the architecture side that started to think about it and that's something where we've already started some great engagement with the community that's forming here to try and work out what identity means in this context so two more things in the last couple of minutes here that I want to say and I promise then you'll stop because I was on some tech as Gabe was going to take you through I wanted just to cover two more things really briefly the one is where the heck do I find the code brilliant you've shown me where the samples are where's the actual code well it's in hyperledger the stage you're in the process is labs and there were a set of repositories they're all prefixed with Firefly so if you start at hyperledger labs you'll find the first and if you have a look at it you'll find a little bit of an introduction to what it is, what it cares about why it's around and this is actually the container of the core code about 35,000 lines a go that's in this core repository that's the main the main grain of the system, the coordinator but that's not to me that's the most important piece that exposes the API and manages stuff together so you'll then find a link off to a whole bunch of other repositories the command line interface that is so important you'll be using it later that means that anybody blockchain or not can start programming against Firefly in a couple of minutes the UI Explorer which you know we put a lot of effort into hats off to Alex and Brian and the team who've been seeding this to really make it so that on day one humans can use this thing, human developers who haven't been in blockchain the whole time don't think in hashes can use this thing and a bootstrap for operational stuff as well a data exchange out of the box which Gabrielle led the engineering on which performs mutual TLS based transfer which where most projects have started it's where Tesla for example used off chain coordination but this is all very much about plugability as well and we've proven the model with as I said with Kafka and then to end the encrypted messaging in the past and then connectors for the blockchains that's an evolving space if connectors another piece of really trope by fire engineering that we contributed from the collider side to seed the project so that's become part of the Firefly family for Ethereum quarter there's a lot of work that we've done that's evolving the merging the moving across of that is happening at the moment if you go to the repo you'll only find part of it event streaming in quarter is something that we've done a really lot of work about as well as kind of building an ordered stream inside of quarter it's not like a block based system is like core that you get out of the boxing in quarter with the UTXO model so we built that on top and that's there as well and then fabric is just like fantastic space that you know with people like Jim and Nick on the team who've been there since the inception of fabric it's something really dear to our hearts as a team and we want to get it right and it's such an active community that actually what's happening there is working with the fabric smart client project to work out the white coordination between logic goes where how we have the white separation of concerns between the code that's being evolving between those two projects so you'll find links to all of that stuff there and then a whole load of detail on the architecture including the periodic table of elements if you want to look inside of the codes you'll see the core broken down a little bit more we've assigned all of them a two-letter prefix it gets used in the go code in various places and you'll see the core components, the network map, broadcast manager, the private messaging manager, the data manager, the event manager, subscription manager, the asset manager, batch manager are all the core pieces of core but then really important stuff right the plugins, the blockchain interface we even have a fake blockchain that's implemented inside of there as well but Ethereum, Core of Fabric plugins IPFS is the first plugin for the public storage interface HCP directs mutual TLS for the off-chain interface identity mapping at the moment, simple mapping of whatever's on-chain identity is your identity that you know the Ethereum address or the quarter certificate name or the fabric certificate name that is your identity but this is a plug point for great things like DIDs etc this one's still evolving but external authentication OOF integration for that part of the authentication which is mapping two keys the stage before you get to the identity interface a database plugin which at the moment we've done SQL first interestingly enough the last generation did no SQL first, we've done SQL first talk about that in the off-line and then the eventing interface where we started with web sockets because it's so great for developers, just where developers live nowadays so we started there's way more coming coming here that we've already got in the works okay I'm going to stop talking now and I'm going to hand over to Gabrielle who's going to bring his deck down to earth and we're going to talk about the what you're going to be doing and seeing for real in your lab Peter before you transition there's just a question in the chat here that thought maybe there's some nuance too so I wanted to raise it to you Louis said we could send data privately off-chain from org one to org two now you question doesn't that mix with fabric multiple channels and private data that is an absolutely great question so we believe from experience that they're complimentary that they're complimentary and there's actually a construct inside of the firefly core model called a ledger which is designed and intended to map to things like what's the scope of who validates my transactions that's the channel model what we've seen is that there are cases where you have data but for whatever reason doesn't actually fit a blockchain at all doesn't matter how much you restrict the parties it doesn't fit the blockchain or this is a really interesting one there's data where you need to prove and have proof with a larger set of parties that have visibility of the data so the channel might include the supplier and the purchaser and an auditor but the visibility of the data that goes between the supplier and the purchaser might be different to the data that goes between the supplier and the auditor and the purchaser but they might all want to see the same events in the same order on the same channel and you just got a practical problem if I want to send a 1 gigabyte file am I going to send that through a channel with the on-chain data probably not that's probably going to be an off-chain transfer am I going to send a scan of somebody's passport on a blockchain well maybe I'm going to be thinking the benefit of blockchain is it's immutable and I'm never going to be able to delete this thing does that does that fit if I put it on a blockchain or I have to delete the whole blockchain if I want to delete that data maybe it's just easier maybe it's going to save me a year of regulatory pain to not put it on the blockchain directly and put it into the blockchain so we embrace the synergy between the sets of privacy in a session earlier in the week Jim went through the different versions of privacy that exist it's only a 15 minute segment and then we do an intro to a firefly afterwards you might want to listen back to that because they fit they fit together they're great Lego bricks that you can use as a device system and all fireflies trying to do is to say you should have access to all the Lego bricks it's not trying to say this Lego bricks better than that Lego brick it's just saying as a reason why there's different shaped Lego bricks and when you're building your solution you should be able to fit them together in the way that's actually going to give you the velocity that your business goals need so hopefully that answered the question a little bit there and actually while you're talking Peter we had a second question come in which I think is a pretty similar vein asking about support for Tessera and other potential enterprise layer 2 solutions and Tessera of course is the private off-chain mechanism that sort of comes in the box in Ethereum and Quorum and that's it another great question so right now today Generation 2 Firefly Code does not have an implementation of a a core integration of Tessera however the blockchain plug-in partners with it which is Firefly ETHConnect has direct integration with the Tessera and EDA private transaction model built in at that layer and the glue needed to just make that linkage work is trivial there's an interesting thing with Tessera of does it fit more as a plug-in as this ledger concept like a channel does or does it just plug-in underneath the blockchain interface and that's something that I've personally been thinking a bit about and I'm looking forward to that conversation in one of the upcoming architecture sessions and hopefully that's a great area where we can have a contribution because that is a in the framework I actually think that's a pretty easy one to solve pretty easy one to solve so that would be a great area to start bridging the the communities here and we're great friends the the team ambassador and the team in collider and me personally and others have been working together for so many years I think we can just make that happen so quickly