 Okay, you were live. Great. Well, welcome everyone to a hyper ledger meetup focus on hyper ledger firefly. My name is Andrew Richardson. I'm one of the maintainers of hyper ledger firefly. And I work for a company called Colito that provides hosting services for blockchain nodes and blockchain services related to that and of course hosting for firefly itself so always love to talk about firefly and the capabilities it brings and the the really easy developer experience for building really powerful blockchain applications. So the topic today is connecting to public and private chains with hyper ledger firefly. This is something that we've been trying to kind of develop more and more in the hyper ledger firefly ecosystem and helping people understand how you can connect to multiple different chains because there's a lot of really interesting use cases kind of developing in the market these days for bridging between private and public chains. So we're going to talk through a lot of that today. Just a kind of quick overview of the agenda. I want to start with an overview of firefly and the firefly blockchain connectors. Just to kind of set the stage I know many of you are familiar with firefly, but I want to make sure everyone knows kind of the pieces and how they fit together. And then I've set up a demo environment that is connected to both the public and private chain so we're going to do kind of an interactive tour of that setup and see how the pieces fit together and what you get out of the box with a firefly development environment. And then you were promised live coding in the description. So we're going to do some live application coding kind of show taking how do those pieces fit together and how could I build, you know, an actual start of an application that can do really cool, you know, coordinating on and off chain and coordinating of public and private chain events to kind of build an actual sort of starter application use case. So that's kind of the agenda today. Since this is a meetup, I'm happy to keep it interactive. If you want to interject with questions or ask for more details on anything. I've got some of my colleagues and coworkers on the call as well that'll kind of help to keep an eye on the chat if you have questions about anything as we go along. So with that said, I'm kind of starting at the most zoomed out picture and what is what hyper hyper ledger firefly is and what it's trying to provide in the Web three landscape. Web three has come a long way and there are so many different facets to it. You have kind of a picture of all these different angles here. In the top right, there's enterprise consortium that I know hyper ledger always pulls a lot of enterprise minded people and these are kind of use cases that are near and dear to to a lot of us, you know, businesses that need to work together that are maybe doing private side change that are very security focused very privacy focused and want to exchange data using blockchain as a way to kind of prove the immutability and the authorship of a piece of data right that's sort of one ecosystem that's been developing in Web three. Then you have all these other sort of you have chains just you know many many different types of layer ones layer twos continually proliferating different chain technologies as people come up with new and different ways to build blockchains and connect blockchains. You have whole ecosystems and defy angles to it right from coins to dows to all these different constructs that are being built on top of Web three. And it can be kind of difficult to figure out you know how do you connect to any one of these different things if you want to focus on one particular individual, there's usually a very steep learning curve for each one of them. And what fireflies aiming to be is to not be any one of these particular bubbles right it's not specifically for consortiums it's not a chain itself it's not specifically for defy but it's aiming to be the glue and the gateway that connects everything else together right. We call it a web three super node. So it's a toolkit it's a set of services that allow you to connect whatever Web three and blockchain technologies you care about connect them together and build real applications on top of them by taking advantage of a lot of integration code a lot of orchestration code and all the kind of really difficult problems that kind of come out on top of these different ecosystems. Many of you might have seen this on some of the other hyper ledger firefly calls but hyper ledger firefly has become a very large project and the name of the game is modularity. Definitely, as an open source community aiming to keep this as modular as possible, and continue adding different tools into this ecosystem with as wide support as possible for for different blockchain technologies. Some of the big pieces in the box here at the bottom firefly cores orchestration engine is kind of the brains of all this, and it knows how to orchestrate all sorts of different events together on chain off chain token events, public chain events private chain events. And that's one of the big value ads that we're going to talk through and how you can leverage that for building an application. But a lot of other pieces here that come right out of the box. When you start a project based on hyper ledger firefly right, it can take your smart contracts and it can give you a piece and make it really easy to build sort of a more traditional application architecture that's backed by a smart contract by converting those smart contracts into HTTP APIs and giving you reliable events streaming out of them. You can do very complex flows between multiple parties. You can have a very strict control over privacy and security, and you can have very strict control over what goes on chain and what goes off chain, and how those things are married together. And you can use these streams of events to trigger application logic based on both on chain events and off chain events and we're going to, we're going to talk through some of that and show some examples of how these flows can can progress both on public and private. And of course there's a whole component to digital assets. Very easy to use token API's minting burning transferring fungible tokens non fungible tokens and tracking wallets. And there's a bit of that in a demo as well so around all that just a lot of the kind of tools that you'd expect from a robust developer ecosystem. We've got K's a CLI tool web tools and explorers metrics. Lots of things come in the box so just kind of plugging a little bit of what Firefly is and all the things that are kind of part of the ecosystem we're only going to touch on a few of them today. But we definitely love to see people get involved in the open source project on any of these pieces that interest you, you know, join us on discord and talk to hear more about all of them. Zooming down a little bit below if you look kind of in this picture, because today we're talking very specifically about public and private chains. There's actually a whole piece of Firefly that you can't see in this zoomed in picture so right here between Firefly and the blockchain is another layer that's very interesting and I think particularly of interest to this audience if you're looking at various public and private chains. And that's the Firefly blockchain connector framework. So, Firefly, again, is not a blockchain node and it doesn't connect to any single blockchain node it provides a set of layers and interfaces for connecting agnostic Lee to any number of different blockchain nodes. So the two well supported connectors that come as part of the open source project or one called EVM connect for connecting to EVM based chains like Ethereum, and then one for connecting to fabric networks. I'm going to be focusing a little bit more on the EVM layer today, just because in terms of connecting to public and private chains. The Ethereum ecosystem lends itself very well to that on there's plenty of public EVM based chains. So we use some of that as a foundation today. But you can actually mix and match you can have a Firefly that talks to a fabric network and an EVM network so lots of capabilities here again trying to keep it as modular as possible. So, below Firefly itself, we have a layer that we're going to mostly be using EVM connector today. And there's this whole API that it leverages that can be used for building your own blockchain connectors as well. So we're not tied into just the ones that are in the box. Sorry, EVM based blockchains could easily be forked off of EVM connect and other blockchains can probably share a lot of the code if you needed to build custom connectors there. One thing that's really interesting in connecting to public chains in particular is that it's been designed. The connector toolkit itself has been designed with a lot of pluggable pieces. The whole connector can be plugged, but little pieces of it can be changed, such as the policy engines. So, a big concern with public chains you know is the fluctuating gas prices getting transactions that are declined because you set the gas price to a reliable estimate of the time on and the gas price fluctuated right and the transaction was rejected. And handling those fluctuating gas prices, handling resubmission of transactions and tracking when those transactions get all the way through. That's kind of all the responsibility of the connector toolkit. And it's a difficult piece of the puzzle to get right, all in its own right. And then by having this connector toolkit and a really reliable connector for EVM based blockchains that can handle all the complexities of gas price and resubmission and monitoring the transactions as they go through, it can then kind of feed reliable information up to Firefly on when the transactions have succeeded and Firefly can then orchestrate that and feed it back to applications. I'm going to pause there because I've talked a lot and I'm showing a lot of slides. Any questions or I see nods over here. Questions in the chat. I don't know if you can see the chat on your screen at the same time but the same question. Some questions are on the blockchain connector framework support for WebAssembly based chains. Also UTXO and how is it different from cacti? Alright, a lot of questions there. And Nico or others, if you want to jump in and help me out with any of these, love to have other maintainers and contributors weigh in, but I'll take a first swing. And it might be helpful actually to kind of break out. I hate sharing slides too much and go kind of show some of the pieces I'm talking about here. I'm going to pause for a second, show some GitHub links that might help some people that are really interested in getting involved in digging in, then try to come back and answer as many of the questions as I can. So, of course, the place to get started is the Firefly GitHub, right? This is the core runtime that was in that big box on the first slide, github.com slash hyperledger slash Firefly. Links to the Firefly documents and links to some of the other important bits. So this is the piece that's kind of off the shelf and it's not particularly opinionated about the blockchain underneath, right? This is the core runtime. Then we have EVM Connect, which I'm talking a lot about. And this is designed to be the connector layer that sits below Firefly and can connect to any EVM based blockchains. There are Ethereum blockchains like Bezu and like Go Ethereum nodes. And also L2s like Polygon that support EVM and JSON RPC. So this is kind of your starting point for any EVM based blockchain. So right now we have very good support for EVM. And if any blockchain is kind of a slight variation on EVM, this would be the starting point to kind of build that. The other piece that I talked about that's a big part of the blockchain connector framework is this Firefly transaction manager, which is leveraged by EVM Connect and would be leveraged by any blockchain connector. This generalizes some of the flows about the policy when I'm showing this kind of policy engine over here. It has plug points for registering your own policy engine and handling, okay, how does my network have gas, right? Most blockchains have some notion of gas, whether they call it that or something else. But how does my network handle gas? How does it handle estimating gas, paying for gas, resubmitting based on failures, that kind of thing. So that's kind of the tour of the pieces involved. If you would like to, you know, get involved in the open source community, these are probably the three that are of interest to you. There was a question about exactly what is supported in the open source community right now. And that is exactly the two that I talked about, the EVM Connect blockchain connector and the FAB Connect blockchain. So EVM based change and FAB Connect for fabric based chains. There are no supported UTXO based connectors in the open source community right now. So that's a place that some people have explored and would absolutely love to see some more people get involved there. It's just one that has not been kind of carried forward to being production ready. Were there other connectors people were asking about? Yeah, and just a quick housekeeping note, if you are not speaking, if you wouldn't mind putting your mic on mute, that would be great. If you have a question that you'd like to raise, feel free to raise your hand and be happy to answer your question, but just to keep down on background noise would be great if folks were on mute. Yeah, so the other question was about like web assembly based chains. I've had some conversations with folks at Hyperledic Global Forum about this and there's no support for that today. Definitely something possible in the future, assuming that the chain has a few kind of core concepts like block numbers and we can go into detail about like what are the minimum requirements of a chain for firefly to support it, but that's probably a deeper technical level conversation that we have time for today. Okay, and then the other question was around how does it relate to cacti? I don't mind taking that one as well. Yeah, go ahead. Cacti and especially weaver are focused on chain interoperability between chains and firefly, the firefly also does interoperability between chains, but the focus of firefly is at the application layer. So it allows your application to talk to multiple chains, whereas the focus of cacti and weaver is solving a chain interoperability problem but at a different layer. Hopefully that answers the question at least at a high level to give you a frame of reference. Yes, the webinar is streaming on YouTube. And I know there's been some talk about, you know, could there be synergy between firefly and projects like cacti and weaver for, you know, if you want to do that interoperability at the lower level and then orchestrate it up and that's, you know, definitely within the realm of things that could be supported because like you said, firefly is all about kind of one level up it can talk to multiple chains but it's not directly doing on chain integration between them. And I'm going to show kind of an example of this, the sort of integration that you can do with firefly at an application level. And hopefully that'll also help make it clear the type of use case that that piece is targeted at. I think I saw a hand up a minute ago I don't know if we got that question or if someone still had a question. Yeah, go ahead. No, it was a cacti and I think you answered it. Thank you. Okay, perfect. Okay, is that good for now to kind of move on. Does firefly allow processing configure configuration updates as part of fabric. Yeah, firefly is definitely sitting on top of fabric at more of a sort of higher level. So a lot of the core fabric constructs remain core fabric constructs if that's kind of a general answer. So, yeah, I don't think I guess I'm not familiar enough with fabric, in terms of processing configuration updates what that entails so I don't have a full answer on that question but the general answer is is a fireplace it's on top of it and it uses the blockchain. And it passes things through and it translates events and the sequences events. But it's not meant to be a wrapper for, you know, all of the functionality provided by a particular blockchain. All right, going to kind of move on and we can get some more questions as we go. Kind of the last slide I do want to share before going into a little bit more of a tour of what firefly looks like and what it looks like to be connected to public and private chains. The concept around decentralized event processing, because this is one of the many things that firefly helps with and it's one of the hardest things I think to get right in a true decentralized application architecture. Because the problem that we're faced with is that a decentralized app architecture means that my app is running without directly talking to other apps that are kind of running on the same ecosystem and I'm talking here about off chain right business applications they're running you know written in traditional languages like node or Java or Python or whatever you know these are not directly on chain but they're applications that want to interact with events that are coming from blockchain right and this is kind of the common use case that's emerging in a lot of Web three spaces right I have existing business logic, or I have new applications that I want to write but I'm not writing the entire thing as adapt that's going to live on the blockchain. You know, there will be pieces that are adapt and there are pieces that need to run off chain in my own sort of infrastructure. So the problem with these types of applications and the problem that firefly is aiming to solve because you know we as the founders and maintainers saw this kind of being solved over and over and over again and it's a difficult problem every time you develop it is decentralized event processing. So, the way that you can set up an application under the firefly architecture is you can run many different applications or different instances of the same application in completely decentralized places right you can have an app running over here in order ones data center or cloud, you can have an app running over here in order to data center or cloud. They don't need ingress to each other they don't need to communicate directly. All they need to communicate reliably is these two kind of pipelines at the bottom, right, a blockchain node with some amount of on chain smart contracts that are going to store. You know, sort of decentralized the dat blockchain state, and then always there's always this other rail for off chain data. It's very rare that you can do an entire use case with blockchain only. And so one of the primary problems that firefly helps to solve is coordinating these two things. I have a private data bus whatever technology I use for that whether it is, you know, HTTP based or a message q based. I have some way for these two apps to directly send a packet of data to each other and then I have some way for them to both access a common on chain smart contract. And then the problem is to keep them both in the state the same state right so this notion of an application state machine is really critical and I'm going to as part of the live coding kind of show what does it look like to spin up a very basic application state machine that can function in an architecture like this. Firefly helps to sequence the events coming from both of these sources right from the private data that sent to me and only me directly from some other member. And also the events that are happening on the blockchain and how do I kind of marry those things together. How do I keep private data private. I sequence things in a reliable order said my app state machines, even though they're not directly sinking state they always end up in the same state, because they process events in exactly the same way so that's, that's one of the difficult problems to solve. And what I'll hopefully kind of show as part of this demo. Did we have more questions popping up. I think Nico answered in Chad there was a question about atomic transactions across multiple blockchains and no firefly at this time doesn't have a cross chain atomic guarantee. So, again, it's definitely something that could be plugged in and you know, love having those continuing discussions but at this time, we're focused very much on the sort of application level integration. Okay, good thanks for the questions keep them coming. So, the architecture for the demo that I'm going to show you today is a bit like this, I have two members. These members are in a private multi party network or consortium right this is one of the use cases in the web three landscape that we talked about these, you know, our organizations that need to share some amount of private data with each other and they want to use a blockchain legend to kind of verify that down. On the other hand member one is also going to serve a role where they need to communicate with a public chain. So they are going to have two namespaces this is a construct in firefly for kind of grouping what your plugins are and what your blockchains are. So both member one and member two are members of a default firefly namespace that is a private multi party network. They're going to share the same type of blockchain connectors they can both talk to a private Ethereum side chain over here so you can see that they're each operating an Ethereum node that forms a private side chain. They're both going to have token connectors so that they could create tokens and share them, and they have that private data exchange pipe that I talked about I'm using the open source firefly data exchange which is based on mutual TLS. And then they have IPFS a private IPFS not public IPFS. This is an IPFS runtime that's shared between them so that they can post data that needs to be visible to anyone on the network right so that's my one name space. On the other hand member one also has an additional namespace for connecting to polygon. So this firefly node is not only talking to a Ethereum node that's part of a private network. It's also talking to an Ethereum node that has been joined to the earth talking to a polygon node that's joined to the public polygon Mumbai test net. So, over here we have a separate namespace that has its own blockchain connector for talking to polygon test net and a token connector as well for minting and transferring tokens on polygon that are visible to everyone. So this is the architecture that I'm kind of setting up. And I'll kind of break out of the slides here again to show you sort of what you get. I'll start with looking at the firefly docs for anyone that hasn't run through this, the getting started guide is really clear and easy way to get started with a development environment on on hyperledger firefly and blockchain. One of the goals of this project is to give a really, really pleasant developer experience and make it easy to get up and running and writing real applications. So, if you follow the getting started guide, it'll walk you through getting the firefly CLI tool, and then starting an environment. By default, you get a stack that's a multi party system that kind of represents a system similar to this right hand side. The command that you run for that is this ff and it by default, you'll get a two or three member stack however many members you specify and you're up and running. It's going to start a bunch of dockers using Docker compose. On the other hand, if you want to connect to public chains, there's another tutorial that might be interesting to you for this connecting for a mobile chains like connecting to polygon. So if you run a slightly different init command with your CLI, you can create a network that connects to public Mumbai testnet right by selecting an RPC endpoint that's joined to that network. Now, getting a more complex setup that talks to both is kind of an additional exercise so I have not included the setup as part of the demo because it would just kind of be me writing YAML for 30 minutes and it didn't seem very interesting. But what I've done is kind of built a stack on top of what you get by adding a bunch of extra Docker containers right so it spun up some of the Docker containers for me and then I've kind of by hand edited my Docker compose override to add a handful of other Docker containers that allow me to talk to polygon. As you become a little more advanced with Firefly, you can build on what the CLI gives you by building custom Docker environments. So I've got a whole bunch of dockers running here. And this is kind of the development environment that I've set up for for this type of public private chain use case. And then of course, when you want to move to production Firefly provides starter helm charts so you can kind of graduate from local Docker and Docker compose to proper deployed Kubernetes infrastructure and just kind of take your same code that you're able to develop locally and put it right out to production proper hosting solution. So I'm starting today with a whole bunch of dockers. And I'll show you kind of some of the tools that come in the box with Firefly as well. So, each node gets a UI so Firefly has a very robust explorer UI. Again I'm sure many of you have played around with this and seen it but if you haven't would highly recommend downloading the tools and spinning up an environment and taking a look at this, you can see. This is node one so he has two namespaces my default namespace is this multi party namespace where I have two orgs in a sort of private network together. And I have my Ethereum blockchain my token connector all the different plug points that you can bolt on that I've been talking about. And he's also a member of this polygon namespace, which is not part of a network it's just a standalone gateway out to the testnet so separate set of plugins for talking to that blockchain. Number two is just part of the network he's not talking to polygon. So this member just has one namespace and is sharing that blockchain node and private data exchange bus with member one for the private multi party network. The use case I'm going to kind of walk through today is kind of trying to showcase a couple of the main things that Firefly helps you do. And kind of put them into a pseudo use case that that might help you to envision some of the ways that Firefly could apply to you or your company or your industry. So the first thing that I'm showing here. I'm kind of doing a an achievements workflow here. So member one is serving as an org that kind of publishes achievements that can be gained. And then other orgs in this private network can submit members that have gained those achievements. And if they are verified, then they receive an NFT on polygon network so there's a sort of private data exchange over here, and then a public testament to that achievement that goes out to polygon. So it's a bit of a made up use case, but you can kind of imagine analogues to this in gaming with NFTs in sort of internal external recognition programs for workers in education certifications, lots of different types of use cases you can imagine where there might be some element of a private network and then some element of sort of publishing interesting things that have been recognized on that network out to polygon. So this is the sort of use case we're going to walk through and show all the different things that Firefly can help you do. I'm going to leverage some of the Firefly UI tools including the Firefly sandbox and I'm also going to write a little bit of code because we're promised some live coding. I'll try to keep it to about 100 lines of code and show that we can do a really pretty complex and robust workflow with just right around 100 lines of code. So the first step in the workflow is going to be triggered with a smart contract. So I have a smart contract. We're going to talk about how you can deploy smart contracts to an Ethereum blockchain and interact with them using Firefly. I'm going to talk about private messaging and how Firefly can exchange private messages that have an on and off chain piece to them and then finally mint an NFT that can be sent to a metamask on public Mumbai testnet because Firefly has a lot of capabilities around tokens. Anything else we should address chat before I sort of start walking through the demo flow. Good to go. All right. So, given that step one is invoking a smart contract, I'm going to start with a smart contract. So for the purposes of the demo, I have written a very, very simple achievement tracker smart contract in Solidity. So this is my smart contract. It has one method called add achievement. So whatever member of the network is designated as the owner can basically add achievements that can be gained in this network and then other members of the network can claim them when they testify that they've achieved them. All right. So I'm going to start with this smart contract. I've got a simple sort of hard hat project here. I can compile the smart contract and then I can use Firefly FF deploy Ethereum to deploy the contract network name. So my Firefly stack that I've set up is called Meetup. So, now the Firefly command line can't be used for deploying every contract in the world but it's a really good starter. And again, something that just comes in the box for deploying Ethereum and fabric contracts. All right. So my contract has now been deployed. So my contract is now deployed and this deployed it to the internal private blockchain just to be clear. We're not putting this out onto Polygon at this time. This is part of the sort of right hand half of this picture in the side chain where these nodes are operating. So I got the address of where my smart contract has been deployed. The next thing that I need to do to interact with this contract in a really, really easy way is to tell Firefly about it. So I'm going to go to another tool that comes in the box with Firefly called the Firefly Sandbox. And because I'm running all these dockers locally, I'm playing the part of every member in this network. I've got two members. So I have two Sandboxes, right? This is member one Sandbox. This is member two Sandbox. The Sandbox is kind of part demo tool, part code bootstrapper. And it's a really good place to start playing around and learning the different things you can do with Firefly. But it's also kind of a good tool for doing setup in a quick way. So the first thing I'm going to do is tell Firefly about my smart contract that I deployed. And Firefly calls this a contract interface. So I'm going to define a contract interface. The two formats that Firefly understands are FFI, a Firefly Interface format, which is kind of a format that we have specified as part of the Firefly project. That's kind of blockchain agnostic defines methods and events in a generic fashion. We also want to support any blockchain that has its own format of describing a smart contract interface for Ethereum that's the AVI is kind of the standard. So I'm going to go ahead and I'm going to grab the API. So we'll go in here and extract the AVI from my compiled contract. So that's the AVI. I can just go right into the Sandbox and paste that whole thing in here. I give it a name and a version. And you can see here the Sandbox actually helps me to see what the JavaScript code would be for deploying this, or I can just run it directly in the browser. I'm going to go ahead and run it now. You can see it's submitted to Firefly and it tracks as the asynchronous events come back. And what this is actually doing is not only defining an interface for me, but because I'm doing this as part of a multi-party network, it actually broadcasts a message to everyone in the network. So I'm going to look over here at my timeline of events on the multi-party network. There's Node, the one that I just created the contract interface from. And we see this batch pin transaction. Batch pin is one of the functions that is built into Firefly, and it's basically a classic on and off-chain marrying of data. But it's a very kind of complicated piece the more you drill into it. In the case of a broadcast, we're leveraging the private IPFS over here. So something like a contract interface is something we want to be visible to everyone, you know, whether they join now, whether they join later, this is going to be an interface that's going to be shared by everyone in the network. So my definition of these methods and events is going to be put in IPFS, and then it's going to be hashed, that data is going to be hashed, and then a blockchain transaction is written with the hash of the data. And then you can always go back and replay the blockchain transactions on this batch pin contract that's supplied by Firefly. And you can see the order that all this data was created, right? So the blockchain provides the ordering and the authorship of the data, but the actual like heavy data payload can be off-chain in this case in IPFS. So Firefly kind of does this all for you, coordinates the on and off-chain message. And we'll see a few more instances of on and off-chain throughout the rest of this demo. But if I go to member two, they get the same message. They know that this new contract interface has been confirmed called achievements. Now that's just defining the shape of the interface, not where to find it. So I can go one step further and use that contract interface to create a contract API. I'm going to call this achievements as well. And now I can specify a contract address. So this is the address on my sidechain where that contract was deployed. And we can see kind of sample code, but I'm just going to run it here. It's going to do the same thing. It's going to advertise the details of that API to everyone in the network. And the cool thing is now Firefly has taken this contract interface and the location of it and it's generated a nice little open API document. And I can actually interact directly with this smart contract using HTTP instead of having to do it, you know, over Web 3 JSONRPC type of calls. So I can invoke my methods here. And member two can also see that this thing's been created, right? So within a multi-party network, you have this ability to create things like contract interfaces and APIs and have them implicitly shared with everyone so that everyone can interact with them. Moving on to kind of the next step. So now that I've got a contract deployed, the other construct that I'm going to need to set up ahead of time in this flow is a place to put tokens. So in order to mint an NFT or to do anything with tokens in Firefly, you have to create what we call a token pool. It's kind of a made up word. It could be a single contract like an ERC 721. It could be an 1155 contract might have multiple pools, right? Some flexible token standards can let you create many different types of tokens within a contract. And then, you know, it's blockchain agnostic. So if, you know, you want to create token constructs based on fabric, you can define, you know, what does a token pool and a token look like over there. For this use case, I'm going to keep it pretty simple and use an ERC 721 non-fungible token. And I've already pre-deployed a contract out here on to Mumbai, since sometimes it can take a little bit to get those out there. So this is my contract. It's a pretty straightforward ERC 721. And I'm going to tell Firefly about a token pool. So I'm going to switch over to the polygon namespace. Still working through the sandbox here. Using the tokens tab, I can get the address and the block number of where this ERC 721 is deployed. So there's the address. This is block number. And I give it a name. We'll just call it, we'll call it achievements. I'm not going to fill in a symbol because for a 721, it'll actually read it from the contract. Nope. And it's saying I got an error because it's not a fungible pool. It's a non-fungible. Try that again. Okay. So now I have created a non-fungible pool. I'll see probably a failure in here. And then that's the wrong namespace. All right. So back on the polygon namespace, right? The sort of left-hand side of my diagram. I tried once to create the token pool and it failed. I tried it again with the actual correct parameters and it confirmed. So now if I go to tokens, I'm now tracking this pool. So it's now indexed that 721. We will probably see in a moment because I did test out on this contract and mint a few NFTs earlier. So as it catches up to the current head block, it should actually find some transfers and index them here because it's going to start from that block that I said. And it's going to start indexing all the things that have happened on that contract and hopefully it'll catch up to the current time by the time we get there. All right. So I think that's all these setup and kind of a tour of some cool things you can do with the Firefly sandbox. So I've deployed a private custom contract into my side chain. I've deployed a sort of very straightforward, simple ERC 721 onto Mumbai Testnet. And I've set them both up so that Firefly knows about them. It knows about this API that it can use in the default namespace and it knows about this token contract it can use in the polygon namespace. So this is the part where I start doing coding. So hopefully everyone's ready for it. Hopefully I'm ready for it. I said the first step here is going to be invoking the contract. I'm not going to do that first domino. We'll save that for last. But I'm going to start by showing, you know, what does it look like if I was going to write this application state machine, this logic over on member two to trigger things based on an on chain invocation of a smart contract in Firefly. So the other thing I've done as a kind of a starter here is to zoom bars in the way. Okay, to set up two starter projects, very simple typescript projects. I've got one that's kind of for member one and one that's for member two. So we're going to start here and member two kind of give you a quick tour of you know what is the code look like when I want to write an application on top of Firefly. So the first thing I want to do is listen for this event coming up. So I'm going to go here. I'm going to start by initializing a Firefly. It's very easy to do with the Firefly SDK. I tell it where my Firefly is. Again, I'm running everything in local dockers. The port that's assigned to my member to Firefly by default is 5001. That's the default namespace. So that's my Firefly instance. The other thing I need to do is to create a subscription. So when you want to do this event driven processing, you need to create a Firefly subscription. Basically, it's a checkpoint for you. This subscription is going to keep track of what are all the events that Firefly has delivered to you as you act those events, it moves your checkpoint forward. It's a viable delivery from Firefly. So all you need for subscription is a name. So I'll just create. I'm going to use replace subscription which will basically create it if it doesn't exist already. If it exists already you'll leave it alone. So that's just going to create me away and I will tell it. I'll tell it to start from the oldest event. So when I start the subscription, it's going to deliver me all the events that Firefly knows about. Now you can do a lot more with the subscription. You can filter types of events. You can say I only care about tokens or I only care about messages or I only care about custom contract events from this particular contract. For simplicity, I'm just going to tell Firefly to deliver me everything. But generally you would filter this a little bit more for an application. All right, and then all I have to do is start listening for the events. So it's pretty simple to start writing an event-driven application in Firefly. All right, so this I just provide a callback. I tell what subscription I want to use. It's going to connect to that subscription, start from wherever the last point I was at, and it's going to start triggering this callback for every event that comes in. I'm going to, I think in the interest of being slightly correct. I'm going to create a little class here that this would be my event handler. So this is a piece of logic that you kind of are going to have to implement for every application. And he's just going to have one of that for handling the event. And you can see with the TypeScript developer experience is kind of tailored to be very nice and easy. We've got a fully fleshed out SDK with types and everything that kind of helps you along. Another thing I do need to set up, because what I'm listening for is a custom blockchain event that's coming from this achievement tracker contract. So I do need to do one more thing in the sandbox, and that is register a contract listener, because Firefly is not automatically going to start cataloging events from every contract on the blockchain. You do need to tell it what contracts you're interested in, and then it will suck those into its own database. So I've deployed this achievements contract onto my side chain. I'm going to tell Firefly I'm interested in this achievement available event. I give it a unique topic. And so this is just going to do a one time setup where it's now created a contract listener so anytime that contract. The event that I deployed emits this achievement available event Firefly is going to index it. And then by extension, if I'm listening to events from Firefly Firefly will deliver the event to my application. I can now tell it to handle the event. And I can say, if that event is a custom blockchain event. This is what I'm going to receive. I'm going to bring in I can look at the details of that to make sure it's fine. We'll go fast and loose here because we're live. But now I can actually inspect the event to see what came from the blockchain achievement available is the event that I'm looking for. And I said that based on this flow, if I get that I would check and see you know which of my members are eligible to claim this achievement, and I'm going to send a private message back to org one for all those members. So, using the sandbox to kind of help me bootstrap here, I'm going to say, Okay, I want to send a private message. I'm going to send it privately to that org. I'm going to give it a unique tag. And it actually generates my code and I'm going to take this code and pop it into here. So my achievement event has a name so we'll expect a name that's called meet up attendee. And then I can kind of trigger this logic, I can say okay when I receive an event on chain. I'm going to now send a private message that is an on chain off chain coordinated message back to org one to say, Okay, the eligible members are just hard code them for now. And I'm going to tell it. I have a metamask wallet address. So I have a metamask wallet that's connected to the Mumbai test net. Alright, so basically what's happening here I'm listening for a blockchain event. If the event matches what I'm looking for, I'm going to send a Firefly private message, and I'll log it. So if I now run this listener. See if this works. It's going to catalog a bunch of events that happened ahead of time, but now if I send it a smart contract invocation and it gets the event it's looking for. It should claim the achievement. So, go to my contract API. I'll show. I'm going to advertise by doing a smart contract transaction. There's a new achievement available called meet up attendee. This is going to write a transaction to the blockchain. It's going to show up over here. All right, yeah, it all went through. Okay, so, so you can see my logs here I got the event and I replied with a private message. So we're running short on time and I know there's a lot going on here. But basically what happened my running application my state machine received that blockchain event based on Firefly sequencing and delivering the event to that application. It consumed that event. It replied by sending a private message. This is using that batch pin technique. This message, the body of the message is going to be delivered off chain in the private data exchange pipe from member two to member one, but a hash of that message is pinned on chain so all members can see it. And then member one is going to receive that message and now we could trigger the last part of the flow and say, you know if member one receives this message, go ahead and mint an NFT. I actually guess I should probably stop and ask if there's questions before I do any more live coding. Anything you guys been keeping track as it's been scrolling by. Okay, I've been trying to answer questions and chat as we're going here. There's a question about what about older events and what would be your subscription. Yeah, so one thing I want to make sure is kind of clear and it can be a little confusing is that there's one level of sequencing that is coming from my outside data sources into Firefly right like blockchain events coming into Firefly. We call that construct a contract listener. And when I create a contract listener I can say okay what what block number shy start listening from. And similarly in a token pool I can say what block number do I start listening from so for my custom contract that's on the side chain I just started from block zero because it's a very short chain, and I just deployed the contract very recently for the token pool on polygon I of course put in a start block number that corresponds to when the contract was deployed because listening from block zero. I just take a really long time to catch up and find nothing. So that's the first level is sequencing things into Firefly whether they're token events or blockchain invocations, then there's a second level of Firefly providing a reliable subscription and checkpoint for your application. And that's this construct that I was showing here where I create a subscription and I name it. And this option here tells, okay Firefly. And what you have and your checkpoint that an event number that you've assigned to these events. Where do I want you to start delivering to me oldest is usually a good choice. Because, especially if you're joining a network late you can still say oldest, and you can replay everything that's happened on that network, whether it's, you know, all the transfers that Firefly has cataloged or all the blockchain invocations or all the messages, you can replay them all. If you want to join and just say okay this is a new thing I don't expect there to be any history you can you can start from newest. So there's there's two levels of indexing and it at each point you can say you know do I want oldest or newest or something in between. Yes, so for and I'll just chime in here a little bit to add on to that for an existing chain that may have lots of other things on it or the chain might be quite old. The best practices actually to specify the specific block number that you want to start listening from, because that will produce the least amount of wasted work by the system to go look at blocks that we know will never have an event in it that matches the thing that we're looking for. So in this case, you know, say this this network that Andrew had stood up had been going for a year and then he deployed this contract as a new thing the network is now doing. You would want to pick the block number that his contract was first deployed in as the point in time to start indexing from that point forward. Yeah, exactly. Well, should I take the last five minutes and mint an NFT. So I will show starting out here I ran this test a couple times so I have two NFTs that I've already been minted in this sort of public polygon. I'm going to kind of real quick try and show this the second arm and I'm going to make an app that would represent okay what is number one doing and listening for a message and then minting an empty. So some things are going to be the same. They're both they're going to need a firefly, but they're actually going to need to fireflies, because they're listening to two different namespaces. So they're both on port 5000 the same firefly but it's a different namespace. So you interact with them differently. They're going to need subscriptions for both of those. I'm listening to two different streams of events here. They're on two different firefly namespaces to do it. And then we can create a listener for both of them. So I'm going to listen to all the events on both namespaces again you'd normally kind of filter this a little bit. Okay, so I created the same kind of event loop I created subscriptions for these events I'm going to listen to everything. All I care about here is message confirmed. So when I get a message confirmed, look at it, then I can fetch the data associated with it. So I'm going to fetch the data from my consortium. It's a piece of data that was shared privately within the consortium, and then I am going to send the NFT to the wallet address. Actually, I think what did I do I put an array, put an array called eligible. So we'll be quick about it. We'll assume that my data really matches what I'd expect. So I pull out that wallet address. And now I can go see okay how do I do a mint on polygon. I can grab one more code snippet say I want to mint an NFT. I can copy this as well. I'm going to mint on polygon meant one to this token pool to the wallet specified. And that should send me an NFT on polygon. Now again because I set these subscriptions up from the oldest event. As soon as I start this app it should get the messages even though they were already sent a second ago so we're going to see if this works. I didn't check if my data. I'm so there were other messages that firefly sent. So I only care about messages that had the tag. So I don't care about these claim achievements. All right, try one more time and then we'll be done. There we go. So I processed all the messages. I should have received a private message and then cause that private message to trigger a token transfer on the polygon subnet. And let's see if we got it. I got it. So now I have three NFTs. Oh, so that's all demo. So there's the that so kind of whirlwind here at the end but showing kind of hopefully driving home. The fact that firefly is this application level orchestration right you can use it to do if X happens over here do why over here and that's actually really, really useful for a lot of common use cases. In this case, you know showing. Okay, I did some logic within my network some of it involved custom smart contracts events, some of it involved on plus off chain coordination of private messages. Based on the state that all that ended up one of my members also decided to take action on a public network. And all done in just about 100 lines of code so a lot of complicated stuff going on, but kind of wanted to show how this stuff builds up and how it's going to trigger a lot of complicated blockchain application logic. I know we're over time I don't know if we can go and take a few more questions before we close out any that jump out I can try and scan through but I'm like 37 behind. Yeah quick question Andrew if you could show where you defined which when you sent the private message to find the recipients of it who could see that message. I just pasted that from the sandbox so it probably scrolled by really fast. But right here is the API for sending a private message. I put this tag on it right a tag is okay you know what is kind of like a subject what is the type of message I'm sending. And then here I have this group. The group is going to define the identities using firefly dids that are going to get this message so it means these identities and this of course. It's a randomly generated org but this is my member one in this example so this is number two sending it directly to number one. They're in a privacy group, the private data is going to travel directly off chain from number two to number one. They're never going to be on chain directly but then a hash of that data is put on the chain so both of them and potentially any other member could always verify like that hash happened at this time yes it was definitely signed by member two by their well known blockchain key. Yeah, and this is the idea is also visible in the firefly UI right. Yeah, yeah so all this we did not tour that part of the firefly UI but if I go to my multi party namespace and go to the network. So the orgs in my network right so this is me. It's this org ending in bf to a for right this is org one. So that's who, who is the recipient here. But you can see this org has a DID for kind of specifying the identity a high level, and then they're tied directly to a well known Ethereum address so every org has at least one Ethereum address that you can use. Okay, if I sign transactions with this you know they came from me. And then, can you show again where you subscribe to the event of the climb confirmation, because I see that there is two subscriptions for the same, get let's say topic. And I'm not sure if I understood it well. Yeah, so you're talking probably about this node, node one where I'm listening to two different namespaces. So the way the SDK is structured is you the easiest way to use it is to construct a separate object for each one because you have to create separate subscriptions per namespace. The handler for minting is in the in the polygon name space. So that's why you also have to be subscribed to the same topic in the polygon name space in order to be able to meet. Yeah, you're right I technically didn't need to listen I didn't act on any polygon events I I logged them. So I probably should have changed my logs to, to log something different. But yeah I was logging them also some of these events, like the token transfer confirmed this was the result of the mint. Right so I was listening to them just for the purposes of logging them. Since I didn't act on them, I really could get rid of this and just say okay I'm only going to listen to events on the consortium namespace. But just kind of highlighting you can listen to both feed them into a single event handler, and kind of act on events from both sources. But yeah they're separate subscriptions with separate checkpoints right fireflies keeping a stream of events for this namespace and a stream of events for this namespace and I can ask, you know, to be delivered both of them. Yeah, it makes sense. It gives a lot of flexibility in fact. Okay. Guys anymore. I see a ton I know Nico thank you for fielding so many in the chat. Sure. Yeah, no I think we're caught up in the chat. Okay. And for the subscriptions are there any limitations or something like that do they expire if you don't listen for them for a while or. No, no, they won't expire the design of the subscriptions is to be durable you can create what we call a femoral subscriptions. For instance, the UI opens an ephemeral subscription so you might have seen it doing some live refreshing. But you know it doesn't care about saving state but if you're doing this sort of create subscription it's durable it's going to be stored in the database, your checkpoint will be retained. You know as long as that firefly databases there. And this code, for example, on a QM9 disk cluster with multiple pods, and there are different listeners running the same code. Do they receive all the pods the same events or is there some kind of identifications to know that the different calls running the same subscription will receive only one one at a time. Yeah, that's a great question so generally your subscription name should be unique so this would usually be tied to your application I called it meet up subscription right because I was creating this demo for the meet up. You would usually only have one application that's using a single subscription. If you have two applications that are talking to firefly for two different use cases they should create separate subscriptions. When it comes to horizontal scaling. It's, you can actually choose different strategies for firefly to deliver events. The default when I'm using here is web sockets there's also a web hook subscription. But with the web sockets you can choose different load balancing strategies. It's kind of, you know, beyond the scope here, but there's definitely sort of basic support for scaling those and deciding how I want to handle a single subscription with multiple listeners. Okay, cool. Thank you. I got a question, talking about the limits of the subscriptions. Is there a limit of the amount of subscriptions you can do on a namespace. No, there's no practical limit. It's just, you know, database storage and I'm certain, you know, past a certain point it will require processing overhead but yeah there's no there's no practical limit on the number of subscriptions you can have to firefly. Thanks. Alright, I will make, I will make a question directly. Are the subscription at least once or just once per application. The subscriptions are at least once. Yeah, at least. Yeah, so there's an act. It's kind of hidden in the API. When this listener callback returns it actually transparently handles the act but you do have to act each event. And but firefly in the case of a communication loss or a crash or something. You could get an event that's delivered twice or yeah there is responsibility on your app and your app state machine to handle item potency. So each event has a unique idea set associated with it in a robust production state machine that's, you know, 10 times more advanced than this you would want to track those ideas and track which events that you've processed and avoid reprocessing them. Okay, thanks. Thanks. Yeah. All right, well I'm sure we could go on and on with questions but I think it's probably about time to call it and say meet us on discord for the rest of them I really appreciate everyone sticking around and walking through this and asking great questions. And hope to see you guys at future hyper ledger and firefly events. I know later in the spring in March Nico is doing a much more involved walkthrough I think two or three hour session with more interactive coding will go a little slower. So definitely put that one on your calendars and yeah hop on the hyper ledger discord to chat with us in the meantime. Yeah, and Andrew if you don't mind just one more quick advertisement. If you enjoyed the session or interested in the firefly project. If you wouldn't mind giving it a star on GitHub. That would be really appreciated. It just helps drive visibility of the project and this. Yeah, we would just love to get more visibility on the project and get more as many people as we can involved so thank you so much. Great job Andrew. Yeah, thank you Nico and yeah links here, please get involved in the open source community check out firefly check out EVM connect, check out the blockchain connector and transaction manager if you have any desire to start talking about better policy engines Connectors would would love to see more people get involved in that sort of public chain space with us so thanks again. Hope everyone has a great day. Thanks Andrew thanks everyone.