 Hey, good evening everyone and good afternoon or good morning from wherever you are joining. Welcome to my pleasure India chapters special session today I would call it's very special because you might have hollered about a new announcement into hyper ledger labs. So hyper ledger firefly is a new project that got proposed and currently it's in labs where it is evaluating additional proposals to its project for example addition of hyper ledger fabric support to its project as overall umbrella hunt. So very soon it may even come out of labs and become a graduated or incubating project within hyper ledger. So, and it's also very good time from community perspective being as a developer or whether you are a business developer right to get engaged on this project because you will see benefits of the project and all across these topics. And today we have a very special guest from Colorado to present us on the topic of firefly. We have Jim and Nico. Hey, everyone. So I'll hand over my to Nico and Jim over to you. Thank you very much. Appreciate it Arun. Thank you all for coming here this evening or this morning or wherever you may be located. We're very excited to get a chance to talk with you about firefly it's a pretty exciting project I've been working on it for a couple of months now and super excited to tell other people about it and hopefully get them excited about it as well. We would love to get more contributors from all around the world involved in the project and and also maintainers as well. But you know the kind of the first step of that is just helping people understand what what is the project how does it work what does it do what problems does it solve so that's kind of the goal of today's meetup is just an introduction to firefly if you maybe you've heard of it but maybe you haven't had a chance to see it in action or try it out yet so we're going to do both of those things today. But so, first, so my name is Nico guyer I'm a software engineer at collido. I'm also the community lead for the firefly project. So I put on meetups run our weekly community calls and that sort of thing. I'm going to hand it over here to Jim Zang, our head of protocol and also co founder of collido, and he's going to talk you through kind of what you know the high level. What is firefly what problems does it solve and kind of the, the story of you know how how did firefly come to be. So, it looks like our camera was having some trouble there. But yeah, I will hand it over to Jim, and we will share screen here and Jim has some slides to take us through. Hi, everyone. This is Jim. I'm one of the co funders, like Nico said, really happy to be sort of back in this very exciting community of high pleasure. I was involved in the community several years back when I was still with IBM, but sort of faded away for a little bit after starting collido and we're focusing on some other technologies like Ethereum and quarter. But lately we've added support back to the hyper ledger technologies, including fabric, and certainly firefly now as part of the, the hyper ledger labs. So we're, we're all fully engaged with the community again. So very happy to see lots of interest on firefly from especially from from India that part of the world, observing our community calls in the past several weeks. I think we've seen a lot of interest from that side of the world so very happy to meet you guys today. And I'll just spend maybe 20 minutes or so on the background, just high level overview of what firefly is how it came to be and what we're trying to do. So you can spend most of the time after that with Nico to look at what does it take to get started, whether you are on the consuming side or are interested in contributing how to get started. So, Okay, need to advance the focus. Sorry, technical difficulties advancing slides here. Something you would not expect. Okay, there we go. Okay, awesome. Awesome. So far fly what it is, it's, it's not a new BLT technology, but it builds on the LT to be a system for multi party systems solutions. When we say multi party system. What does it mean so I don't think I don't necessarily coined this term. I've seen this term used in other channels in other situations but I think in general it's a new term that is describing a system where typically it's rooted on blockchain. So, it's a multi party system where multiple enterprises or companies or institutions are coming together to solve a problem. And the problem they're trying to solve usually involves data or, or, or assets or files to transfer from one party to another. And it usually needs a blockchain on the bottom of the solution because you want all the parties to have the same view to where is the data, who has it, who send it to who. And of all the parties that are involved in the transactions, you want them to have the same view of the state of the transaction. That's where things are really critical to have a blockchain as sort of the foundation of such a system but on top of the blockchain layer, a multi party system has many other components that are needed to make things flow. All the things that you've seen in the typical centralized enterprise IT systems, you know, reliable messaging, API servers, file system storage, distributed file system databases, all that are still involved to make this such a system work. So at the end of the day, you find that to make a solution work across all these multiple parties. You have the blockchain on the bottom but that's just sort of five to 10% of the whole thing you have to build on top of that you've got to build all these other things to make all the, all the data exchange work reliably. So that's what we mean by a multi party system, which is it's rooted in blockchain but it's much more than blockchain. So that's, that's sort of the space far fly is targeting, and it's trying to solve all the problems to accelerate the adoption of a blockchain. Okay, just need to click. Alright, so let's spend a few seconds on the sort of the problem statement, whatever we're trying to solve. Blockchain is definitely a groundbreaking technology, but it's so new that it's still in its early days in the adoption curve. We've seen in the past six years. Since we started on this journey with blockchain, there are interest in this technology from every single industry, regardless of what industry industry you are you have at least one or two problems that can be solved. That's not possible or very difficult before blockchain came into being. However, we've also observed to actually solve the problem. The journey every customer goes through has so many roadblocks along the way and they were sort of not expected. Most of the enterprises came into the space with a fairly naive view that, okay, I've got a blockchain. You know, I'm going to write a bunch of smart contracts deployed to the chain and we'll be fine. But very soon they found out that, well, if you put the business logic on chain, then the data that needs to be processed by those logic also needs to go on chain, which means everybody will see it. And that's not going to work in many of or we can say in most of the scenarios. You actually want the data, the business data, which has your competitive advantages or is very sensitive in its own nature to be held private only to the parties that are directly involved in the transactions. You don't want everybody else to know what that data is. Unless they are somehow involved in the transaction, but you still want them to be involved to guarantee the safety of the data and to make sure there's a decentralized consensus. So you're sort of in this in this tension between you want to share and then you want to keep things private. So every every customer we we've seen without a system like far fly ended up building everything from ground up. After the ledger is put into place they start building many things, one after another, and the result is what they thought is, you know, a couple weeks or a couple months kind of effort ended up taking years and taking generations to get right. And they, you know, they may spend a year or even more to get something and to end working but when they trial it with their users they found things are not working so they have to go back to the drawing board and start over. So it's, it's very unfortunate that a fantastic technology like blockchain, it's sort of seeing difficulties in adoption because things that are needed off the chain that needs to be there to make the chain itself work. So that's kind of the problem where we're seeing enough of that we decided we've got to do something about this because as a company we we know this technology is groundbreaking is going to be very disruptive is it's going to be strategic for the whole industry going forward but until these robot blocks are taking care of our solved the adoption curve is not going to be what we would like it to be. So, I've mentioned a couple of times that there are all these different components that needs to be built beyond the chain so this is sort of a high level overview of what they are like. At each party at the table, they're running their own bunch of components or you can say they're their own stack of components that are attached to the blockchain, the blockchain is definitely the universal source of truth. But then on top of it, they're building their own components so that they can do their processing business logics data exchanges save their critical data share files all that. So, you know, there's definitely information that needs to be shared across to the whole network, you broadcast, for example, a membership joining the network. So that information is always shared everywhere. But you can also say I defined a new asset with a non fungible token that I like to put up for sale for people to bid from to bid on, and that's that's a unique asset that needs to be broadcast everywhere. But at the same time you also have just peer to peer data sharing just between two parties or multiple parties, but it's a subset of the network so there are parties that are involved and they can see the data and the rest of the parties on the network are kept in dark. So private data exchange, you know, you want to do it through reliable messaging. And you, you may also want to pin the information to the chain to utilize blockchains data immutability and global ordering to make sure when multiple parties are submitting exchanges or transactions together. So there is a global view to the ordering of who submitted first and who second and all that. So all that is is very difficult because involves often components databases queues messaging systems and the blockchain itself. So blockchain is hard enough to figure out. And now you've got to make it work with all these other enterprise components. So that's sort of the high level view of the kind of things you have to make work to build a solution. Okay, so now if we look at the open source landscape, right. As a enterprise developer I like to first look at what's available in the open source space for anything I'm, I'm starting to build, because open source is great it's usually give you the best quality stuff, and also prevents vendor lock in. So it's usually the first choice for any enterprise solutions to start looking for solutions. Well, unfortunately, while there is a lot of open source projects in the DLT layer, right just look at hyperlinked itself. There are at least five different choices you can make. Of course on the very top. It's the kind of special unique things you build for each of your own projects and those are typical, typically your own IP so you have to build them for the solution specifically. And there's a big missing part in the middle that takes care of all the things we just described things you have to build on top of blockchain. And we haven't seen a open source project that addresses that space. And as we said, out of a whole solution blockchain is about five to 10%. And let's say the top layer, the special IP is another 5% or 10%. In the middle we have 60 to 80% of stuff that's like completely missing in the open source space. So that's what we're trying to fill in with far fly. We like to think ourselves as to blockchain what Kubernetes is to Docker. You know this may sound grand, but this is really a good analogy when we try to explain what far fly is. We use this as analogy and people get it right away. Here I think around circa 2013 2014 when Docker came about. It was great it's it's super, super slick, you can deploy things repeatedly and you don't have to think about deploy things configure things when things run together how do you configure all the ports so they don't run into each other. Docker is a great isolation deployment platform. It was great it was so exciting and we're trying to use it, but we found that doc while Docker is sort of the beating heart of new architecture. There's so many things missing right how do you configure networking how do how do you connect the instances of doctors how you how do you name them. So they don't just run on IPs. So that's where Kubernetes came in until kill Kubernetes. It was quite difficult to figure out how to properly and efficiently use Docker. So, Kubernetes helped a Docker to to realize the promise of Docker, and we think far fly, you know, we're still in the early days of far fly will, you know, will still be trying to grow it to become a real thing, but we'd like to think that far fly will will help the adoption of blockchain just like Kubernetes to doctors. Right so Now let's look at Look at what exactly makes up far fly. So as you can see from this diagram far fly is a typical way to run far fly is every party in the network has their own copy. So the thing that they run for their own organization is one we call one far fly node, a far fly node has these multiple components we can look at them more details later. But just like you run a blockchain node for your own party run a far fly node, alongside your blockchain node for your own party. So every party writes, writes some components that may be mostly common across all the parties in this network. But there may be some specific tweaks they need to make for their own for their own deployment. And when you look inside a far fly node, you see all the components we were talking about earlier that are missing from the off chain point of view. So sort of not on this picture but it's assumed to be there as the foundation is the blockchain node. And a far fly node is attached to a blockchain node. What it does is, it's sort of a collection of of elements, if you think of far fly nodes as a collection of like a periodic table, coherent collection of atoms. So you've got the core that is where it's basically orchestration engine for a multi party flow. It's got a API that you can send messages to send a file exchange to and ask far fly, please share this with this party. And at the same time, please add a painting transaction to the blockchain, or at the same time in a token to represent this information because this is going to be represented as a unique asset. So all those things is very easy to do with far fly, by just making a simple API call. And then to talk to different kinds of blockchain technologies, unique connectors. So far fly is designed to be super pluggable. Pretty much everything it does is through a pluggable interface, so that you can you can replace what's there with a alternative implementation. For example, a business logic, when some events so far fly is completely event driven programming model beyond the API is so when some events is published and it's received how do I process it. You can write, you know, any write the business logic in any business language, or a, you know, low code, no code type of tools, or even in advanced cryptography, such as your knowledge proves or trusted execution environments. So, you plugging what fits your scenario the best. What comes out of the box is sort of the common components are really useful for, you know, most of the scenarios but if you have a special need for a special kind of plugin. You can, you can swap in, or if there's not an existing plugin implementation yet, you can write your own implementation. And we're going to provide as you will see with Nico's demo part. A very good material to write them yourself and we'd love to engage with you to help you write your own plugins. I mentioned that it's very pluggable. So, and all the major blockchain technologies with the big three fabric enterprise Ethereum and quarter, it's all supported out of blocks. We have 100% support for enterprise Ethereum already we're working on very actively working on hyperlegislative fabric and portal support. So we love to hear feedback from you guys and so we can accelerate these components. I guess I'll, I need to go faster for the remaining parts. So I'll skip this one. This is mainly saying a far fly is leveraging blockchain but it extends blockchain to make things much easier to build on top of blockchain. We joined hyperledger because it's the best place to provide open governance over open source projects and far fly is a high quality components that we contributed to this project. It's, it's not, you know, when you look at some of the code, they may look pretty new, but that's because we're building the next generation of incantations. The current generation is already in in deployment in production systems with many of our customers for multiple years. And the new generation is written in go lang to have a better sort of community attraction. And it's an improvement in terms of the plugging architecture as well. So, as part of our contribution we have beautiful designs of the UI that allows you to look at what's happening underneath the cover. And hopefully this is something that will interest you both as a consumer or as a contributor so we can make far fly even better future. So with that I'll transfer to Nico and he will show you how this thing works. Thank you Jim, I appreciate it. I guess so I'll switch to my slides here and but while I'm doing that we can just pause and ask her, you know, are there any questions or things that folks would like Jim to clarify before we jump into other topics. Hi hall, could you hear me. Yes. Yeah, so you told like it can be plugged with Hyperledge of fabric as well right. The question here is, if we plug in as usual like in the hyperledger fabric will be using database like couch DB or level DB, right. So, if we connect this for firefly, where will the data go and store in hyperledger fabric. That is what my question is. Great question so you still set up hyperledger fabric the way you want if you want to use couch DB or the embedded level DB, you can do that. But understand that it only has your own chain data in that database. And it's the database schema is designed such that it's easier for the for the protocol to process state. It's not necessarily the ideal way to save the data from your business queries point of view. So, hyper fabric, sorry, far fly gives you a off chain database that is a replication of the data on chain, but also your private business data that is not put on chain, but is also critical to your solution itself. So you also have this database in far fly off chain that you can choose to replicate the information from on chain storage, but also has your private data, and you can design your schema to make that be more efficient in terms of queries from your solution. So that's that's the difference between on chain state database where you get with fabric and off chain database. Okay, so, okay nice that's great actually so querying is also like present problem in hyperledger fabric. So if we go on data increase the data like business will usually has many transactions per day. So, increasing data might also make complex for querying. So that's great actually. And another question is, you were telling like there will be multiple nodes of firefly right. So, each node will have the same data or what is the architecture there. Yeah. So, so the answer is the short answer is it depends, and it will probably make more sense actually as I get into my slides and show a demo. Each. And the reason it depends is because not every party in the network may be privy to all of the data in a certain transaction. So, for, for things that are public. Like the ledger itself, everybody will have the same. Everybody will be working off the same ledger everybody will see the same blockchain. But there may be data payloads associated with certain messages that only certain parties in the network have in their database. So hopefully that'll make more sense as we get into the next part. Yeah, yeah, that's so can I call it as a hybrid blockchain. I don't we haven't really used that term. I guess it depends on what you mean by that. Yeah, like hybrid blockchain isn't it but there will be a public chain, but in the same thing we can, I mean, create some subnets private subnets between the organization. So, maybe if I see that more than I can. Yeah, so the fireflies is most definitely about combining the power of on chain logic with off chain business logic, and also having data on chain and off chain and orchestrating between both of those things so from that standpoint it does it does both and it leverages blockchain in a lot of different ways to be able to do that. Yeah, I think just going with your analogy. Maybe it's more of a twin brother to the chain rather than the hybrid, because it runs alongside the chain and compensate or compliments what the chain is having difficulties to do. All right. Okay, sorry, one question. So for this, you know, firefly you mentioned that you provide you know off chain database as well. Right. So what are databases do you support for often. Ah, great question. I will cover that in just a second. Yeah, thanks. Yeah, the short answer is right now postgres and SQLite, but it's it's very pluggable. Great. Thanks. All right, I'm going to share my screen again. One more question if you don't mind. So yeah, go ahead. The firefly nodes right so do we have to actually share the certificates with the node and how is it managed within the node to connect to the network. Yeah, good question. So there is a firefly has a network registry API. And so when when a new node comes up. You can you can use an API to register the node to the network and provide the identity of the member that's running that one. In terms of exchanging certificates, that is going to be dependent on the actual the technology you're using to implement the private data exchange. So when we look at the example today, we'll see the what we call firefly data exchange HTTPS. That is using HTTPS mutual TLS. And there is there are certs for each of the members on each of the nodes that are sort of the setup by a deployment tool for you in the demo. And to add to that, in terms of the identity, how, how do you represent identity on the firefire fly network. You will see in the demo that identity is represented as if you're madras, of course, that's when you build your firefly on top of Ethereum delta. So if you are building it on top of fabric, for example, or even for the where identities are represented as certificates, then identity. In that case, in the registry will be certificates, because identity itself is a pluggable component in power fly. I have a follow up question on that. Do you like, do you provide that, you know, as part of firefly this firefly provides a, you know, key management solution as well or you know integration to any, you know, hardware module. That's a great question. So, at the moment, we have implementations that uses software based key representation so the key itself is in memory. It's manipulated by the by the software. But we have the part that we built in the current generation has support for HSM modules. We just need a port that over to the new generation. So there is an interface for signing things and we don't assume the private key is always available to us. Great. Thank you. And just real quick apologies for the I realized the video or my computer I think right now is struggling under the CPU load of processing the video we've run this setup before and it worked a lot more smoothly. I'm not sure why it's struggling today but I'm just going to turn video off for now. Apologies for that. I will go ahead and share my screen though and so you don't have to look at a black screen and we'll talk through, you know, how, how does firefly actually work now. So, we'll kind of transitioning a little bit. We're going to talk about some key concepts in just like things that you can do with firefly and how it works. And then I'd actually like to go hands on and show a demo of it show some examples of, you know, the different types of things that you can actually do with it. And so you can actually see it in action because I think that's really helpful. So to describe sort of the different types of things that you can do with firefly. We have this cast of characters here who you may recognize from computer science stories such as public private key signing, and that sort of thing, Alice Bob and Charlie. So Alice Bob and Charlie all work at different organizations, but they work in the same industry and they want to perform business transactions with each other and they want to power this by blockchain. So, I'll go quickly through this part because Jim did a fantastic job already describing the use case for firefly when you would want to use it. So, you know, but to summarize, you know, Alice and Bob could stand up blockchain nodes on a shared chain, and then, and then what, well there's a whole bunch of other stuff that they need to add in order to actually do business transactions on top of that chain. So that can be very difficult when you have a lot of different corporations trying to work together and integrate with one another it's very can be very time consuming. And so that's what firefly solves firefly is a standard for a way for businesses to perform multi party enterprise transactions powered by blockchain. So Alice can stand up a firefly node Bob can stand up a firefly node Charlie can stand up a firefly node they all register to one another and they're in a firefly network. This gives them a ton of different capabilities. They can send data publicly or privately. They have the choice of making that on chain or off chain. They can send models, you know, event driven or request response. They can send just, you know, JSON objects they can send blobs or binary files. In the very near future, they will be support for fungible non fungible tokens, as well as custom on chain logic those are things that are either in development or will be shortly. And there's also a very easy to use rest interface, along with web sockets and web hooks for receiving events out of the event driven model that firefly has, and like Jim talked about. It's all very pluggable so a lot of these things can be replaced with you know if you need a specific technology or specific type of messaging system for instance that firefly doesn't support today. It's extensible you can you can build a plugin to extend it. So let's talk about how do I actually get data, you know, say Alice has a piece of data that she wants to send. So, the first way is a broadcast this is a public way to send data to every party in the network. So Alice has a piece of data she wants to share with all the other members. Maybe she's declaring, hey I have this asset. Maybe she just needs to notify everybody of something that she's done or something she has. And so she can do use a broadcast to do this. However, say she has a piece of data that is a transaction only between Alice and Bob, and Charlie should not be able to see this transaction. There's also a way to send messages and data privately in Firefly as well. In either of these cases, it's worth noting that the the data payload itself will not be on the blockchain. And we'll talk a little bit more about that on this slide. So Alice has the option when when she's sending messages to other members of the network, whether that message should be pinned to the blockchain, or if it should be unpinned. And even if the blockchain is used is it's a pin that's stuck on the blockchain not the actual data payload itself. So, Bob can verify that when he receives the data payload that yes okay that is actually what Alice sent me it's really from her and that was really what she sent. However, there is an option to send data completely off chain if there is a need or a particular use case for that as well. So broadcasts or private messages pinned or unpinned. Like I mentioned earlier the the actual things that you send inside the message could be just JSON objects, or it could be a blob, it could be a binary file. The data can be either in line in the message or it can be linked. And like we talked about before it could either be public or private. And you can sort of mix and match all of these different types of things. Okay, let's talk real quick about the the event driven model so Jim said that you know Firefly is designed in to be an event driven programming model Firefly itself is very event driven. And the best way probably the most recommended way to write an app that uses Firefly or to interact with Firefly is in an event driven manner as well. Alice has a piece of data that she wants to send to Charlie. Charlie previously has set up a subscription and we'll talk about what subscriptions are actually show you one and a little bit. But it's basically just a way of saying hey for these types of events, send them to this place. And that could be a WebSocket connection or it could be a web hook just you know it post to an HTTP endpoint somewhere. So Charlie is set up that in the past. Alice has a piece of data she wants to send to Charlie so she makes an HTTP post to the Firefly API. I've sort of for the sake of this drawing simplify the communication between the Firefly nodes here. But when she makes this post she'll immediately get back a 202 accepted that means Firefly has received the message and it has it it's safe. It will take care of it, but it the transaction is not complete yet. So after she receives the 202 she'll get to get an ID back with that so she can correlate it later to other events related to that message. Firefly will send the message over to Charlie via however he set up his subscription and that will confirm the message. So once Charlie has received it. Alice will receive either again over a WebSocket or web hook a an event saying that hey this message has been confirmed Charlie got it so the transaction is done. At some point in the future, you know Charlie's application may also generate some data. As a result of receiving this message from Alice. And so then you could flip the whole diagram and Charlie could send some data back to Alice the other way. And then this could this message could be pinned or unpinned the data that she's sending could be a JSON or blob this this could be a broadcast message to everybody or it could be in this case we're only showing it going to one member of the network but remember you can kind of mix and match all of these concepts of ways to send data within Firefly to meet the needs of your specific application. So if you have an application that is not event driven, or you have a specific need to work in a more traditional request response model Firefly has a sort of translation layer built into it that allows you to write an application in a traditional text manner. So the key difference here is that when Alice makes this post so this is a post to a slightly different HTTP endpoint that behaves differently than our other broadcast or private send message endpoints. This endpoint which I'll show you in a little bit will actually look at all the the rest swagger and I'll show you all the different endpoints that are there. So as opposed to the request endpoint though that request will stay open and will Firefly will not respond to the request until it has sent the message all the way to Charlie Charlie's application has responded to it. And that response from Charlie will be wrapped up in another Firefly message and returned to Alice back as the response to her original request. And as you can imagine the latency is definitely higher in this model, because this original HTTP request will be blocked until Charlie's application has a chance to respond. Hopefully Charlie responds quickly. But as you can see that this is definitely not as ideal for throughput as the event driven model so that's the event driven is is the preferred method of operation in Firefly but the request response model is there to if you Okay, so Firefly is very modular as Jim talked about I'll just quickly highlight all the different things that can be plugged into Firefly. We've talked a little bit about it so I won't talk you to death about how you can use plugins, but yeah we talked about you know, Ethereum support is there 100% today. Fabric support is in very active development and quarter is shortly to follow so you can actually swap out you know the entire blockchain layer. It's worth noting that all of the members of the network need to be using the same type of blockchain right today in Firefly. But it all of the members of the network can agree hey for our network use case, maybe fabric is a better fit than Ethereum. And so we're all going to deploy Firefly and we're all going to use fabric. On the database side there was also a question about this week. There are plugins today for PostgreSQL and SQLite. Not all of the members in the network have to use the same type of database though the database is their own private database and so your different members could use different databases if they wanted to if they had a specific need for that. And the blockchain and the blockchain the data exchange and and the public storage are and probably the registry are the ones that need to be the same across the network. I just got a little pop up from zoom, saying that participants can see my application or that you can still see my slides correct. Yes, we're looking at just like. Okay, cool. I thought well they've been able to see my slides the whole time right I hope. All right. Cool. So, yeah, the event transport, all of these things are pluggable so if you want to use something other than WebSockets or WebHooks you could do that. Here's just a quick look at we talked about this diagram in our community call yesterday. So there's there's sort of multiple. You have the the firefly core process, but a firefly node is really a microservices architecture. And so you can have a firefly is is really an orchestration engine. And it talks to many different systems to actually implement the specific functionality that it needs. Firefly has many different interfaces of sort of types of behavior that it defines in the code. And, you know, say you wanted to swap out, you wanted to use something other than IPFS well IPFS makes a lot of sense in a distributed system like this but say you want had a reason to use something else. You could write some different client code here just just a little bit of code and go that implements the public storage interface and talks with some other system besides IPFS. And boom, you've got a plug in and you can extend firefly and work with multiple different public storage and public storage systems so won't go into much detail here but this is just sort of a picture of the different layers of when we look at the firefly application how a firefly node is put together. All right, just a couple of quick concepts before we get into some hands on demos. So namespaces as well when we start looking at the API you'll see everything is prefixed by a namespace. A namespace is a way to basically group related messages and data together. So, your reasons you might want to use it. So there is a default namespace that's there out of the box that you can use. But you may want to use a different namespace for instance if you want to just run some test transactions, because blockchain is used here, the data is immutable it's on the chain forever. So you can't go back up and clean up test data afterward. So you might want to isolate that on a different namespace so that your application can have a clean view of the world of the network. You may also have a multi-tenant system where you want to run multiple different apps on the same firefly network. You can segregate them by namespaces and this provides a way to do that. Okay, so messages, we're going to look at some messages here in just a second. A message is really just unfortunately it's you know everybody has a message Kafka has a message sqs has a message firefly has a message. A message is the way that you send data to other members of a firefly network and message can have multiple data elements in it, it can have a header section that describes how the data should be sent. And it can have a group section in it that says who it should be sent to. So we'll look at some specifics here now actually, I think, yep. All right. So I'm going to slide over here, you should be able to see. Let's see so my screen sharing is paused. Just try to unpause it here. All right, should be able to see my desktop. Can you see Chrome? Yes. Okay, great. We're going to go hands on now and actually show firefly in action and I'll try to go through this quickly because I want to leave plenty of time to talk about, you know, questions and answers and have some discussion here at the end, because that's the I think the discussion part of meetups is one of the most valuable parts so if you want to get started with firefly the easiest way to do that is with the firefly CLI so the CLI is a tool. It is written in go so you can right now you can install it with go install if you have go installed on your computer. And this is a way to set up a like a local development environment so say you want to write an app that runs up with on firefly. And you can use the CLI to deploy a like like I'm sure you realize by now hey there's a whole bunch of moving parts in a firefly network well the CLI takes care of the logistics of all that for you. So this is designed as a tool to deploy to production, this is a development tool. So, I'm going to show that in action now I have it installed, and the binary name is ff. So, you can run that and it will tell you all the different commands you can run so I'm going to ff init demo. It'll initialize a new firefly stack it asked me how many members I want say three, and then I'm going to start it up and then while it's starting up I will kind of describe what it's doing. Under the hood the the firefly CLI is using Docker it's using Docker compose to basically start up all of the different components of a firefly network so there's a firefly core. There are IPFS nodes there's a blockchain node, there are data exchange nodes, Firefly CLI is out of the box going to use SQLite so that the database is not going to have its own container, but you could there is an option a flag that you can set to deploy Postgres if you want to do that. So, so this is basically going through and it's setting up all of the containers and it is writing a bunch of configuration and going to basically register all of my members to play contracts all the logistics of getting the firefly network set up from the ground up so I think my computer is under a lot of stress because usually this goes faster. But we'll just give this a minute here. Well that's going. I just want to point you to the the dock site so if you're curious to to read up more on firefly, or what the different API endpoints are you can go to labs dot hyper ledger dot org slash firefly. And there's some different getting started guides here on, you know how to how to set things up some examples of you know how to broadcast data. And then the API spec is also here. So, come to this page and see all of the API endpoints this is generated by so that are the swagger for firefly is generated by firefly itself at build time. So it should always be up to date with the latest version. So you can come here and see all of the different endpoints and my goodness this is going really slowly I apologize. I'm not sure. Yeah. Yeah, I'm going to. I'm going to close some stuff on my machine to hopefully get some CPU cycles back here hold on. Sure. So in the meanwhile, you know, would they use base or column right now for blockchain. Right now, what the CLI is deploying on my machine is using Ethereum so it's it's actually that the current version of the CLI if you go grab it today will use it'll actually use ganache as a just a very lightweight blockchain implementation there's an open PR right now to switch that to an actual go Ethereum node. And as more types of as other DLTs are implemented in firefly, there will be additional command line flags added to the CLI to set those up as well. Okay, yep. Okay, can you guys still hear us okay. Yes. Okay, great. I just switched my mic. All right, I'm going to try my screen share again here. And I close some stuff on my machine. Hopefully that'll be better I do apologize for this. Yeah, and stuff is not let's see. I'm just going to try to start this up one more time. I'm guessing because things were just going so slowly at timed out. Actually, yeah, we can take a few questions while this is starting up now if you want. So if we talk about even driven messages, it feels like a lot similar to you know what areas you should do right, although you know obviously you have you know so many other features built in. But in terms of messaging, you know, it is similar for that right. I apologize. I didn't I didn't quite catch the beginning of the message. What is it similar to so areas, you know, hyperledger areas because you know it provides you that wallet and you cannot, you know, have you know, send out those messages without having to use blockchain. Is it similar to that. Okay, I'll take, take a crack at it. So block blockchain messaging is so there are different technologies that makes message exchanges attached to blockchain nodes possible. So I think areas is more of a peer to peer wallet to wallet. So far fly messages are things that you send across parties, you know, can be Jason payloads can be can be referenced to a file or can be filed itself. And the secret sauce of messages exchanged between far fly parties is it has a very proscribed side effects in terms of what what it does to the blockchain. So many two things can happen when you exchange messages. One is, it's going to be protected by blockchain so after the fact neither parties can deny exactly what kind of data was exchanged in that transaction, because it's pinned to the blockchain. So the hashes and commitment is, is mutable now. The other is a global ordering, if multiple parties are sending their messages in, let's say for bidding for an asset. It's critical for everybody to agree who went in first and who second. So that's, that's the kind of special treatment messages for powerful. Thank you. So you mean, you know, a broadcasting is also there, you know, like, not peer to peer but I could actually broadcast. Yeah, so so broadcast will go to all members in the network and actually the demos up so we can actually see that in action now. Sure. Just before that, you know, so can I have selective broadcast as well. So you can send data to multiple members we don't call that a broadcast we would call that a private send to a group, and I'll actually show that as well. Okay, thank you. Sure. Okay, so the demo is up so my, my Firefly CLI has finished starting the stack and it says your here's your web UI for each of the members of the network so I have three members in my network. And Firefly core is listening on different ports for each of them so 5,000, 5,1002 so you know kind of using our characters from the slides earlier will pretend that this is Alice, this is Bob and this is Charlie and I'll try to use those same names as we're going through the demo and so that folks can kind of follow along. So, here we have each of their UIs right now they all look the same, there are there been no messages sent through the system so there's three members in the network and no messages no transactions because nobody has sent anything. So, I'm going to go over to postman here. I'm going to. I'm going to send a message. This is from Alice. So I'm using port 5,000 here to hit the first Firefly node in the network, and this will be a we're sending this to the broadcast message and point here so this will be a public message that will be sent to both of the members on the network. A message has a data element which is an array you could have multiple pieces of data here if you wanted I'm just going to send one, and I will post that you can see I get back over here and ID, which I can use to look up this Firefly is also hashed both the message itself and the pieces of data in it. And it's told me that, okay, I got the message we can see this is a 202 accepted, and it's still pending right now so we can go back and look at the Firefly dashboard here and just refresh this. And we can see that the message has come here and let's just refresh these guys to see that the demo is not working. Oh man, this is wonderful. This did work last time. So, the other two nodes have not seen the message. And so this one is from that standpoint Firefly is working correctly in that the message is still pending because the message hasn't hit the other nodes. I'm going to try stopping it here and starting it back up again and see if that clears it if not then I'll just have to talk through the rest of the demo and I do apologize for that. The first time you start up a Firefly stack on your machine it takes a bit of time because it is doing a lot of deployment and configuration setup that the next time you start it should start up pretty quickly though it just has to basically go turn on all of the processes in the other containers. Hopefully this will get that message stuck unstuck out of the pending state and the other nodes will be able to receive it and it did not. Oh, there it goes. Okay, cool. Refresh this one. Alright, so now, now everybody has the same view. So, each, this is Alice, Bob and Charlie all see the same message that has gone back gone through the system. So here to the messages tab to see the actual message that can see the hash of the data to go to the data tab. You can actually click on this and see the actual data payload as well and there's there's the message that was sent. I think Nico was actually trying to show the tolerance aspect. Yes, yes, we will. That's a good spin on it. Thanks, Jim. I'm going to try that one more time just to make sure I'm going to broadcast one more message here. Just to make sure that goes through as well. Before we keep going. Okay, yep, I think I think we're in business now. I'm not sure why it didn't go through the first time but now now each member sees two messages have been sent through the system. So that's a broadcast. Let's look at a private message now and there was a question about you can kind of broadcast a message to multiple people but not everybody. And this is this is how you would do that so we would we called. So the previous request was to the broadcast message endpoint. Now we're going to go to the send message endpoint and the we've added a new thing to the message. Jason here called a group with an array of members. We could have many different, you know, however many members you have in your network you could list out all the identities of the members that you want to send this message to in this case we're just sending it to one but if you if we had more than three and you wanted to send it to to you could just continue appending identities to this array. So here we're going to send we'll say this is a secret message. We've also added a header. Now this is not required to send a private message but I wanted to talk about the header as well so the header is where you can define some other fields that tell you know how the message should be processed so this one we're adding a tag on and a tag is used to to the other members of the network, how they should process the data so, for instance, you may have, you may send some data. And the message may be sent because it was a new customer order or something like that and so the tag can be used to tell the other members hey this is a new customer order, as opposed to maybe an order that's being canceled or revised or something like that, and that can inform the other members how they should process the data, independently from the data itself. Okay, so, so this is going to be a message again I'm sending it from Alice's endpoint to org one is, we look over here, you know member one is this is Bob. They count up from zeros zero one two is how the orgs are labeled here. So we'll send this one. So what we should see here is Alice and Bob should both see this message but Charlie should be totally oblivious to the fact that it happened. So if we go back over here. We look at Alice's Firefly interface we can see there are four messages sent. Bob sees four messages, Charlie sees two. And if, if you're counting, you maybe wonder why we jumped from two to four. When, when we sent that group message, there was an additional Firefly behind the scenes sent another message initializing the group between Alice and Bob's nodes. And that was what this group in that message was and that's why we have four messages here. But again, so Bob can go look at data and see, there's a secret message. However, Charlie doesn't have any record of this happening. You can see the two Hello World broadcasts, but that's all. Okay. So we're going to do a time check here. I want to show one more, one more use case here and then, and then we can just switch to some question answer discussion time. So I'm going to create a subscription here. So this is so Bob is going to create a subscription and subscription says, you know, when certain events happen or certain messages come in, send them to this place and we talked about earlier how that could be a web hook, or it could be a rocket in this case, I'm going to demo a web hook. And so this is a post to the subscriptions endpoint. So this will create a subscription. And I'm going to define that subscription here so basically I'm telling it I want it to use web hooks. I give it a name this could be whatever you want. So the subscriptions need to be unique between the name space that you're creating them in and name. So you kind of have the, the two combinations, the combination of the two needs to be unique there. And then I can set some options on it. So the most important option here is the URL of where I want it to go to. So I fictiously called this the banana handler. So if somebody sends me stuff related to bananas, it's going to send a post to this endpoint slash banana. I'm going to filter on things coming in to firefly based on if they have the tag banana, then I'm going to send them to my banana handler. This will also. So these options here. So remember how we talked about the request response model so this is this is how I set up the far side of the of the response so basically anytime a message comes into this endpoint. Firefly will wait for a response, it will get that response it will wrap it in another message as a reply to the original message sent to it. And then it will tag that with banana response. And it will send that back to whoever created the original banana message. Hopefully that'll make more sense when we actually see it. So I'm going to create this. That's created so that's basically the URL that I had set up up here is going to send requests to this endpoint. Now I'm going to go back to so this was Bob Bob set up that subscription so when Bob receives messages there. With the tag banana will get an HTTP posts over to here. Now Alice is going to go send a make sure I get the right one. Yeah, so here's the request response. One. I mentioned earlier that's a separate API endpoint. This is to the request message endpoint so we've looked at broadcast message we've looked at send message now this is a request message so this one behaves a little differently. So here we're going to the tag is banana because that's that's what we have set up on the far side for the subscription to receive that. This the TX type I've set here to none that means this is actually not going to be pinned to the blockchain. And for the data I just decided to make it a little bit more interesting so I created you know a whole JSON object here rather than just a string called Hello World or something like that. And then here down we've seen this group already so this is a message from Alice from from her API to Bob Bob is org one. Hopefully that makes sense so sending a private message requesting a message in response from Alice to Bob. And so let's do that now so hit send. Notice how the latency was a little higher there. This is not pinned to the blockchain so it was actually pretty quick but basically that went round trip from Alice's Firefly Charlie's Firefly. Sorry Bob. Let's do this request been we can see that the banana endpoint was hit here and we can look at here we see the JSON payload that Alice sent to Bob. And if we go back to postman we can see what Bob responded with in the response so the response itself is a Firefly message, and it has data in it as well so we can go down here we can see. So basically what Bob responded with so responded with a status 200. Here's all the headers that were on that HTTP response from a quest bin. You can see it's you know powered by express. And then basically this request been just responds with success true. And that's what's in the response body there. So let's look at Alice's dashboard now we can see. So here was the private banana message that she sent you can see it was with the tag there banana and then here's the message that Firefly generated in response that based on the HTTP response of that request been. I should be able to look at this. I can go. I can go to the data tab, and I should be able to see, you know, here's, here's the actual payload, the response that Bob sent. So, that is it for the demo thank you for for bearing with the technical challenges of doing a live demo. I appreciate your patience there. Hopefully the demo and the hands on was helpful just to see some of the types of things that you could do with Firefly. I have about 15 minutes left and just wanted to open it up for for more questions and answers I think some some conversations been going on in chat. But yeah I want to open it up for Q&A and discussion now and actually before that sorry I had one more slide and that's kind of what's what's next. So, just in summary, kind of wanted to conclude with what's next for Firefly so we are currently actively working on fabric and porta. Those are fabric especially is under heavy development right now. If you are interested in fabric or porta, those would be fantastic places to get plugged in, either building the connectors or also the the plugin layer that goes into the core, or even if you have experience setting these things up in the CLI need some integration there and some additional options for turning on networks with with other DLTs. So those are those are areas that we're working on right now, fungible and unfungible tokens actually is is being worked on right now as well so that's that's coming up next shortly. Custom on chain logic, we know we definitely need to have. However, we're holding off on implementing that until we actually have multiple different types of chains that we can work with so that we make sure we get that right. We don't want to design custom on chain logic, or just Ethereum and then realize that we needed to design it differently when we have other chains available so we're waiting on that one until we get all three. You know, Ethereum fabric and quarter 100% supported and then we will layer on custom on chain logic on top of that. And lastly, what's coming up next and Firefly, hopefully contributions from you all. We would love to get people involved in this project and contribute to it, or you know if you're really passionate about it and want to get involved, you know, long term, we would love to bring on more projects for the projects as well there's a lot of different repos a lot of different parts of the project that people could have ownership over and definitely want to grow this community and that's why we're so excited to be able to share with you all what it's all about today. So that's that's it for my slides I will stop talking now and open it up for discussion and questions. Thank you. Jim is there anything in the chat that we wanted to kind of surface in discussion here I haven't been keeping an eye on a lot of great questions. The majority of them are already answered either live or in the chat. There's one remaining one from Kent. He was thinking about the glitch you hit and how you're able to recover. And that got him to think what's the backup strategy for for our finance and what are the what do you think is the mechanism that allows it to recover. So what I think happened there is, we probably got, there was probably some component of the network that wasn't talking to one of the other components and just a restart. Got that to work. It was probably just a timing issue and everything starting up on my machine. So, so what's the. Yeah, so I can just talk briefly about the kind of the deployment strategy so so Firefly itself is, it is a, the process itself is stateless, so you can you can run multiple Firefly core processes. You, as long as they so the state really ends up going to the database primarily. So, each type of database that you use will have its own ha and redundancy sort of model and that's, that's going to be dependent on which type of database you're using. As long as you know if you wanted to scale and if you wanted to have ha for the Firefly core. You can run multiple copies of the process, but they do need to be talking to the same databases the same public storage data exchange within their within that members node so you so we talked about how a Firefly node is really like a whole bunch of different processes, and a node could have actually within that multiple Firefly core processes for redundancy or for scale. But they do need to talk to the same source of truth in terms of where the data is coming from though. So, yeah, so you could have a Firefly node crash in the middle of stuff. And, you know, all of the important state and status of messages in flight is it's going to be persisted. And so if it comes back up again and it has a message, like we saw earlier that it didn't make it to the other side yet. It's able to pick that back up and keep going where it was. So can hopefully that address your questions. Others have other questions to discuss the rate limiting step for Firefly node. I don't think at this point we have any specific rate limits on the API. So, you know, the design of a Firefly network is a bottleneck. Yeah, that's a good question. I'll take that one a second. So the design of a Firefly node is that only the it's, it's sort of a private system for the member that it's been deployed for so it's not like this is a Firefly API is not going to be a multi tenant API within within one node so you don't necessarily have to worry about like you know a whole bunch of other people hitting the API and you know causing causing slowdowns. It's basically going to be you know however fast your application can go. You're only going to be limiting yourself in terms of bottlenecks that that's a great question. There there is more performance testing and tuning and scale testing that needs to happen on Firefly in general but there's there's there's batching that happens within Firefly a batch is a very important concept within here that we didn't really get a chance to talk about in detail but you know anywhere Firefly can for throughput will will process things in a batch so that's when it writes a pin to the blockchain that happens in a batch when it writes data to IPFS that happens in a batch. So we try to try to reduce the number of bottlenecks by by grouping data to get higher throughput, but there's the database is one potential bottleneck that I'm, I'm a little skeptical about until we run some hard tests on it. The blockchain you know just you know how fast you can get stuff in and out of the blockchain might be Well, the short answer is we need more testing on it and it's it's early in the project and that's that's one of the things that we're definitely aware of. Yeah, as Nico mentioned, you know we've we've seen bottlenecks happening from past experience with live deployments, and they tend to be all the distributed components in the mix and that being the blockchain itself and IPFS. Both are, you know peer to peer decentralized technologies and compared to centralized technologies you know it's a daily server or even the database. Those tend to be slower than the others and for both components we have designed techniques to address that so Nico mentioned batching or messages so that's actually specifically because of the IPFS bottleneck and then the adapters we built both Ethereum adapters and fabric adapters will have a a queuing mechanism in front of the blockchain so that if you're sending transactions much faster than the blockchain can process. They will be accumulated in the reliable queue Kafka is obvious choice so both connectors have great support for Kafka. So it won't be able to overrun the blockchain. Yeah, thanks Jim. So Vikram had a question here about. Can we see the containers the CLI brought up yes you can and I'll actually show you how you can do that real quick. So the CLI has a couple of different helpful commands. If you just run FF or FF help it will tell you all the different things you can do with it. So, first of all I can see all. I do a lot of development with firefly so I have a lot of different stacks, you can run, you can have many stacks on your machine so this is I have like all kinds of different things in different configurations. You can only run one of them at a time though, it's just worth noting, because of port collisions right now we've had thoughts about running multiple will be a lot to run on your machine but. Right now you can run one at a time and if you want to see what's running on one of them so we were running the dev stack earlier so I can run FF. info on the dev stack is like a read the stack info and then it will tell me all about the stack so this first thing this first table that gets printed out here is. All of the containers and you can see the image the Docker image name that it's using and the tag and image ID so if you need to go check okay which version of this thing by actually running. Especially as we're doing development on it. That's that's a helpful thing. And then the second table that gets printed out here is this is what Vikram is asking about like what's what's running and so. If if it's running this table will get printed out and it will show you all the things will show you all the so I can see that all these are running because the state is up. And it will show you all the port maps that they have set up on them as well. So that's that's how you can see so this this shows for each of the members so. So these are like these are the data exchanges for Bob. Sorry Alice Bob and Charlie, and then here's the Firefly course for Alice Bob and Charlie. So that's a helpful thing to just see kind of what's going on there. Cool. Glad that answered your question. Thanks, Vikram. Good question. For the purpose of like governance. Do we need some governance for this. For fire if you use fireflies there's some additional need for governance like you know for consortium we need to, you know, have a governance that you know how do we allow what what is really to be allowed, you know how to on board a new organization. So does I mean anything else you know firefly ads on top. I apologize the audio was a little hard to hear I heard membership. Yeah, how do we on board new members. So basically, is there additional governance that maybe needed if I use firefly. Yeah, that's a great question. So in terms of membership registry. So the membership registry is a core component of our fly core. And that itself is again a pluggable component at the moment we have a centralized implementation of that registry. In fact, the previous generation had a decentralized implementation of that registry which is based on blockchain itself. So, based on the community needs, we can bring it back into the into a new generation and fabric for example has great support for decentralized governance. For membership management us as does a quorum and Bessie. So, yeah, I guess the short answer is, it's, it's, it's pluggable and it's both be centralized simple or decentralized. Thank you. Yeah. All right, we've got probably time for maybe like one or two more questions. Don't be shy. All right, well if there are no other questions. I just wanted to say thanks again for for giving this opportunity to chat with you all today. I'm really excited to share about Firefly and get help people understand what it's all about and equip people to be able to get involved in the project so if you're interested in Firefly and you want to get involved. So the next steps that I would encourage you to take our, we're on rocket chat, and you can join our rocket chat through the, through the hyper ledger rocket chat I will drop the link to that here in chat so you can join that channel if you're interested. So we have a weekly community call as well. And the weekly community call is it's a little smaller audience than some of these meetups usually it's a chance to talk about Firefly discuss, you know, upcoming, either existing architectural things or, you know, upcoming changes that folks may be interested in adding or changing in Firefly, and also just to discuss things about it so you can. Just here a link to this is where our. That's our wiki page there, and you can see all of our community calls on there as well. And we get the link to the chat channel here as well. Yep, I had it right there. Here's the link to our chat channel. Thank you all very much for coming out to this meetup. It was great to get a chance to chat with some of you and I hope that we can keep the conversation going. Definitely join our chat there where I'm very active on there and a lot of the other maintainers are as well. That's a great place to ask questions or, you know, if you're trying it and something isn't working right it's a great place to get help or even report bugs as well. And we would love to continue seeing folks and what we would love for folks to get involved. So thank you very much and hope you all have a great rest of your day. Thank you to Arun and Vikram and others for putting this together. We really appreciate it. Yeah, thanks so much guys. Hope to talk to more of you guys in the future. Thanks a lot Miko and Jim for this exciting session. It was very insightful and we learned a lot and we are definitely hoping that this will grow your community as well for the future. Likewise. Alright, thank you. Yeah, thanks everyone. Bye bye. Bye bye.