 And what I'd like to do is talk about Firefly, which is a great new hyperledger labs project. And we always want to support the new hyperledger labs projects in the meetup groups. And so today we're very pleased to have both Peter Broadhurst and Nico Geier from Kaleido who are joining us today to talk about this new hyperledger labs project Firefly. And let me just give you a little background on Peter and Nico. So Peter is the co-founder and engineering lead at Kaleido. He has 15 years of experience at the intersection of enterprise middleware, cutting edge cloud architecture, and also mission critical customer engagements. His specialist domain is enterprise middleware. And he's worked on every stage in the software delivery cycle in core messaging application server and integration of technologies that interface with blockchain. And he's also the author of a vast majority of the Firefly code database or code base that we're going to be talking about today. And then we also have the pleasure of having Nico Geier on he's a software engineer at Kaleido. And he's also the open source community leader for the Firefly project. So those of you who want to engage with Firefly after this event, Nico will be a good point of contact for you. His background is in designing, building and operating enterprise SaaS systems at every layer of the stack. And he's also an innovator and technology evangelist who loves helping people learn about new technology. And he's also the primary author of the Firefly CLI that we're going to be talking about today. So at this point, I'd love to turn it over to you gentlemen and let you take it from here. Thank you, John. I really appreciate it. So, Peter, I'll hand it over to you if you want and go through kind of Peter has a couple of slides and then I have some slides as well. So the goal today is to really give you an introduction. First, we're going to talk not too long at a high level about the goals of the project, its status, what it's trying to achieve, really what makes it different and quite unique within the Hyperledger stables here. And we're then going to go into a more technical session about how you get started with it, the things you can use it to solve right now today. And Nico's going to go through a great sort of technical presentation, but also we'll get down to some demonstrations of the APIs and maybe the samples as well. So that's the flow here. I want to kick off with the slides. Firefly is at its early incubation phase in the Hyperledger family, which means it's a labs project at the moment and is actively working its way through to incubation stage as a fully fledged Hyperledger project. It has a very rich code base. There's a lot of capability already there. And the actual pedigree of the technology goes back for a number of years. And we'll talk a little bit about that. We move forward with one slide here. I want to just give you a little bit of a high level overview. And this is really also what we're going to talk through in this slide section around what Firefly is, the problem that it's there to solve. And Firefly is not in itself a DLT technology. What Firefly is is an orchestrator, an API server, a developer centric platform with a user experience, CLI, and an API to make blockchain tech work for a modern multi-party system. And this concept of a multi-party system is something that we're going to talk quite a bit about in this presentation because it's really where the blockchain technology is at right now. So we're going to move forward to one more slide. The interesting thing about the blockchain space at the moment is it's still nascent. In Collido, we've been in this for more than three years that Collido's been around and the technology's been at the edge of wide adoption for that whole time. And it remains there particularly in the enterprise sector. And there are a number of reasons why it's still in this nascent position. A lot of them are around actually the gap between the technologies out of the box and the needs of an enterprise network. You have the lowest of the low level plumbing comes out of the box, a DLT and you have to plug it together with all of these other. We found somewhere between 10 and 50 components you have to plug it together with before you have something that actually solves a use case in an enterprise context where the amount you can actually put onto a completely shared DLT where the data can never be deleted, where the data is shared with everybody who's maintaining that ledger even if it's a fabric channel you're going to have a number of people maintaining that ledger. That's a small piece of the puzzle. And if we move forwards one slide, the journey that we've seen played out time and time and time again is that a group of organisations trying to solve a problem in a new way to build a multi-party system comes together and at the beginning they think all we need to do is write some smart contracts and we're there. Well, we'll deploy some stuff, everyone will run their infrastructure and we'll connect together and we'll be done. You know, we'll have a few components, four to six months we'll be there. And the reality looks completely different. As you look at your use case, you look at the data involved, you look at the shape of the problem you're trying to solve, you realise we need a rich user experience, we need great APIs, we need to integrate backend data and actually the blockchain can be used as one fundamental building block, one Lego brick that makes up the overall solution. But we need all this plumbing that just does not exist. How do we get these organisations to be able to come together and solve a problem? And actually this middle piece, what the job becomes is 10 to 40 components, two to five years in the making and a real difficult journey to proving an actual piece of business value. We know from experience because we've helped organisations do it within Colloido, we know that it doesn't have to be that way. And the job ought to be, you model the things that are actually unique about your use case. You take tools that work off the shelf as engineers that are built for you as developers. You put them together, you build your solution and you go. That's the way everything else runs, it's the way you're used to building applications everywhere else. Why can't blockchain be the same? And if we move forward to a slide here, the reality of what you want to build in a multi-party system, what makes it valuable is what you need to build is a stack. A stack of software that includes the blockchain also includes the off-chain private data exchange pipes that are needed for the non-blockchain pieces. Also includes which APIs a local data store that's for your private data that you may or may not have shared with anybody in the network gives you a complete picture of that and provides you with great APIs to understand the core building blocks like tokens that give you APIs that let you interact with the blockchain, not being a blockchain developer. So that you can build a network where each member can run this stack, the job of running it is achievable, maybe run on a hosted platform like Kaleido, maybe run just completely independently, but it needs to be easy to run, it needs to be suitable for the kind of enterprise data and core integration that you need to do, and it needs to let you build great user experiences, great APIs quickly on top of it because the use case only exists once that's true. Move forward to one more slide here. And I guess we find it's pretty astonishing that Firefly seems to be the first open source project focused on this aspect of the problem. And it's really early in its life cycle with a significant durable code base there that's been seeded from a number of years of experience and production code from the Kaleido's background, but actually the community is just forming. We're about six weeks in to the forming of the community here. This is a great opportunity to get in at the ground floor on an open source project which is really trying to solve the... taking the potential of these technologies like blockchain, like the more advanced compute technologies and make them consumable for developers and ecosystems that want to solve business use cases, not build plumbing. So we've moved forward to one more slide here. A parallel and not to be too grand about it because I'm very early in the journey here. We know for sure that the blockchain-DLT space needs for it the same kind of acceleration that we got when Kubernetes formed on top of Docker. We think back to people like me who were using Docker in the very early stages and you saw the sort of potential to take any piece of software and put it in a box and suddenly that software could just be run and deployed. It seemed game-changing. It seemed obvious that this is going to change the world, but actually anybody who built cloud services on it in the early days, you found you spent all of your time building the orchestration layer on top and there were multiple orchestration layers in very, very early phases and you could see how much work you had to do on your project before you could actually build anything useful. Now we're at a stage where it's just ubiquitous. You start from Kubernetes, you build your Docker, they bring them together and what's fantastic about the Kubernetes ecosystem is it's pluggable to any cloud, it's pluggable to any storage. It's got all of the patterns there to be able to onboard all of the technologies, the operator construct. You can plug in anything you like. Suddenly building projects in a cloud-native way is a hundred times easier than it was when I was first building cloud services and that's the journey that the industry is on and we hope that Firefly can be part of that journey here. So what is Firefly in itself? So Firefly is an API gateway and a plug-in infrastructure and a microservices architecture for building that stack, that set of software that needs to run that you can build a multi-poddy system application on top of. And really what a multi-poddy system is is separate autonomous organizations that are running their own copies of the various application use cases, the UIs, the APIs, the integration capabilities that are running their own copies and they're communicating. And almost certainly, because you're doing it in the modern era, you're building a modern business ecosystem, blockchains the beating heart. And other advanced cryptographic technologies like zero-knowledge proofs, like trusted execution environments, may be part as well. However, because the whole value is these are enterprises that have sovereign data running in a decentralized way, that guarantees, it's a 100% certainty that they're going to have a different view of the ecosystem. They're going to have different data that's unique to them. So what Firefly does, what a Firefly node is, if we go forward with one, is we think of it a little bit like a periodic table of elements. It's a pluggable surface area to take all of this kit that you need, the blockchain nodes, the smart contracts that you're going to plug in that have been built by others, like fantastic tokens projects for fungible and non-fungible tokens. Great projects that have been built in the low layers, zero-knowledge proof projects, etc. You can take those as building blocks. You can plug them together with the building blocks like private data exchange, messaging, large file movement, like great pieces of the puzzle like IPFS for sharing data that isn't suitable for the blockchain from a size and shape perspective, but is suitable for distribution to everybody peer-to-peer. And you can assemble them together. You can have a UI out of the box, a great API which we're going to talk about a little bit later that's designed for you as a developer that conforms to sort of the modern principles that you would expect is event-driven, so it has things like web sockets and webhooks built in so that you can just get on with building your application and it's pluggable. So by building to the Firefly API set, you aren't tied to a particular technology set. We move forward one more here. One of the things that we really are making this true, this isn't just slideware. We've done this in previous generations and are doing it in the latest generation of the Firefly code base. Even the blockchain itself is pluggable. The big three are there. You can build an application that's for the standard things that should be the air and water of any multi-party system. Being able to pin data, being able to sequence things, being able to put things in order in a block in a sequence between a set of private parties, being able to share data on-chain and off-chain, fungible and unfungible tokens. I think of them like the crud of a multi-party system like you would have for a database, create, retrieve, update and delete. Those fundamental constructs, you can just build on top of the Firefly APIs and plug in from the community contributions of the big three, your chosen blockchain platform and the same plugability in databases, the same plugability in messaging. You can assemble together those components and you can have an application built for Firefly. A very important point here is also you need that pass-through so that when you want to expose and really utilize the unique features that are only there inside of a particular blockchain technology, custom on-chain logic for that particular technology set, features specific to them, but there's also a way to pass-through, to break through the barrier and get to that full suite of technology as well. But you can see that this goal is about less about building inside of these and more about an umbrella, a way to bring together these technologies to break down some of the silos between the communities and to focus on the people building the apps. Not as we are quite insular in the blockchain community a lot of the time, think about how cool the internals of the tech are. To say it's great that how cool that internals are, this best atomic swap contract that we've just built, that's fantastic. How do we make it so someone who doesn't understand atomic swaps can use it and get value of it? That's the goal of the technology suite. Let me move forward to one more slide. So when we think about what Firefly is and we consider the fact that it sits sort of on top of the blockchain and around the blockchain integrating that together with the off-chain pieces, the question becomes, well, what does it add? What does it take away? What does it extend? I just wanted to point out that it's both. It's about leveraging this fantastic capability. But for my whole career was not there. This ability to have a shared source of truth between enterprises and to embrace the fact that that's true, leverage it and extend it. So to take from the blockchain things like global ordering and finality that were impossible in the days of REST APIs and messaging when we were building these ecosystems before and to make that available and then to extend it with great REST APIs, built-in patterns that bring things together to then combine that with data and all of the things about data that were true before blockchain, data that's unique to individual parties, data that's private, data that is very sensitive and regulated, data that is small and JSON based and structured, data that is hundreds of megabytes or gigabytes and unstructured, bring it all together and on top of it allow the pinning and the joining together of those technologies and then to be able to build layers of information on top to build genuine multi-party business processes in a simple way using an event-driven model and to pull in those constructs the air and water of blockchain solutions like digital assets, tokens, NFTs bringing them together to have pluggable identity to be able to know who did what when in an ecosystem while retaining the right levels of privacy and data and data sovereignty. So that's the goal. And then just the last slide that we're going to talk through, I'm sorry there's two maybe just go on to the next one. I just wanted to talk about the evolution of this technology and we'll see the user experience here I'm going to see this in action a little bit later but we move on to the next one the journey that we're on the phase that we're in and the right-hand side of this is the really exciting phase it's the birth of Firefly but I wanted just to give you the background that this isn't just a fly-by-nights brand new flash-in-the-pan idea this is the culmination of and many years of real blockchain projects learning what actually building a multi-party system needs. Now it's been seeded Nico and I are both from Collido there's other organizations involved and you can look at the Hyperledger submission you'll see some of those sponsors from the projects themselves it's come together from a lot of componentry much of which is used in production today but what we did when we went through sort of phase one of the plug-and-play services and we went through and we built the first brain which we call Collido Asset Trail when we did the next generation of this Firefly we actually rebuilt the core from scratch not all the plug-in pieces not the ecosystems for the different blockchains not the off-chain components but the core itself we rebuilt it and we rebuilt it so that it could be suitable for open source and plug-able it could be the platform that fits a modern open source project written in Go has a plug-in architecture that really supports a community coming together and building something so that's the journey that Firefly has gone through and we've been really enjoying the collaboration over the last six weeks or so when we've been doing this as a group rather than doing it as an organization and it's a really exciting time to get involved so that's enough of me talking we're going to now go onto the bit I think I'd enjoy if I was listening which is we're going to talk about what it does, how it works I'm going to hand over to Nico who's going to go through a set of slides thanks Peter, I really appreciate that great introduction so there's a lot that we can talk about in Firefly this I'm a software engineer and talking to software engineers so this is going to be developer to developer here the way I would like to approach this is to talk about some high-level concepts in Firefly then we'll look at some specific examples of JSON payloads of like how do I do this and more, how do I do that then we'll actually, I'll switch screens I'll screen share and we'll do some hands-on live demo stuff so that's kind of how we're going to break it down so to talk through some of these concepts we have a small cast of characters here which you may recognize from public private key signing and or other computer science stories Alice, Bob and Charlie and so Alice, Bob and Charlie work at different organizations they all work in the same field though and their businesses want to do enterprise business transactions with each other and they want to power it all with blockchain so Peter already gave a great introduction to what is Firefly so I won't spend a whole bunch of time on that but it's essentially, Alice and Bob could deploy blockchain nodes and set up a private chain but then how do they actually get data back and forth or there's a ton of infrastructure that is you need on top of that to have an effective enterprise multi-party system and that's the gap that Firefly seeks to fill, it's a it is a standard that organizations can use, Alice can run a Firefly node, Bob can run a Firefly node Charlie can run a Firefly node and then they can all collaborate together, they can run these enterprise transactions there's a ton of different things that they can do and we'll touch on each of these in detail in a little bit but there's options for sending data publicly or privately things can be pinned or un-pinned there's event-driven and request reply models, there's lots of features, there are some features that are still in the works such as fungible tokens, non-fungible tokens and custom on-chain logic so but there's a lot that's already there so we're going to start with what's here, what can I do with it today so the first thing that I think is probably makes sense to talk about is like how do I get data from one person in the network to the other so in a Firefly network we talk about we sort of use the terms member or organization interchangeably so Alice, Bob and Charlie are all members of the network and they're at their respective organizations so Alice has a piece of data here that she wants to distribute to all of the members of the network so she can do that via a broadcast, it is a public message, anybody can see it the hash of it will go on the blockchain and it will be there for anybody to look at so that's great when you want to just announce something to everyone else in the network but what if Alice has a piece of data that she only wants to send to Bob, well you can do that too there's a different API endpoint that you can use to privately send data to a one member or a group of members and you can select who has access to that data so those are kind of the main concepts of you know you can broadcast or you can send privately and we'll look at examples of how you do each of those here in just a little bit the next thing kind of decision point you can make is whether you want the data to be pinned or unpinned so in the case that it is pinned it gets pinned to the blockchain but maybe there are use cases that you don't want that data to go to be pinned to the blockchain and so there is a separate API endpoint or sorry a separate transaction type for that as well in either of these combinations you can send either JSON data or blob it can be a binary file that data can be in line in the request sorry about that my camera has okay I think we're back a camera froze there for a second the data can be in line or it can be it can also be linked and the data can be made public or private for either of these so now I want to talk about just the a couple of interaction models with the API the event driven model is probably what we expect the 90% case to be used and so the event driven model it allows for for higher throughput so if you're used to building asynchronous applications this will sound familiar so Alice has a piece of data she wants to send to Charlie prior to her sending this this data actually nevermind sorry I was we'll get to that in the next slide so Alice has a piece of data she wants to send to Charlie so she makes an HTTP post to the Firefly API for the sake of this diagram I've simplified the communication here so they're Firefly nodes talk but but once Alice's Firefly node has received the data she immediately gets a 202 accepted back and that says that Firefly has received her request and it will process it at some point in the near future Charlie's Firefly node receives that message and then sends the message to Charlie it could come over a web socket or a web hook depending on what Charlie's application is set up to receive once Charlie has received and his Firefly node has processed the message Alice will get a confirmed event back and that's that's how she can be assured that Charlie's received this message and whatever he decides to do with it at that point is up to him so like we talked about these can be pinned or un-pinned the data could be JSON or blob and all of those things apply here in the event driven model there's also a request response model so if Alice is building her application to make a request and expect something back in return before she moves on you can use the request response model it is obviously going to be higher latency as we described the flow you'll probably see why but Alice makes a post request to the Firefly API that she does not immediately get a response back instead what happens is Alice's Firefly node transmits to Charlie's and then Charlie at some point prior has set up a subscription we'll talk about what subscriptions are how to set them up in a little bit and he will receive this message over a web hook his application will respond with an HTTP response this could be an app that's designed specifically to work with Firefly or it could be a legacy system or just some other HTTP server but as long as there's something on the other end that responds with an HTTP response Charlie's Firefly node will wrap that up it will send it back to Alice's node and then she will get the 200 okay with the payload of whatever Charlie sent so that's the request response model you can see how it's obviously going to be higher latency because there's a whole bunch more hops here involved until the response comes back to Alice I just want to very briefly touch on the plugin architecture of Firefly and kind of highlight some of the pieces in it Peter alluded to some of this earlier but so Firefly is designed as a as a microservice architecture and so there is a Firefly core the core is written in Golang but Firefly itself is a system that has a whole bunch of different parts to it and all of those parts are swappable via plugins and so it is it's extensible it is it's customizable if you have specific needs for a certain technology that may be optimized in a different way than an alternative you can write a connector to connect to that plugin very easily so everything from the blockchain layer right now we support Ethereum out of the box and I realized yeah so I thought I had a spelling mistake and I hand wrote these slides so there's no spell check on paper unfortunately so we support Ethereum out of the box fabric and core to support is in progress in active development now on the database side we support PostgreSQL and also SQLite public storage we support IPFS it just it makes sense it's a distributed public file system so it makes it's the perfect fit for building distributed decentralized business applications but other things such as the identity system the data exchange and the event transport are all pluggable as well so it's really cool architecture and I definitely love to see takes this extensible architecture in the future in integrating with other systems okay couple other concepts that I want to talk about real quick and then then we'll actually look at some real examples I promise so namespaces namespaces in Firefly are a great way to segregate data or just group messages and data types that are related to a certain thing so there is a default namespace that is available out of the box or you can define custom namespaces the namespace can be advertised to everyone in the network and then all the other members will be aware that that namespace exists and messages might be coming in on it reasons why you might use a namespace they're useful for testing so you might have a test namespace where you run some transactions to just make sure your network is set up correctly or you might be running a test app to exercise it but you don't want all of those transactions and messages sort of polluting the main data space for your application it uses blockchain so if you run a pin transaction it's there forever so the namespaces give you a way to sort of group data that you may not want to see in your main application or you may be running multiple apps you may be running sort of a multi-tenant system a namespace is also a great way to group the data by application or by tenant or that sort of thing so you'll see in all of the API endpoints that we look at most of them will all be prefixed with a namespace and so that's what that's there for next concept is messages this is in the world of computer science the word message is rather overloaded but firefly has its concept of a message so everything when Alice wants to send Bob data and wants to reply to Alice all of that data goes in a message so I can send firefly a message and firefly can notify me of messages that have been sent to me as well a message can have multiple data elements there's a header section where you can define information about how the message should be delivered and that sort of thing and we'll look at some examples here actually I believe that is my next slide shift gears now and look at some JSON after we look at just a couple of examples I'm going to share my screen and then we'll actually try it and fingers crossed that live demo will actually work the way it's intended to it's always exciting so this is the simplest of simple messages that you could send in firefly I could I could post this to the broadcast message endpoint and that would send string hello world the value here could be a JSON object I've just made it a string to make it simple you'll notice data is an array so I wanted to I could actually send multiple data elements all in one message this is still one message but I've just attached two different pieces of data to it so I could broadcast that data if I posted it to a broadcast endpoint but what if I just want to send to what if Alice just wants to send a piece of data to Charlie and not Bob in the network so maybe there's a piece of secret data doesn't want to advertise to the entire network there's a separate endpoint for that and then within the payload here we have this new group object that we added to the message within the group we have a list of members and we put the members identity here in this case Charlie will pretend is an identity that's registered on the network and Alice could send this message just to Charlie and it would not go to Bob Bob you probably notice that members is an array so if I wanted to send both to Bob and Charlie but not Frank or somebody else that might be on the network you could extend this by just adding more identities to the list of members okay let's talk about a couple other concepts on messages so messages can have a tag and a tag is intended to indicate to the other members of the network how this piece of data should be processed you could think of it as kind of like a function call or it is an indication to the other member of what they need to do with it so in this case maybe we have a customer order and the payload here is the data about the order but we set the tag to new order placed to indicate to the other members of the network that this is a message about a new order that just came in rather than maybe a message about an order being returned or canceled in which case the data would obviously be treated very differently in those cases so that's what a tag can be used for. Messages can also have topics topics is an array you can have multiple topics that's a little bit more of an advanced topic sorry terrible pun or use of word so in this case you know kind of building on our customer order example we can use the customer ID as a topic and what this will do is it will ensure that messages that share a same topic are ordered and need to be confirmed and acknowledged in the order that they have been ordered on through Firefly's ordering system powered by blockchain so if there is a default topic that is used if you don't specify as a custom topic here but that's a way to sort of maybe have lots of customers that are at various steps in a flow you could isolate those so that one doesn't block the other while they're being processed by using separate topics here. Another example so you're kind of going back through my earlier slides we talked about how you could you could pin transactions to the blockchain or you could have them unpin and have them off-chain if you needed to so this is how you do that there is a back in our header section on the message you can define the transaction type if you set that to none that will indicate to Firefly that so the options right now are batch pin or none and so none means don't pin this to the blockchain this is an off-chain operation and so in this particular case I'm transmitting your top secret data to Bob so this will be a private message send that is not on the blockchain and this would only go to Bob okay that is it for my slides at this point I'm going to shift gears here and share my screen and hope that our live demo works here alright I should be sharing my screen Peter or someone else on the call can just give me a quick thumbs up okay excellent excellent thank you appreciate it okay so as a developer when I'm learning about a new system I like to get hands on I like to actually try it I like to run it all on my own laptop if I can and that's exactly what we've built the Firefly CLI tool for so Firefly CLI this is the GitHub repo for it it is written in Golang you can install it by running go install we have plans to distribute binaries like through brew and other package management systems but for now you can install it through go install or go get and I'm going to show you what the CLI will do right now so the CLI is designed to build a local test environment we call that a stack so I can create a new stack by saying ff is the binary name for the Firefly CLI I can say ff init I'll run that and it'll ask me hey what do you want to call this we'll call it demo it'll ask me how many members we want in the network and I'll say three so it's generated here a Docker compose file for me I'm going to go ahead and start it and then while it's starting up I will describe what it's doing so I can go ff start demo okay so the Firefly CLI wraps Docker compose and we're using Docker containers for all of the parts of the Firefly system that periodic table of elements that Peter talked about all of those different things are going to run in various containers so for each member of the system there is a Firefly core, there is an IPFS node, there is a data exchange there is a blockchain connector in this case the default out of the box here is deploying an Ethereum stack and so it's going to use Firefly ETH connector there is one blockchain node that they all end up sharing just to reduce the number of containers running and the default out of the box is also to run with SQLite you can choose if you want SQLite or Postgres when you set it up again to just keep the number of containers down we went with SQLite out of the box so you can see my containers are coming up it's now doing the registration so it's registering each of the organizations and nodes with the other members of the network and we should be wrapping up here pretty shortly and then it will print out some more information on how to actually look at what it created okay there we go I timed that just right so it says we've got a web UI for member 0, 1 and 2 so continuing on with our cast of characters here number 10, 0 is Alice 1 is Bob and 2 is Charlie so I can go here I'm just going to open up each of these interfaces and then I'll try to so you can notice that they're all running on localhost because this is all running in Docker on my computer but they have different port numbers so I'll try to I realize there's going to be a lot going on here and I'll try to indicate based on the port number whose screen we're looking at Alice's Firefly UI so this is a UI explorer that comes out of the box with Firefly that lets you see we can see there's three members in this network we can see the history of messages and transactions and data that has been sent through the system and so over here we've got this is Bob and this is Charlie so now I'd like to hop over to Postman and actually start making some requests oh before I do that I'll point out I just want to make a quick call out to the docs in case you want to find out about the the API go to labs.hyperledger.org the API spec is right here on the page you can also get to this through the if I go to one of these nodes instead of UI I can go API this will also give you this swagger is actually generated by the application but if you don't want to set up a whole stack and run the application you can go here and see the same exact thing so you can just browse to this page and see these are all the different endpoints on the API so the first thing we're going to do is we're going to broadcast a message so that's going to be a post to I've made my font a little bigger here so you all could read it and it's kind of cutting it off but namespaces slash broadcast slash message excuse me so like I said this is the original example that I had which is the maybe just make a little bigger is that better? that's fine thanks for the heads up alright hopefully that's a little more readable this is what I call the simplest message ever so we're just going to this is a post to broadcast message and we're just going to say hello world and then so just to describe our story with our cast here this is port 5000 so this is Alice broadcasting to the rest of the network we'll hop back over to Chrome and look at okay so we see in Alice's UI we can see there's one message that has succeeded we should be able to go to Bob's UI and he sees the same exact thing and so does Charlie it was a broadcast so they all got that message we can go to the data tab and look at it and we can see there's the message hello world so that the actual payload of the data was stored in IPFS and this was an on-chain transaction so the hash of it there is on the blockchain and there we can just sort of look at the whole thing so this is a great way to see you know kind of what as you're testing your application you can peek at the network from the perspective of any of the members on it and kind of see what is going on under the hood alright so that was the simplest thing we could do let's try something else now so let's say Alice has a piece of data that she wants to send to Bob in this case Bob is org one but we're still this is Alice's API that we're using here so here we're going to post some secret data called a secret message so we should see this message show up on both Alice can see that she sent it Bob can see that he received it Charlie should be completely in the dark to what the message was and indeed there we go so there was also another thing that happened here there was a group in it that went through so that's that's basically Alice's Firefly node saying hey I'm sending a message to a select group I need to define that group ahead of time before I can send messages to it and that's that's why you see that that's why we're our message count now is up to three because we initialize the group and then send the private message so this is Alice's UI let's hop over to Bob's Bob sees the same exact thing over here you can see the same same message this was this was pinned to the blockchain and we can go to data and there's we can see our secret message there now so this is this is Bob's UI the message was sent to him if you go look at Charlie's UI Charlie has no clue what just happened he does not have a message about that so that's that's an example of sending private data alright let's look at so this this is this if I wanted to do the same thing but not pin it to the blockchain I could set the transaction type to none let's see for the sake I want to leave a little time for Q&A so for the sake of time I'm going to skip ahead so I want to show the the request response model as well because that's that's kind of interesting so backing up for a second here what we're going to do is Charlie is going to set up a subscription Charlie's going to set up a subscription to send events for a certain topic to just an API some URL on the internet that happens to be this request bin that I have set up here so basically HTTP requests to this address will show up here if you're watching please please don't make spammy requests to my URL during the demo thank you so essentially this this is what a creating a subscription looks like this we will make a post to subscriptions and we'll say this is we're going to call this fictitious example this will be the banana handler so anything with the tag banana will go to this endpoint we can define some options on the subscription so this is you know where it will go so it's going to go to my request bin address slash banana we want the reply on it and then we're going to tag the reply with a banana response so that will come back with the tag which Alice could have a subscription set up to handle that particular banana response in a certain way as well and we want it to make a post to there so this is what a subscription looks like we're going to post this to I think I said Charlie earlier we're actually going to this is Bob's address now that I'm checking it here so Bob's going to set up the subscription we'll post that comes back with an ID subscriptions can be updated by doing a put on them you can delete them to get rid of them and you can also list them by doing a get on slash subscriptions as well okay so now we're going to go back to Alice's API and so we haven't sent any messages yet in this transaction and Alice is going to send a message with the banana tag and for the sake of the example we're going to send a JSON object payload this time instead of just a string and here I've defined the group as just org one and this is this is Bob so this is going to be a private message unpinned request response from Alice to Bob hopefully by this point that makes a certain amount of sense so we're going to send it latency was a little bit more there not too bad we're running a lot of this locally so and then we can see we scroll all the way down here this is the payload that my request been responded with so it said 200 okay it's apparently they're using an express web server because it's powered by express so we can see their headers are on there and then the response body was just success true so now if we hop back over to our browser and look at our request been we can actually see our request that we made there so it was a post to slash banana because that's where we define a subscription to send those things to and we can see this is our payload that Alice sent to Bob so this is how you know if you want a subscription is how like if you want a web hook to send request to your application to actually handle them and execute your specific business logic that you have for that type of message that's that's how you can do that subscription it's worth noting that subscriptions are not inherently tied to the request response model a subscription could be a web hook as well I don't have time to demo both of them but just wanted to to kind of demo those pieces so we could look and now we see Alice has five messages Bob has five for Charlie he's only got one over here so that is it for the hands-on demo and I'm going to switch back to my camera here and I wanted to conclude with I had one more slide and I actually forgot to put it in my deck but it's okay it was just some text so just wanted to wrap up with kind of describing what's next for Firefly so in development right now in very active development are connectors for Fabric there's code up on github that folks are working on right now building that out we're working on the Cordo connector as well coming soon but I don't in various stages of getting started are token support for fungible tokens and non-fungible tokens and also support for custom on-chain logic so that's kind of the I'd say the near term roadmap for big things that we know we need to have in Firefly that we are working on I also just wanted to take a moment and say like this is an open source community and if some of the things that we've talked about here today or some of those upcoming things sound exciting to you we would absolutely love to get you involved so thank you for coming out to this meetup hopefully this gave you just kind of a good introduction to what Firefly is some of the basic concepts with it and enough that you can kind of get your feet wet with the CLI try it out I'm on rocket chat through hyper ledger I'm also available to email so you know if you are getting started please reach out and I would love to help get you plugged into the Firefly community and we would love more contributors and we would actually love maintainers as well as we advance the project so definitely want to get people plugged in and involved thank you very much and I will we've got about five minutes left for some Q&A and then I'll hand it back over to John after that yeah great presentation gentlemen that was really informative and it really like looks like a great piece of the software stack to leverage on hyper ledger one of the questions I'll have and then we can look at anyone else who wants to maybe come off mute and ask the question directly is just in an enterprise setting it sounds like this would be very applicable to maybe the property insurance world where there would be a claim that would be submitted by a customer and they would say okay we we have a claim against our house insurance and then the insurer would review that and then they have a public database which is the clue database and they would be able to go ahead and share that claim history with the public database once the internal messaging was all straight now and the claim was approved by the insurance companies that sound like a good use case I think it sounds fantastic it does and one of the sponsors of the Firefly project was actually the institutes and particularly the Weststream collaborative that's part of the institutes and that's actually a network of a very long standing network of insurance companies so we certainly have a lot of experience have it applies in that industry and it's a really any industry that has a problem of siloed data of there's some kind of something that's happening in the real world that needs to involve multiple organizations and different parts of that need to happen between those different organizations it's a great candidate for a multi-party system it's a great candidate for blockchain and you're squarely in the wheelhouse of what Firefly has grown up trying to solve it's not just about security token offerings the world of blockchain the world of problems that DLTs can solve in a way that was impossible before DLTs came along is really white and I think that was a fantastic example there were examples in healthcare was one that came up on the chat there's great examples there's examples in supply chain you just think about how many steps it takes to let a ship leave port or post trade settlement how much of that is about private, very sensitive data exchange that's kind of backed by blockchain but it doesn't all go on the blockchain it just never does those are the sort of problems that this technology has grown up trying to solve yeah I see extreme value in that and I agree with you when you're talking about an industry consortium and multi companies involved there's obviously private data that they don't want to share with the consortium however there is data that they do want to share with the consortium and I really think that your application layer really enables both components there okay perfect so and I appreciate both of you and the team answering all the questions in the chat and at this point if someone has a specific question that maybe wasn't covered in the chat and they'd like to come off and ask it directly just go ahead and let me know and if you want to raise your hand great if you want to just come off chat that's perfect it sounds like here's Ramaro and he would like to be a contributor for Firefly and I think anytime we're talking about a labs project we always want to make sure we're getting contributors and maintainers engaged early to ensure the success of the labs project so maybe you want to talk a little bit more about how to get people onboarded we put a lot of stuff in the chat and maybe even skillsets and everything else that you might be looking for so I'm pulling up a link here real quick to the our rocket chat which is probably the best place if you want to chat with folks on the project that's the best place if you want to engage in real-time chat with maintainers and other contributors on the Firefly project you can find us all there so if you have a Linux foundation ID it's a free account you can sign up for if you don't have one sign up there and then join that channel in rocket chat and be happy to chat about how to get plugged in in terms of skills a lot of the core is written in Golang so that's obviously super helpful but there's a lot of there's a lot of different pieces a lot of different technologies obviously we're working on Korda it's Java so try to think of what other yes so maybe I'll take this one a little bit so it's a microservices architecture that's really really important to understand about this this isn't just a go project it would be impossible for it to be the umbrella of things like Korda if it were and already there's different components that are written in different languages so there's a data exchange that's part of the open source it's very pluggable for lots of different technologies the data exchange implementation that's available that uses HTTPS and MutualTales that's written in TypeScript the UI, well that's all React and TypeScript it's not a community that you can only be involved in if you know go for sure and in terms of skills it's a huge range because some of the skills are I've got I'm involved in a community which is solving great problems for enterprise adoption of DLT and people are struggling to use us applications are struggling to build on us could Firefly be a way that maybe it becomes 100 times easier for someone who's never heard of blockchain to use my tech that's another way to get it to get involved isn't just necessarily about building the core and the things that are Firefly specific taking a tech you know we're working with lots Hyperlever Avalon, Hyperledger Cactus Hyperledger Bessu as well as Fabric these communities actually working out how that plugs in is another great skill set to bring to the community thanks and I appreciate that as well because we always are talking about the Hyperledger Greenhouse and I know there's been a lot of focus in this presentation around Hyperledger Fabric but maybe you can talk about a little bit more about those intersection points with the rest of the Greenhouse and maybe even have to tap into that community and bring them on board with Firefly as well I'll take a minute on that one I know Jim's on the line and he's probably thinking about talking people who've been in Hyperledger for a while might know Jim from previous lives he's one of the core contributors on Firefly and there's already been talking lots with other projects Bessu because actually the most advanced of all of the blockchain connectors in the Firefly stack at the moment is the Ethereum one so there's a lot of collaboration that's already happened there for many years we've known the Bessu guys since the very earliest days there and then a really interesting space is around identity plugs and then another one is around the interop side and also zero knowledge and I know there's been an active collaboration with Cactus on those two topics as well so we being a sort of melting point for technologies being a way to make technologies accessible is just such an important part of Firefly so we really want to be that place where technologies come together to help break down there are a few silos out there and actually being able to help break some of those down so really that's something that everybody on the Firefly project is really passionate about is really good production blockchain projects more than anything else we need success we need use cases that show value and that's probably a little bit more important in this stage of the journey than which individual technologies are used here or there yeah that's perfect and it looks like Alfonso's weighed in and breaking the silos which is really what I think the greenhouse is all about is how can we cross pollinate and help each other out in the different projects because there's a lot of expertise that covers all around Hyperledger and then being able to pull in resources that may help the Firefly project is a great way to cross pollinate okay perfect let's see if anybody else would like to answer or ask a question for the Firefly team on the session here and I just feel like you know we want to make sure that a good way to engage is going to be with the chat a good opportunity to talk to the team directly so Jim go ahead and weigh in yeah sorry John Dvendran still has an outstanding question from the chat okay perfect and Dvendran I see it here it says am I right in thinking that the subscriptions topics and etc are used to integrate with enterprise wide messaging systems like Solace that's a fantastic question so there's two sides of this this is a really important and it's a really astute question so you think about a technology like Solace or you know your TIBCO AMS or your IBM MQ series or whatever it is or ActiveMQ Artemis RabbitMQ whatever these technologies have existed for a very long time and they're exceptionally good at reliable enterprise to enterprise messaging and also within the enterprise Firefly has connections on both sides plugins on both sides and your enterprise network as it builds is going to need need both of those so one organization on their own in the system might use Solace maybe they're it's a financial organization they've got 100 systems connected together in a trading ecosystem every one of those 100 systems uses a private Solace box inside of their organization right then yes absolutely on the sort of front side the API side of Firefly you'd plug in Solace you might do it sockets or webhooks or you might contribute to Firefly an event plugin for Solace using the lower level you know implement it directly and that's great that organization then in the ecosystem like there's 10 organizations one of them's using Solace that's brilliant there's also the integration at the other side how do those 10 organizations want to privately share data with each other and that's that's where the private data exchange plugin comes in for Collider and that's the other side that's the sort of the backside of Firefly is is the integration to what's the cross-member private pipe and each network is going to have to choose one we've never seen a network that's got built without choosing any the blockchain's never been enough in the experience that the people involved in Firefly have seen we've never seen one evolve without one but it may not be just because one organization is using Solace that everyone's going to connect together through Solace what organization might be using Solace internally nor the organizations might be connecting together through 0MQ or something like that right and Firefly is then that bridge that allows the developers who only care about REST APIs integration and Solace because they're in their organization it's their bridge to the rest of the ecosystem and they don't have to worry about the fact that well that ecosystem is working on something else right they don't have and this is the problem in Enterprise blockchain is you end up in a situation where every organization has to learn the tech stack of every other organization you're never going to get anyway you need a way to make the job of joining the ecosystem easier for each of the participants but still enterprise friendly so that was a long answer but I just that question tickled me because it's from my background I thought it was a really great question I think you've really understood the types of problems that Firefly is trying to solve yeah one other question I'd have for you is just around deploy once deploy too many and so I don't know if you're familiar with the Accord project which is a Linux foundation project around natural language smart contracts but their philosophy has always been deploy once on the Accord project and then be able to plug it into the blockchain architecture that best meets your needs so do you look at Firefly as being that deploy once deploy many type architecture going forward or what's your philosophy there I have a personal view and maybe open it up to some others all so far all of the value in Enterprise pretty much exclusively or maybe it's changed a little bit in the last year it's been in building islands building private networks that have a group of organizations and a DLT or set of DLT technologies and private exchange that allows those organizations to talk to each other and there's this fantastic innovation on the use cases the applications organizations have been a huge amount of efforts to building Enterprise applications that solve a problem at the moment they're also building those inside of one of these ecosystems kind of locked inside of them I think one of the next steps for our industry as a whole is for these bridges to start getting built between ecosystems one of the way that bridges is going to get built of course it's going to be using DLTs that are shared being able to go up to Ethereum 2.0 across and down to fabric whatever at the DLT level another way that we're going to see bridges getting built is when applications can be deployed in a decentralized way to multiple ecosystems and being able to build an application on top of a set of APIs like Firefly could really allow you to do that if we standardize things like fungible and non-fungible tokens and I've built on that plus data exchange that's the small building blocks that already in flight for Firefly maybe I could build an application that I could deploy to 10 business ecosystems rather than once and suddenly the amount of payback I get for that really heavy investment that I'm doing in an enterprise application it makes more sense for me to do it and we'll get more innovation and people will get more payback and then the rising tide lifts all boats everyone will do better when you can get more success more quickly out of building to blockchain that's certainly the journey of all of the other technologies waves like AI and other similar ones have taken it becomes more interesting when you stop talking about the tech you start talking about the use cases we talk much less about AI than we did a few years ago not because AI isn't fantastic but because everyone understands it now and we're now building use cases on top of it and it's achievable we need blockchain to get there Hey, this is Jen I'll add to that John that I think the question is around two different approaches one is being done with projects like a core-cored thing to a certain extent or composing already they have a hyperledger where they start with the common language for domain specific language overall we spec out the whole network versus Firefly we focus on APIs and components which makes it in our opinion makes it very flexible for all sorts of things in the future all of those projects like demo and composer and a core they have to work across the whole community from day one to make sure the language they define will be able to support share evolutions and that's a difficult task it's a very interesting approach but Firefly we have a pretty different approach just one aspect Yeah, no problem Jim and I just wanted to touch base on that because I'm familiar with the core project and I'm familiar with what Firefly is doing and just wanted to discuss the way the two projects are approaching how to interface with multiple blockchains that may be out there that an organization is adopted Okay, perfect Oh, yeah, go ahead, John Yeah, let's go ahead and take his question so he wants to know does Firefly work across versions org one uses ETH but org two started with ETH too so maybe take that and let's discuss it Yeah, great question so, you know as Peter was talking about with the plugin architecture of Firefly there are certain parts of Firefly where each member of the organization can have a different implementation of how they want to interact with the network there are some that do have to be the same though and the blockchain is one of those so while Firefly is designed to have a pluggable blockchain layer you could plug in Ethereum you could plug in Fabric, you can plug in Quarta all of the it is a shared ledger so all of the members of the network need to have the same ledger they all need to be using the same blockchain and they would each have a blockchain connector connecting to the same blockchain Just one really small caveat of course if you've got a technology which is true in Fabric, true in Quarta where you can have lots of individual ledgers on the same technology platform like lots of Fabric channels or lots of peer-to-peer connections in Quarta that's supported it's only, but it does at the moment, a restriction which could be left in with community contributions is everyone needs to be using the same blockchain tack and they choose which ledgers they're using today there's no EVE 2.0 plug-in so it would be very cool if I met you interested in contributing that one that's the topic dear to my heart yeah and that's always the thing is the space is going to continue to evolve so you know his question is relevant in fact that you know EVE 2.0 will appear at some point and we'll want to connect to it okay perfect one thing that I would say go ahead I just wanted to say one thing is that the led you get a private copy your view of the world in Firefly it's subtle right but you've got your own database with your view in the world and that's all history that's happened so if somebody contributes to the plug-in in the future that allowed blockchain to connect into one Firefly the Firefly model would let your view of the world encompass transaction histories that span multiple blockchains because it's not it's about everything that you've seen it keeps a cached fast copy of everything you've seen in the past so it is suitable to that sort of future state where we see organizations needing to be the boundary of various different places the technology doesn't do that today but the model is quite suitable to that in the future Jess had a really interesting question here which I've been thinking about I never thought of this before but could you have two different Firefly networks each using different blockchain but connected through Firefly as a gateway I suppose you could it's a rather fascinating thought exercise and it would probably come down to some orchestration between the Fireflies in the separate networks perhaps through subscriptions to transmit events back and forth I need to spend a little more thought on that on some of the implications there but it's an interesting thought yeah there is a stream of work that Andrew and Jim are working leading on tokens and that stream is considering more than just the tokens within one chain it's also thinking about bridges and of course there's lots of things that you could bridge but tokens have characteristics that make them easier to bridge than others because what Nico was discussing there you've got two different ledgers being able to move data between them is one thing being able to move assets so that they no longer exist in this chain and they do exist in this chain or data that's a harder problem and Firefly is a great example of what Firefly is not trying to do Firefly isn't trying to be the place the community that would build the super sophisticated bridge contract but it is trying to be the community that could plug in things like hash time locks and netting and other ways to do settlement that you could plug that in and provide examples in a place where you could plug them in to standardize what state transfer might look like or what token transfer might look like perfect it looks like Faisal has a question for us here is it possible to attach a file like a PDF where the transaction message in Firefly without putting it in IPFS and he wants to keep private between himself and the counterparty so go ahead Nico yeah so that's what the private data exchange is all about so you can most definitely the same way that we in the examples that I walked through I didn't show attaching a file but instead of putting just a JSON string in that payload I could have done a file upload there and that would have not gone to IPFS that would have been transmitted over the private data exchange which in the current implementation uses HTTPS with mutual TLS and that would have been totally excluded from IPFS there to keep the data private perfect and I think that kind of leans into that property insurance example that I gave where you might have the full claim history that you want to share internally and then finally when you say okay we've paid out a claim of for a new roof on this house then you're going to go ahead and put that on the public you know clue database for property insurance claims there's a subtle thing a question often comes maybe someone's going to ask it is like isn't that what things like channels are for like you can just have a you know a transaction history that's just between these parties just the experience that we've seen is fantastic and really helpful but they don't solve the full the full problem data like 100 megabyte PDF is still going to be not particularly suitable to putting inside of the DLT data that you might want to delete or might have regulatory reasons where you need to delete it and the future isn't particularly suitable to the DLT and then here's the fun one often business transactions need to be one consistent business transaction and different people are allowed to see different parts of it you know the the assessor may not be allowed to see the same data as the insurer in an end to end business transaction but they're all one they're all one contiguous set of events they might all want to be on the same blockchain ledger they might want to all be in the same channel and Firefly embraces that that some data can be shared it's part of one stream of events can be shared with different parties at different stages along the journey and still be backed by the same by the same ledger perfect yeah that makes perfect sense and I'm glad you address that because I'm sure that there's somebody that has a question about either on you know the live stream or what we have for the group assembled here okay any other questions that we can ask for the team here this is a great opportunity to really you know get their expertise and learn more about the project and then engage and you know be a maintainer or a Firefly project okay I'm just gonna check here on the YouTube live stream I'm not seeing anything specific coming through there so if anyone has any other questions let's go ahead and surface them now and if there's not any go ahead yep yeah we had a question from a minute about what is required to be a maintainer and I'll take that one and the short answer is I'm document I'm in the process of documenting what that looks like and let's feel free to reach out either by email or rocket chat and I would love to get you plugged in it's on the to-do list for the project as a whole to document what is the process of becoming a maintainer and it won't be an onerous process but we do know that it's something that needs to be documented but let's chat super excited to hear that you're interested it's always going to start with some contributions so we can get you plugged into that straight away there's lots of areas that I'm sure you could bring skills and would be a great part of the community okay and then Jess has another great question here so the question is can you speak about what your expectations are for the on-chain logic I'm going to take that one a little bit so maybe Jess, the first thing to say is if you go and look at the project and you look at the on-chain logic that you'll find you might find an early PR around integration of some token logic but the stuff you'll find in the main branch there is the simplest smart contract logic you've ever seen it just omits an event and one of the things we're trying to address is that's because we don't care about on-chain logic within Firefly it's not that at all it's because we don't want to have any perceptions about the on-chain logic we want any on-chain logic to fit the model and one of the reasons why we haven't already done custom on-chain logic is because another really core principle is it's going to work across two blockchains so before we define the model in Firefly it is defined in the Ethereum connector there's a great REST API and event streaming technology in the Ethereum connector for any on-chain logic before we define how it rolls up into the Firefly umbrella we want to make sure that at least one other blockchain is at the same level so the work that's happening on fabric at the moment is about getting a parity between what you can do on Ethereum and what you can do on fabric so that we can roll those up to a standard model of what invoking any any on-chain logic can look like at a simple REST API level and we just don't want to rush and then end up we accidentally you know only one leg of the store works because we built that one without thinking about the other one so that's the only reason why you won't see custom on-chain logic but from a project perspective anything goes it's very important to us and it's the same for off-chain logic so off-chain logic can be anything you like it can be human processing business logic it can be Node.js, it can be Go, it can be Java it can be trusted execution it can be deterministic it can be it can be Azure knowledge proofs as well so it's the same for off-chain logic being pluggable as well as on-chain logic being pluggable perfect and it looks like just really appreciated that great answer so thanks for doing that Peter and this has been a wonderful session closing questions or comments feel free to post them in the chat and if not I really want to thank the Firefly team and Peter and Nico for joining us today to go through you know how we can get involved and what I want to make sure of is everyone also knows we're going to have some great meetups coming up which are around both what Alfonso talked about earlier and Alfonso thanks for joining the session today and then I also want to recommend if you're interested in what's going on in the blockchain job space to join the second of our four-part series it's going to be hosted by the Hyperledger Boston Meetup and Jim Mason around you know blockchain employment and what opportunities are out there so we're going to go ahead and wrap up here and I hope everyone has a great day and David has done a great job of always helping out the Hyperledger Meetup community he posted a link of where the recording will be in the chat and then we'll also go ahead and share the presentation deck with the attendees as well after the session so thanks everyone have a great day closing remarks Peter and Nico otherwise we'll wrap up yeah I just wanted to thank you again John for organizing this and thank you to all of you who have attended and just super excited about the excitement of the community and really looking forward to helping get people plugged into this project and get some some more contributions from the community so super excited and just thank you again for the opportunity a lot of fun appreciate it thank you so much everyone okay everyone have a great day and we'll catch up soon take care