 Okay, you're alive. Welcome everybody. Thank you for joining us for our hands-on workshop today on how to build Web3 apps with Hyperledger Firefly Super Nodes. Really, I'm gonna have everyone today. We had a great webinar last week talking about Firefly and the 1.0 launch and there was a brief demo at the end of it, but I think there was a lot of desire to go deeper on some things and to really get more hands-on. So today is gonna be hands-on and I'm really looking forward to it. Before we get in, just here's the agenda of the things that we're gonna be going over today. I'm gonna cover a couple of housekeeping items. I have a few slides to kind of set the context for the workshop as well as introducing Firefly. The bulk of this time will be, the hands-on workshop will actually be in a terminal and in a web browser using Firefly and doing blockchain stuff. So it's gonna be really exciting. We're gonna leave about 20 minutes at the end for some roadmap discussion and Q&A. But again, the bulk of it is gonna be the workshop. The whole session will be an hour and a half. So that's the agenda. On to some housekeeping items. Please note that this workshop is being recorded. This workshop must abide by hyperledger code of conduct and the antitrust policy. If you're not familiar with those, you can find them both on the Hyperledger Foundation Wiki or I guess you can't really click the link there, but my slides are linked to them. Couple other housekeeping notes. There are a lot of us in this Zoom, which is awesome. I'm happy to see such a great turnout. Please keep your mic muted if you're not speaking. Right now I'm the only one that's speaking. So if you're not me, please go ahead and go on mute just to cut down on background noise. Please, please prefer chat as the first resort for asking and getting questions answered. And again, we would prefer you using the Discord chat as David was mentioning earlier, the Discord chat in the Hyperledger Discord server under the Firefly section. There's a dedicated Firefly workshop channel that we just created this morning. So go in there. Some of the other maintainers are monitoring that and I will be happy to answer questions as we go along. If you'd like to speak during the workshop, that's okay. I would love to keep this interactive, but just please go ahead and raise your hand and wait to be called on. Again, there's a lot of us in here and this will just kind of help us keep it organized and keep on time. I'm happy to take some questions as we go, but there's a lot to cover and I'd really like to keep us on track and on time. So that's it for housekeeping items. Thanks for bearing with me while we go through that. Let's talk about what we're gonna do in the workshop today. So we're gonna use some pretty cool tools here today. You may be familiar with hard hat already. Hard hat is a pretty common tool for doing Ethereum development, testing, contract deployment and that sort of stuff. So we're gonna use hard hat and we're gonna compile a custom smart contract. We're gonna deploy it to a blockchain node running on our machines and we're gonna use that contract with Firefly. And what we're gonna be doing today is I'll have a slide on the end result, the end goal of the workshop in just a minute. But the other awesome tool that we're gonna be using is Hyperledger Firefly. And that's probably what most people are here to learn about today. Hyperledger Firefly, if you are not familiar with it or didn't get a chance to watch our webinar last week, we described Firefly as the first open source super node, which is a complete stack for developers to build and scale a blockchain Web3 applications. So what is the value of Firefly? Where does it fit in the blockchain ecosystem? Well, it's not a blockchain itself. It's not a DLT. It sits a layer above that. But Firefly, the value to a developer, I'm assuming that most of us are developers in this room. And so kind of looking at things through that lens. The value to the developer is that it takes care of this whole stack of things that developer needs to build. You can see on the left, we have this diagram of like, okay, at the bottom we have our blockchain and our smart contract. And that's kind of like, oftentimes when we're building a Web3 app, that's what we think of first. We go to, okay, what's the logic that goes on chain? What's the smart contract look like? And then all the way at the top, we have our business application, our web UI, our user portal, or maybe some sort of business back office system that needs to be integrated there. But like, how do you connect all of the things in the middle of that? Once you start getting into building an enterprise Web3 application, you realize that there's a lot of plumbing and a lot of electrical work. And all these things that are not very fun things to develop that you still need in order to actually build out an entire enterprise grade Web3 application. So that's the gap that Firefly fills. It's a platform. It's a common foundation to build enterprise Web3 apps. So what types of things does it have in it? It's got a lot. If we kind of break it down into three main groups, though, you've got apps, you've got flows and you've got digital assets. And we'll actually walk through a bunch of these use cases in a little bit, kind of breaking them down into these three groups. So at the center, you've got the Firefly Core. The Firefly Core is an orchestration engine. And it's coordinating things that are happening on the blockchain, things that are happening off-chain. It provides a really easy to use REST API for developers to access all these functionalities. It provides an event delivery mechanism over WebSockets. Some of the other really cool things about it is that it's a microservice architecture and it's very pluggable. So there are specific implementations that we'll talk about the things that we're gonna be running on our machine later. But if you wanna use a different database, for instance, or if you want to use an entirely different blockchain, those are plugins into Firefly. And so Firefly is very modular. It can adapt to meet specific needs for specific business cases. And it's a really cool architecture. So I'm not gonna spend a ton of time on what Firefly is and all the value that it brings. There was a great webinar on that last week. I hope that as we use it, you'll start to see the value and some of the power behind it and the really cool features. But I just wanted to paint a little bit of a picture before we jumped in here. Okay, so what are we gonna build today? Today, my goal is that you walk away from this workshop having all the pieces that you need and the understanding to go build a Web3 app with its own token economy powered by Firefly. So how are we gonna do that? Now we're gonna use hard hat. We're gonna compile and deploy a custom ERC-20 contract. We're gonna use the Firefly Sandbox to walk through using Firefly's APIs in a very approachable, user-friendly manner, which will provide us sample code snippets that we can look at to see, okay, how would we go build this feature into our backend, into our application that we're gonna build in the future? So at the end of today, you won't have a full end-to-end working application, but you should have all the knowledge and all the pieces that you need to go build that. And we'd love to just see the creativity that people come up with and the ideas that this will spark as people start to see all the different things that they can do with Firefly and an understanding of how all the pieces fit together. So the things that we're gonna be doing in the Sandbox, we're gonna create an API, we're gonna look at the Swagger UI that's generated for our smart contract. We're gonna mint and transfer tokens from the Swagger UI. We're gonna create a token pool to let Firefly index all of the ERC-related transactions. We're gonna send broadcasts and private messages and kind of look at all of the three main groups of features in Firefly. And throughout all that, we're gonna be using the Firefly Explorer to inspect and kind of see what's going on inside Firefly as we're doing these things. The tools that we're gonna use, again, so we're gonna be using Hardhat, the other tool that we're gonna be running on our machines is the Firefly CLI. I'll walk you through how to set that up in just a minute. Firefly CLI is a tool that will set up a local Firefly development environment on your machine. It uses Docker Compose to do this. That's why Docker is one of the prereqs. And it gives you all the components of what we describe as a super node right on your laptop. So what goes into a super node? So what we're gonna be running when we run the Firefly CLI and it starts up a development stack is, so you'll hear me talk about different members of the Firefly network. So you can think of different members as perhaps different organizations or different companies. Remember, the context here is building enterprise web three apps. So you may have different businesses that need to transfer data, transfer tokens, perform business transactions backed by blockchain. So that's what each of the members are going to be in our Firefly network that we're going to stand up or our Firefly stack. Each of those members has their own super node. And so inside the super node, you have a Firefly core over here. Each Firefly core is connected to a database, data exchange, blockchain connector, tokens connector, so on and so forth. There is to keep things simple and as lightweight as possible. There's one blockchain node that will run on your machine and both super nodes will end up actually just sharing that same blockchain node. So as we're going through, we're gonna be using Firefly cores API. We're gonna be using the web UI, the Firefly Explorer, to look at what's going on inside there that web UI is actually hosted by the Firefly core. We're also gonna be looking at the Firefly sandbox. You can think of sandbox as an application that sits outside the super node. It's an example of an end user application that is written to use Firefly's API. So it's not part of the super node, but we ship it with the Firefly CLI because it's an awesome tool to learn about Firefly and try it out all in a web browser. It will also provide code snippets of how to use, how to build these functions in the backend. Okay, so before we jump in, I'm just gonna check on chat here. It looks like there's a few questions that have been going on here. Any big questions that any of the other Firefly folks that are online think I should address before we hop into actually getting hands on? Okay, I'm gonna share my full screen now. Give me just a second to do that. All right, here we go. So here's our workshop guide. This is the GitHub gist that I linked to earlier. Hopefully the font size is readable for everyone. Kevin, does it look like it's coming through okay to you? Yeah. Okay, great. If I need to adjust font size or anything, please just let me know. Happy to zoom in on stuff. Hopefully the screen size should be good though. Okay, so hopefully you've had a chance to go through the before the workshop section and make sure you have Docker. The Firefly CLI will also use OpenSSL. We'll also need Node.js installed. Hardhat uses Node.js. And so that's why we need that as well. So increase font size, got it. Good. Yeah. Okay. All right, so what we're gonna do first is I wanna get the environment created and get a blockchain node running on my machine. So we're gonna use the Firefly CLI to do that. I'm basically gonna walk you through the getting started guide. So if we pop over to the Firefly docs, this is the getting started experience for folks who are coming new to the project and walks you through installing the CLI, starting an environment and using the sandbox. I'm gonna be walking you through that today. So we're gonna start with installing the Firefly CLI which is the first step there. Okay, so if you happen to be a Go developer and you have Go set up on your machine, you can just go install the Firefly CLI. If not, that's okay. If you don't wanna worry about setting up a Go dev environment, that's not a requirement. In that case, we can go to the releases page. So we'll go to download the package for your OS, go to the latest release page on GitHub and we will just download the appropriate binary for our machine. So I'm running on an M1 Mac here. So I'm gonna download the Darwin X-84, sorry, RM-64, they both have a 64 in those. I oftentimes get them confused at first glance. Okay, I'm gonna download that and make sure you download the one that's appropriate to your system. If you are running on Windows, you should be able to use the Linux binaries in Windows Subsystem for Linux too. And if you have Docker set up to use WSL too as well, that configuration should work for you. Okay, I'm just gonna, there's a handy command here. Basically, we just need to unzip this thing and put it somewhere on our machine that we can call it. I've got a command here that I can copy and paste to put it in my bin directory. So I'm just gonna do that here. I'll make my font a little bigger in my terminal. Ask me for my password because that's a directory and type it correctly. Okay, there we go. So now that we've got, I have the Firefly CLI binary installed in my bin directory. So I should be able to run FF version. And you know what? I have a version compiled from source. Hang on, let me get rid of that. Sorry about that. Okay, so if I run FF version, now my Mac is gonna say, hey, you didn't pay Apple a whole bunch of money to sign this, so I'm not gonna run it. That's okay, we can deal with this. You just hit okay. It's gonna kill it, that's fine. It'll go to system preferences, go up to security and privacy. And then, so it'll say FF was blocked because it's not from an identified developer. We'll allow that, that's fine. The next time we run FF version, it'll say, hey, are you really sure you wanna run this? Yes, okay. And then there we go. Okay, so I'm running 0.0.48. So that's the latest release that's out there. And hopefully you've been able to get that and run that on your machine as well. Okay, let's go back to our guide and see where we're at next. So we've got the Firefly CLI installed. Now we're gonna create an environment. So this is kind of step two in the Firefly Getting Started Guide. Set up a dev environment. I'm gonna use a slightly different command than what's in the Firefly docs because A, I wanna use ERC 20 and the default is ERC 1155. And then I also want to customize the names of the organization. So this command is going to initialize a new stack. It's gonna call it workshop. It's gonna create a network of three members. That way we can demo both public and private transactions. And I'm gonna use the ERC 20, ERC 721 token connector. And then the prompt names command here is going to just let me type in my own names for all the organizations and nodes. Before we create it, I just wanna highlight real quick all the different. So if you want to see all the different things that the Firefly CLI can do, you can run FF help. It will print out. Here's all the commands that the Firefly CLI can do. If you wanna know, hey, what are the different things I can customize in a Firefly stack when I create it, you can run FF init dash dash help. And here's the full list of options. So you can customize which blockchain it uses. If I add a dash B space fabric, it will use a fabric blockchain. We're not gonna demo that today. We're gonna focus on ERC 20 on an Ethereum node, but you can do that. You can have it use a Postgres instead of the built-in SQLite database. You can enable Prometheus metrics. There's a bunch of different options that you can set here. Okay, so we are going to, I'm gonna just copy this command here. And I'm gonna run this. And for clarity of the workshop and the demo, I'm gonna name my organizations and nodes red, green and blue. And I have three different themed Chrome browsers that should match those colors if I get the order right here. And so you can name them whatever you want. The name here is not important. If you don't use prompt names, then it will just go with default names of org zero, org one, et cetera. So I'm gonna call this one red. And then I'm gonna name the node for this one red node. And I'm gonna call this one green. And green node, blue and blue node. This will just visually help give a little bit of an indicator of when we're looking at the three different browsers, which perspective we're looking at the network from. Okay, great. So we have initialized the stack. We're not running it yet, but let's go ahead and do that. Before we run it, just wanted to call out, if you are running on a machine like mine on the Mac, that there actually runs Docker containers inside of VM. I wanna make sure we have enough RAM allocated to run this because it will start up quite a few Docker containers. If you need to double check that, you can go up here to the Docker desktop and click on dashboard. We can hit the little gear icon here and then click on resources. I recommend at least a gigabyte of RAM per member. So I'm using three members here. I usually give my Docker VM like seven or eight gigs of RAM. And that tends to be great. So just wanted to point that out. If you don't have enough RAM, unfortunately some of the, yep, unfortunately some of the processes struggle a little bit with not having enough RAM. Okay. So now we're gonna run ffstart and then we're gonna tell it to start the workshop. All right, so we'll let this go for a little bit. It's gonna pull some Docker containers. It's going to initialize our blockchain node and start everything up. I'm gonna pause and kind of catch my breath here a little bit. I also got feedback that I maybe need to slow down a little bit cause folks are trying to follow along. So I apologize if I'm going through this too quickly. There's a lot of exciting stuff I wanna share but I'm just checking out chat here. Okay, any, before we hop over to hard hat and start looking at the contract, anything that I can help clarify or any questions that we wanna address before we move on to kind of the next phase here in the guide. So I think the questions Niko, I can just see as we've been tracking in the chats. I think we've got people following along which is fantastic and as you're going and people have been just really focused on making sure they've got what they need on their machine. I wonder if a couple of people maybe on the chats could just know if they've got there successfully and just get a confirmation from a couple of people that they've got there to this point and whether we need a couple of minutes to just allow people to catch up here. Sure, yeah, anyone has anyone been able to get to this point where they've been able to start a stack on their machine along with me here? I'm starting my machine, it's initialization. Awesome, okay. It may take a little bit longer than what it did on my machine. I probably had a lot of the Docker images already. So, okay, yeah, somebody had something listening on. Yeah, so there are quite a few ports that are exported. That's probably something I should have noted as well. There's quite a few ports that the Docker Compose file exports. And so, if there is a port collision, the Firefly CLI should tell you which port it tried to grab and found something else listening on already. Okay, so it sounds like some folks are tracking along or are very close to getting a stack started up. So that's great. I'm sorry, Nick, go ahead here, go ahead. The team here is gonna, if you're on Mac and you've got a recent install of the Apple operating system, it may have enabled a system for sharing an algorithm. Yes, okay. Yeah, let me thank you for that reminder that was a while ago. I forgot about that. So in the, thanks, Apple, for this. In the latest version of Mac OS, there is a new feature that Apple added and it happens to listen on port 5000. If you wanted to say all that, I'll walk you through that right now. It is, it's an AirPlay receiver. And so I just go to system preferences, I go to sharing and there is a thing at the bottom here called AirPlay receiver. This will listen on the port that the Firefly Core wants to allocate to itself. So if you just uncheck this and then try to run FF start, that should solve that problem if you're running on the Mac and running into the port collision there. That was a good call out, Peter. And thank you, I had forgotten about that. Okay, let's go back to our guide here. All right, so we've run, we have ran a start workshop. Now we're gonna shift gears and look at our contracts that we're gonna deploy. So what have we done so far? We've set up a Firefly development environment on our machine. We have a blockchain node running. We haven't done anything with it. We will go look at it in a little bit but we're gonna kind of shift gears now and then go look at hard hat, which is a different tool to, this is a tool that Ethereum developers are probably familiar with. And so we're gonna look at, how do we take an existing workflow that people are probably familiar with or at least some of the concepts they're familiar with and use that with Firefly. So Firefly has a, it's concept of a tokens connector and a tokens connector is a bridge, I'm sorry, it's not a bridge. It's a component that sits in between the Firefly core and the blockchain node itself and it is written in such a way that it knows about what type of contract that it's supposed to be working with. So in the Firefly hyper ledger GitHub repos, there are two different reference implementations of what a token connector might look like. If you are building your own smart contract, your own token implementation and you wanna run on Firefly, we highly recommend you should build a token connector that is knowledgeable about your specific contract but there is a reference implementation provided for ERC 20 and 721, which we're gonna be looking at today. So we're gonna clone that GitHub repo, hop back over to my terminal. I'm gonna go ahead and just open a new tab in my terminal here. And then I'm going to go to my code directory and I have a workshop directory in there. There's nothing in here right now. So I'm just gonna clone this repo here. You can clone it anywhere you want on your computer. And then if we look at the guide again, it says CD into that directory. And then inside there, there's a Solidity directory. So we just cloned the source for the whole token connector. We're not gonna run the whole token connector because we're actually already running it in our Docker environment. But what we need is the Solidity files that are in there. So if we look at this directory, it has some files in it. If we look at the contracts directory, there are some Solidity files in there. So I'm just gonna actually open up my IDE real quick and show you what is in there. That's probably a little too big. There we go. We look at contracts. We see there's, this is the contract that we're gonna deploy. It's ERC-20 with data. This extends the open Zeppelin ERC-20 contract. I haven't installed dependencies which is why we're getting all the red underlines here. We'll solve that in just a minute. And so yeah, so this extends open Zeppelin and implements ERC-20. And Firefly has this concept of being able to associate data with transfer. So that's what ERC-20 with data is all about. There's also a contract provider for 721. We don't have time to look at that as well today. We'd love to do a separate talk on NFTs, but you should be able to take everything that we have talked about here today. And with some minor changes, also you could do the same with 721 if you wanted to, but we're gonna focus on ERC-20 today. Okay. So I'm gonna hop back over to my terminal and actually I'm gonna go back to the guide and it says now run NPM install. So that's what we're gonna do next. So again, I just cloned the repo, I seeded into it. I'm in the Solidity directory and I'm an NPM install. This will install HartHat. It will install the open Zeppelin contract dependencies and everything that we need to be able to compile our contract. We'll give that a second. Okay, great. So we've got our dependencies installed. We'll pause to kind of make sure people are keeping up here. Any questions or comments that I can address while we're kind of letting people get the repo set up, get things installed? Another sort of public announcement if you haven't seen it on Discord. If you have permissions error, trying to get clone, make sure you're using the HTTP S link to clone the repo, not the SSH link. Apologies for that. I would have thought SSH should have worked for everyone. So that would look like get clone and instead of instead of get at github.com do HTTPS colon slash slash github.com slash hyperledger firefly. And I can just drop this in chat as well. So everyone has this here. It should be HTTPS. Okay, hopefully everyone can clone that repo, run npm install and get the dependencies installed. Again, we're working in the Solidity directory inside there. There's a question, is it possible to use Rust rather than Solidity on the dev side? As long as you can compile and deploy an Ethereum smart contract onto the chain, you're welcome to use whatever tooling chain or language you would like. The end goal here is to get a smart contract on chain. So that's hard hat and Solidity are the tools of choice here for today. But as long as you can get an Ethereum contract deployed to the blockchain node, you're running locally, you're welcome to use whatever tooling you want. Use Truffle or any other tools that are common Ethereum smart contract development tools. Okay, now we're gonna run it. Sorry, we're gonna compile and deploy it. So if we look in, just so you can see what's going on here, inside the Solidity directory, there is a script directory and there's a deploy script here. This is, we're gonna run this script and this will compile and deploy our smart contract and it will print out the addresses that it has deployed the contracts to at the end. And I see someone has raised their hand. Yeah, go ahead. Hi, does the Firefly Supernode runs the Ethereum node that I'm gonna deploy to or Ethereum-like node? Yes, it does. Yeah, so great question. And I can just show you real quick what, after we ran our stack, I could run Docker PS and we can see all the things that we have running here. So sorry, some of my zoom windows are in the way a little bit, but we've got, we have three Firefly cores, we have three token connectors, three blockchain connectors. And then right here, this is our Go Ethereum blockchain node that's running on our machine. And so internally it's listening on 8545, yeah. So I'm going to talk directly to that node to deploy and work on my contract or I'm going to use another interface of Firefly. Yeah, so we're gonna have, so great question. And let me show you what's gonna go on here behind the scenes. When we run this deploy script, it's going to use the, there's a hard hat config.ts. And this is an important detail, so great question. Thank you. I've already put in this repo a configuration to use the Firefly network that's running locally on your machine. And so here we've configured a network called Firefly and we've told it this is the URL of the blockchain node and this is what hard hat we'll talk to when it goes to deploy this contract. So hopefully that clarifies there. Yes, thank you. Yep, yep. Did I see someone else with her hand up? That had a question? Okay, maybe not. Okay, so yeah, it's a great question about, how does the deployment work? So we have a blockchain node running here, that's what we're gonna deploy to and this script is what's actually gonna do it. So to run this, we can just go back to our guide and run npx hard hat, run scripts deploy.ts. And so we'll make sure we do that in the Solidity directory. Just run that command. This will compile our contract. We may see a couple of warnings, that's okay. I am gonna go look at those later though and see if we can clean that up. So that compiled it and it deployed it. And so we can see here at the output, we can see our ERC 20 contract was deployed to this Ethereum address because your ERC 721 contract was deployed to this Ethereum address. So this is great. We have a contract on chain and now we can start to use this with Firefly. I'm gonna take another moment to pause here because we're about to shift gears now and go start looking at actually using Firefly with this contract. So I wanna make sure that, if people are following along and trying to keep up, we get at least to this point where we have the contract on chain because that's kind of a big milestone in the workshop is making sure we get our contract actually deployed. So I'll just kind of pause for a minute. Folks have a couple of questions. I can take a minute to answer those as we go here. Somebody asked for the link to the gist. Yep. Yeah, sorry. Let me send that to everyone here, just in case. Okay. Yes. Missed off I had, you got your hand up. Go ahead. So the connector, the coin connector, what does that, what's the truth here? Does it like connect Ethereum contract? Yeah, I'm glad that, yes. Yeah, I'm glad you asked. We have not actually used the token connector yet, but that's gonna be one of the really cool parts of the workshop here in just a few minutes. Okay, thank you. Okay, yes, we are recording this and the recording will be made available afterward as well. All right, so I'm conscious of time here and I wanna make sure that we get to look at some of these really cool features of Firefly. So we're gonna jump into the Firefly sandbox now. So there is a guide in the docs on, this is kind of in step three of the getting started experience in Firefly, which is using the sandbox. There's a video walkthrough from the webinar last week, a little bit of a description of what the sandbox is. Again, it's an end user, it's written as an end user application. So it sits outside the super node. It uses Firefly's API and it's kind of broken up into these three columns here. I'm gonna actually open it up. There is a link here right in the docs that should open up the UI for the first member. I'm gonna try to keep things straight by using these color themed Chrome browsers. Remember when I set up my network, I named them red, green and blue. And so I'm gonna open up the sandbox for the first node here. So this is what the sandbox looks like. It is kind of broken up into three columns. And on the left here, we have a form that we can fill out that will prepare requests for us in the middle. We have an example of some server code that will, you can think of this as like, if I'm building a backend application that is designed to use Firefly, here's an example of some code that I can go take and put right in my application. This uses the Firefly SDK. This is Node.js TypeScript code here using our Node.js SDK. There is SDK support coming for more languages in the future but right now we've got Node.js. And so that's what this Firefly variable is here. It represents an imported Node.js SDK. We're gonna start on the contracts panel. So there's three different panels. You're messaging tokens and contracts. We're gonna start with our custom contract that we deployed. And so you can imagine a use case where, I'm building an app that has an ERC-20 token economy built into it, but it's a custom contract. It has extra features. It has things that are not in the standard ERC-20 interface. And I wanna use Firefly to interact with those features. So that's what we're gonna show first. So just a couple of concepts here that I wanna go over. So we have in Firefly a thing called a contract interface. So first of all, there's some helpful hints here on how to deploy a contract. We've already done that because we walked through that with hard hat. I wanna just take a brief moment and talk about contract interfaces and contract APIs because these are some building blocks of really powerful features inside Firefly. So in the Ethereum world, we have Ethereum ABI format which describes the inputs and the outputs and events and all the type information in a smart contract and all the functions that it has. And this is a great way to just inform a system about the shape of a smart contract. Firefly is multi-chain, multi-protocol. And so it works with Ethereum but it also works with fabric and it could also be extended to work with other types of blockchains. So we wanted a way to be able to describe a smart contract for any blockchain. So that's what the Firefly interface format is all about. It is a way to describe a contract in a blockchain agnostic format yet still encapsulating blockchain specific important information like the type. For instance, for Ethereum, you'll see inside an FFI it still embeds the specific EVM type that a variable will be treated as in the EVM. And so this also has the advantage of now we have a way to define an interface that can describe, for instance, a fabric chain code and it doesn't matter what language the particular chain code is implemented in. We have a way that we can talk about smart contracts in a way that's blockchain agnostic. So what we're gonna do is we're gonna tell Firefly about the shape of our ERC-20 contract that we've just deployed. So Firefly doesn't know anything about it right now. It's just on the blockchain, but Firefly doesn't know where it is or anything about it. Because we're using an Ethereum contract and we already have an ABI, Firefly also has a convenience function to convert that Ethereum ABI into an FFI or a Firefly interface. And that saves me as a developer a bunch of time typing out a bunch of handcrafted JSON which is probably going to be error prone. So what we're gonna do is we're gonna switch this toggle to ABI JSON and we're gonna upload that we're gonna just paste in the ABI here from our contract. So you can find that and if I go back over to my IDE, I'll tell you where you can find it and then it's also in the gist. So you don't have to go digging for it, but just for your knowledge, it's going to be under artifacts, it's gonna be in build info and it's gonna be in this big long ugly JSON document. It's in here, I promise. There's a bunch of other stuff in here though. So to save time from sorting through that, I've actually already copied that out and I have put it in the guide here. Since we're convenience, I've also included a copy here. So you can, you know, select this whole thing. And again, this is just the Ethereum ABI for that contract that we have compiled. And we're gonna copy this. Sorry, I'm gonna go back to my red browser for my red member here. And I'm just gonna paste this whole thing into this box here. Okay, I need to give it a name and a version. So within Firefly, just about everything is encapsulated in a namespace. And so a namespace is just a way to group data and messages and definitions of things. So within a namespace, the name and the version of a contract interface needs to be unique because that is going to refer to a specific smart contract or a specific version of a smart contract. So I'll just call it ERC-20 with data. You can name it whatever you want. There are some conventions that it needs to conform to but you don't have to name it the same thing that I am here as well. And I'm just gonna say that this is version 1.0. Now I'm gonna go over here and on the server code, I'm gonna hit run. So this is what I'm basically doing is I'm telling that the sandbox backend server make a request to Firefly's API to broadcast this contract definition. And what do I mean by broadcast? Well, so a variety of things just happened there. We see that there was a transaction that was submitted. So actually, sorry, first immediately we got a 202 accepted and then we got an ID back. That's a message ID that we can look up in Firefly to see what happened with that message later and we can see what the results of that request was. So Firefly uses an asynchronous programming model. So when you make a request, oftentimes you get an ID back and you can use that ID to look it up later. You can also set up a WebSocket listener to listen for events. If you don't wanna, and that's actually the encouraged model. So rather than polling for status, your application can receive updated status in real time. Okay, so over here on the right side, the sandbox does have a WebSocket setup and it's listening for events coming from Firefly. And we can see there was a transaction that was submitted. We received a blockchain event. There was a contract interface that was confirmed and the message that was used to broadcast that was confirmed. So what happened there under the covers? Let's go to answer that question. Let's go take a look at the Firefly Explorer and see what happened in Firefly now real quick. All right, so I'm just gonna open a new tab. This is, if you're curious how I got here, if you go back and look at where you started up your Firefly stack, there were some URLs that got printed out here. And so I'm just looking at web UI for member zero. And this is the link right here that I've just opened in my red browser. So this is the Firefly Explorer. This is kind of a view into the system, both my node and my nodes perspective of the network. So we can see a network map. We can see our red, blue and green members here and each of their nodes. We can see some information about my node that was all the plugins that I'm currently using. And we can see there's a little bit of activity here now. So there was a batch pin. There was a message confirmed, contract interface confirmed. And so what is a batch pin? You might be wondering, well, Firefly will take, if there's a bunch of requests coming in all at once, it will batch them together for efficiency, it will hash them, and then it will pin data to the blockchain, hence the name batch pin. And so what's happened here is when we broadcasted this contract interface, it was sent to, there was a message that was sent to all the other members. So we can actually go look at the, let's go look at the green node here as well and open up its Firefly Explorer. We can see that it has some of the same things. The transaction wasn't submitted from this node, but we see we have the same events over here, contract interface confirmed, message confirmed, blockchain event received. So what happened is when I broadcasted that, it Firefly took the payload of that JSON document, it hashed the payload, it pinned the hash of that to the blockchain and it put the actual JSON payload on IPFS. And then all of the other members are listening for blockchain events that are happening on the Firefly batch pin contract. They all saw the event, oh, hey, something was pinned to the blockchain. What is that? Let me go get the data payload that's associated with this. Oh, it's a contract interface. Great, let me store that in my database now. Now I'm aware of this contract interface that was just declared. So if we go to any of the members now, we should be able to look at the blockchain section here in the dashboard. And we see there was a batch pin event, but we can also go here and we can look at interfaces and we see that there is this interface that's been defined here. That's cool, not very useful yet. We'll get to where it's gonna be really useful in just a second. I just kind of want them to describe something, kind of what's going on behind the scenes when we're doing all these things. Okay, let's go back to our red members, Sandbox here. And now what we wanna do is we wanna actually use this thing. So right now we've just told Firefly about the shape of it and that's it. And so next I'm gonna go to register a contract API. So what this is gonna do is it's gonna build an HTTP API and it's going to build a Swagger UI for us to work with all the functions on here. I'm also conscious of the time. I realized that I wanna leave time for discussion at the end and that we are rapidly running out of time. So I'm gonna try to speed things up a little bit. I hope you can follow along. If you get lost in this part, this will all be recorded. So hopefully you can kind of go back and walk through some of these things with me after the fact. But there's a few more things that I wanna show here. Okay, so we're gonna register a contract API. I need to give it a name. This name is going to be part of the URL path. So it needs to be URL safe. And so I'm just gonna call it ERC 20 and we need to give it an address for this. We're gonna hop back over to where we used hard hat. And remember I told you to save these addresses. We're gonna copy the address for the ERC 20 contract and we're just gonna paste that into this box right here. So this is gonna tell Firefly, hey, that contract interface that I broadcasted earlier, I want you to generate a REST API for me. And when somebody calls HTTP methods on it, I want you to send blockchain requests to this address here. So we're gonna broadcast that. This also gets broadcasted and pinned to the blockchain the same way as our interface did. Now that I've done that, I can go here, I can hit refresh and then I can see that I've created a contract API. So let's go take a look at that now. We'll hit this little pop out button. And here is a Swagger UI that has been dynamically generated by Firefly that gives us a listing of all the endpoints that we can now use to interact with our contract. So let's do something with our contract now. This is kind of the whole point of everything that we've been building up to here. So let's mint some tokens first. We don't have any right now. So we'll mint. So in this case, we're gonna call the invoke mint with data function or endpoint rather. Here it is. I'm gonna hit try it out. I need to fill out a couple of things. I need to first tell it how many. Let's just do, we'll do a hundred. I can give it some data. I don't actually need to give it any data at the moment. So I'm gonna do, I'm just gonna put 0x00 here. And then I need to tell it who to send it to. I'm gonna mint it to myself. And then we'll do some transfers to the other members here in a second. To find out, what's the red nodes Ethereum address? Cause that's an important thing to know here. I'm gonna go back to the Firefly Explorer, look under network and organizations. And I can see there's one labeled your org here. Okay, so this is me. I'm gonna click here. There is a verifiers section here and that has my Ethereum address. I'm just gonna hit this button to copy it. Then I'm gonna go back to my Swagger UI and paste that here. Okay, again, if you're looking to figure out where did I get that? I went back to the Firefly Explorer. I went network organizations and then I clicked on an org here. Okay, so that should be enough to mint 100 tokens. I'm gonna run that. We get a 202 back. It's great. Let's go query the smart contract and see, do we actually have a balance now? And so just to do that, we're gonna scroll down to the query endpoint and we're gonna check balance of and I'm just gonna paste my Ethereum address here, run that and we get 100. So that's cool. Let's check one of the other members and see if they have any balance just for the sake of the example. We'll copy the green members address. We'll paste it here. We would expect none and indeed we have none. Okay, so only the red member has a balance right now. Let's do a transfer real quick. So I'm gonna go to, let's see, I'm gonna just scroll back up here. I'll collapse this just to save some space. Okay, invoke transfers, what we wanna do. I'll hit try it out. Let's send the, we'll send the green member, send them 10 and I'm gonna paste the green members address there, run, we got a 202. So that's, the request was accepted. We don't know that it necessarily went through but we can go back down here and then check their balance again. So it was previously zero or I'm just gonna execute the same one and then now we've got 10. Okay, great. So we've done a mint, we've done a transfer. We've done that through Firefly's custom smart contract support, which is really cool. So, we're working with an ERC 20 contract here but maybe again, maybe your contract has custom functions on it that you wanna be able to use through Firefly as well or maybe you're working with an entirely different type of contract that's not an ERC or something like that. The Firefly is, it's approachable. It has really easy to use APIs but it also is powerful and gives you full control of using any smart contract with it. But this was still quite a few steps and there's still, if I want to build an app that has a whole token economy there's still a bunch of things that I need to actually build a robust app. For example, I'll just throw one of them out there. What if I wanna see the whole transaction history of everything that's happened on this coin or what are the wallets that have been interacting with it or what are people's current balances? So let's take a look at the Firefly Explorer real quick. There is a token section here and it has a dashboard and you'll notice there's nothing in here. We have, we've been working with our ERC-20 contract through the custom contract support in Firefly but at this point there was a question that was asked earlier. What is the role of the token connector? And I haven't answered that question yet and I'm about to now. This is where the token connector comes into play. We haven't actually told Firefly to go index the history of this contract, listen for events on it or any of that stuff. Any of the kind of all the plumbing and transactional history and things that you need to actually build an enterprise app with a token economy. So that's what we're gonna do now. So that's kind of what this middle column here is about in the sandbox is using Firefly's rich first-class token support and tokens APIs that are built in. So first of all, I'm gonna create a token pool. I'm gonna call it FFC for Firefly Coin the symbol is FFC. That's what is also in the contract. If you specify a symbol here, it needs to match what's in the contract and I'm gonna get the contract address. So again, to get that, I'm just gonna go back to my terminal and copy from where we deployed this from hard hat. And so if we look in the Firefly Explorer our tokens dashboard is looking pretty sad right now. There's nothing there. But as soon as I run this, we're gonna see a variety of things happen. So we created a token pool and all of a sudden we told Firefly about the address of the contract. And this now tells Firefly to start talking to its tokens connector, which is aware of how an ERC-20 works. So between the combination of Firefly and the token connector and the blockchain it's going to build the transaction history and store that in our database. It's gonna populate the Firefly Explorer and it's gonna give us a much richer view of what's going on with our token contract. So now let's hop back over to the Explorer. We'll just reload it. And all of a sudden we start to see this dashboard come alive. We've got some token transfers that have happened. We have a history of a mint and a transfer. We have a, we can see our account balances here of, this is the original hundred that we minted and then we transferred 10 of it to the other member and we can see our token pool here. We can click on to any of these things and kind of drill down into them to get more details about them. So we can see this is using the ERC-20, ERC-721 connector. It's a fungible pool. It has 18 decimal places and we can see the contract address and all this good stuff. And so all of this just became available to us because we created this token pool and told the tokens connector that Firefly is using about this contract and it has built kind of this rich dashboard for us to use here now. This also opens up the Firefly first-class minting, transferring and burning APIs as well. So we've already minted some. We can see our balance here is 90 but let's do some transfers from here now. We can do a transfer right in the sandbox. We don't have to go into the swagger. We, the cool thing is we don't even have to actually go look up Ethereum addresses because the sandbox is now, it's aware of all of these things. So I believe we transferred some to green before. I'm gonna transfer some to blue now. Let's send another 10 over to blue and we'll hit run. Okay, and let's go take a look at the blue members dashboard. Now we haven't looked at that one. So we're gonna open up Firefly Explorer on this one and let's take a look at the token section here. And now we can see, yep, our balances are being updated. The first member has 80 and both of the other members have 10 now. We can see both transfers here. And again, if we were transferring with data, we could also look up the actual, the blockchain event and see what that data was that was attached to the transfer as well. So there's a lot of information you can kind of dig into here. And then let's, you know, for the sake of the completeness of the demo, let's burn some tokens too. Let's burn 10. I must have wanted to show this because I just think the burn icon is the coolest one in the dashboard here. I refresh, there's our burn icon. It's just straight fire. Okay, and then let's just make sure our accounts have updated. Yep, so we had 80 and then we burned 10. So we've got 70 because we've transferred 10 to each member and then we burned 10. So our account balances are continuing to update there. So hopefully you've been able to kind of follow the journey here. If not actually doing it, but you've been able to follow along and it's made sense of, you know, we've started with our own ERC-20 contract that we compiled, we deployed it to the chain. We told Firefly about it. We accessed it directly with our Swagger API. And then we used Firefly's rich token support to start indexing the complete history of the token contract. Even before we made Firefly really aware of the fact that this was an ERC-20 contract, it was able to go build that history even back before we told it about that. And so there's one other just quick, I'll just real quick walk you through the last tab on the sandbox and then we'll kind of wrap things up and then leave some time for some discussion and Q&A at the end here. But I also just wanted to briefly touch on the messaging tab, because this is kind of like the, we've talked a little bit about messaging when we talked about broadcasting, but this is the other foundational building block in Firefly, a building enterprise web three apps is sometimes I just need to get a piece of data from one organization to another. I want to use blockchain to do that. And sometimes I need the data itself to be public. Sometimes I need it to be private. Firefly supports a variety of different combinations there. So in the sandbox, if I just hit expand, send a broadcast message and sure we'll just send this is a message. We'll wait for the event to go through. It's great. To see messages, I can look in the off chain tab here and look under messages. I can see there was a broadcast message and here's the data that was associated with that. The data could be, in this case, I just sent a string. It could be a JSON object. It could be a file. It could be a binary attachment that was referenced by ID. And I'll demonstrate that in just a second as well. Just for the sake of the demonstration I'll just pop over to one of the other members. We'll look at their, sorry, we'll go to off chain, look at messages. We should be able to see that same exact, yep, this is a message. Here we go. So that went to everyone. We can look at the blue member as well. Look at their messages. Okay, this is a message. Great. Let's do a slightly different scenario here. Let's send a private message. In this case, as a hypothetical example, I have a file that I need to send from one member to another. And so I'm going to go to the file attachment toggle here. I'm going to choose a file on my desktop. I have a really cool picture. It's the Firefly logo. It's a PNG, it's not too big. It's 20K, but 20K is still a lot to store on chain. So what we're going to do is this file will actually get stored in IPFS and then we're going to send a, basically it will send the, sorry, this is a private message. So it is not stored in IPFS. This uses Firefly's data exchange. I'm sorry for the, I misspoke there briefly. This will use Firefly's data exchange to directly transfer this file from one member to another. And it will still hash and pin the file, the payload of it to the blockchain so that I, as the red member, can attest that, yes, I actually had this data and I can prove that I had this data on this date. So we're going to send it from red to, we'll send it to blue and then I hit run. That will upload the file. It will send the private message. And so we should be able to go over to the, the blue members dashboard now and let's look at the data tab here. And here we can see, we received this data. It's about 20K and I can just click right here and I can download that thing. I can open it up and there's my image that I just sent. That's great. Just to prove that it was indeed a private transfer, let's go to the green member who should have been completely in the dark about the contents of that message that was sent. And we will jump over to the data tab here, sorry. And we can see that the last thing that it has was, this is a message. It does not have the private data that was sent from the red member to the blue member. Okay. So hopefully you get an idea of the things that you can do in the sandbox, kind of these, the three, what I would describe is that the three pillars of Firefly features, messaging, tokens and smart contracts. And there's a lot that you can do with them. They give you the very powerful building blocks to build enterprise grade web three applications. And hopefully this gives you enough of a starting point that, okay, I can go from using command line tooling and building my own contract. I know how to deploy it to a chain. I know how to use Firefly with that contract. I know how to do tokens transactions. And I know how to send messages now between applications. These are some of the building blocks that you need to build a web three app. So hopefully this has given you enough of a starting point that now you got the creative juices flowing and you're thinking of all the different things that can be built with these functionalities. Just real quick, would like to, but before we jump into open discussion at the end, I never liked to let a good opportunity go to waste to invite people to join in the Firefly community. This is an open source community. And it's in my opinion, a very open open source community. We would love for you to join us on Discord. If you're not already in there chatting in the channel for the workshop, please come over and join us. We'd love to continue the dialogue. Myself and a bunch of the other maintainers are in there on a daily basis, chatting with folks, answering questions about Firefly. And it is also a great place to give for us to receive feedback too of like, hey, I tried this thing and it didn't work. Oh, well, that's not expected. Let's take a look at that together. Also, the source, it's all open source. It's on GitHub, go check out the source. We would love if you have ideas of things that you want to build on Firefly or new plugins or feature enhancements, we would welcome contributions to the project. So come chat with us, come check out the source and we'll just love for more and more people to get involved in this project. Cause I think it's really exciting and I think it has a lot of potential. So thank you all for listening. I think at this point, we are going to kind of transition now into, Peter brought Hurst, one of the other maintainers on the project wanted to talk a little bit about kind of future roadmap and where is the project going from here? Because I'm sure a lot of people are really curious about that. And then we will open it up for just open discussion. After that, if people have questions, we can discuss whatever topics that people want to talk about. So I think we have about 24 minutes left. So I will go ahead and turn it over at this point to Peter, but thank you all very much for following along in the workshop today or really appreciate it. Thank you so much, Nico. I'm just going to start sharing my screen here. So before we go into roadmap, I'm just going to recap a little bit. I hope everyone's enjoyed getting your hands on Firefly, about how far through you got during the session today, the Discord is there. Keep going with us. Keep chatting with us. It will be great for you to make sure you get to the point that you've got that sandbox there. So the journey that we went through was use the CLI, which is a developer tool just to get it running on your laptop. It gets all the components running. It gets the blockchain running. It gets Firefly Core running. It gets all the connectors for tokens running. It's not a production deployment tool. Production deployment, how does that work? Kubernetes, Helm, DevOps tooling. We'd love to have that conversation on Discord, but that tool gets you that environment running on your laptop. You then have the Firefly Explorer UI, which is a lot like a block explorer will be for just the blockchain layer. This is the tool that lets you see what's going on in Firefly, all the layers. The blockchain and then all of the off-chain pipes and the tokens and everything as well. And then this absolutely fantastic tool, which you saw Niko demonstrating and hats off to the community members that built this over the last few weeks. It just lets you experiment with all the different things that Firefly can do. So I hope you get to the point where you've got all those tools there and you can really experiment. I just want to take a little bit of a step back at this point and kind of talk about what Firefly does today. Before we talk about roadmap, let's just talk about what you install and the B1 of Firefly, what have you got? So it's what we mean by a super mode. It's a way for you to build applications that are decentralized, web-free applications on top of a set of APIs. So those APIs are there for you as an application developer. APIs that allow you to connect to custom smart contracts that you've built and APIs that let you do kind of really quite complicated things like on-chain, off-chain data coordination, small casting data to everybody in the network that needs to be put on a system like IPFS. So it's shared with everybody. It doesn't fit on the blockchain. Sending data securely directly from one member to another member or to three different members, that's by the blockchain, but they can't go onto the blockchain because it's too sensitive or it needs to be deleted. So these flows, it's sort of data exchange patterns, multi-party business process flows, APIs that just do that as a pattern on top of those core-based capabilities and then digital assets. And we, anyone who's seen blockchain knows just how important those digital assets are to building use cases, whether it's uniqueness, these NFTs in an enterprise context, knowing that everybody's referring to the same thing in the world, those NFTs, or whether it's exchange of real value, digital settlement, exchange of value and a tokenized economy, APIs for that, including all of that coming that you need to build like the off-chain indexing, all built on sort of the core of Fireflies, the orchestration engine, kind of thinking about Fireflies doing for blockchain, what something like Kubernetes does for Docker, it sits a layer above and helps you orchestrate all of those things together. So that's what it is at its core is this orchestration engine. And in the middle of it is an event-driven programming model. I hope you find that that really comes through as you're using the sandbox, is everything in blockchain, whether you use Firefly or not, the only way to program in blockchain is through an event-driven model. So Firefly helps you with that. It makes it easier for your applications that you use things like WebSockets to try and make it easier to build. So it's a platform for building on. And if we just look at a more technical view, rather than a feature function view or sort of the last chart was the architecture. This is the architecture. And look at the components of it. It sits as a layer in partial generation presented by software we've called this middleware. It sits between the application and all of those core backend data systems. So whether that's public blockchain, I know there's questions about public blockchain, we're gonna talk for a minute about that, whether it's your own pluggable private blockchain, you know, whether it's hyperledger fabric which we didn't see today, but super simple to get started with just as easy as we have a theory in today. People like Jim Zhang, who's one of the TSE members is key contributor to the Firefly community. So, you know, you can choose your enterprise version of blockchain that we'll talk about sidechains as well, but all pluggable. So about these core sort of blockchain native technologies, but then also it sits on top of the sort of off chain data. Again, pluggable things like shared storage, okay, as we talked about. And then your own private data bus, because almost certainly if you're building for enterprise, there's gonna be data that's too private to go onto the blockchain itself. So it sits as this layer in between and it's a microservices architecture. So the reason why we're talking about how much memory do I need? Well, you first need Docker and you need to have all these containers running on your laptop because it's designed to be pluggable. And nowadays, pluggable means microservices. It means a Docker-wise Kubernetes native deployment model. So that's what it is, the way it's constructed. No detail or no time to talk about the detail of what all of these different components are in this session. And at its core, it has the database, a private database. And this is something that's really important. Firefly is stateful. It has your private data. It's designed to sit at the boundary between your domain and the blockchain where everybody else is participating as well. It's your view of the world. The private data that you may be exchanging with that network of participants and the blockchain data, all index in a fast off-chain database. So just wanting to make sure that everyone was on the page of what it is right now today. And let's talk about some of the roadmap items that we're working on immediately coming out of B1. A bunch of these are already started and in flights. There's always room for contribution, new contributors. So if you've got skills, you wanna bring to the project. Nikos, a great person to reach out to to talk about how to get involved. But all of these threads are ones that you can participate in but there's also other threads that you could work on as well. If you are interested in contributing. But key focus areas one is no surprise being an enterprise-focused technology and where enterprise adoption of blockchain's been for the last few years. Firefly evolved and actually many of the components have evolved over the last four years of production deployments on sidechains, on enterprise, private blockchains that are secured with a sort of hard boundary. You have to be permissioned in. You have to be able to join the club to have access to it. Technologies like hyperledger, fabricated hyperledger, best suit and even quarter. Nowadays the lines between whether a use case or whether it's a use case needs just a sidechain or just public is being blurred. It's really common to need a mix inside of your business, inside of your projects. So we're seeing the lines of separation between what used to be, obviously this is gonna be on the sidechain and what used to be, well obviously this is gonna be public. Those lines of blurring as more and more layer two and another sort of proliferation of public blockchains and permissioned public blockchains are happening, CK rollups and all these technologies that are meaning that those things are happening lots and lots more and as enterprises are thinking more about digital assets, business to consume use cases. So this is a big area but we've got a big focus on at the moment. There's another focus around additional sample applications that show things end to end. The sandbox is so fantastic for seeing what Firefly does or the different individual operations but what does an end to end web three use case look like? SDKs, there's a Node.js SDK, hats off to Andrew Richardson who led the development on that one but there's a goal to have SDKs rubber languages, Java, Spring Boot, et cetera to be for all the variety of application developments and platforms that people work in and then sort of slightly beyond that supporting talking to a lot of different blockchains from a single Firefly instance. Some of this is available today. You can actually connect token connectors to token economies and multiple blockchains today on Firefly but that core sort of bus where you're doing the custom smart contracts, et cetera, you're tied to one blockchains today. So that's a model that's gonna sort of evolve very quickly we think and then another area that's a big focus is if this is your gateway to the world and multiple blockchains and there's multiple people that your organization is connecting with and lots of other different blockchains, how do you manage those connections? Who am I connected to and what are those identities? That sort of outbound gateway security is another area. And then some more features sort of built in rather than just in the Kubernetes layer where they've been used for a lot of production deployments today, actual pluggable aqueous security and extensibility in the API as well. So that's that, I'm gonna just take one more minute before we just open for questions and I'm just gonna focus in on that public chain and I'm gonna give you a teaser of where that's going. So connects is inside of Firefly to date. We've had a connector for Ethereum called ETHConnect which is a very mature technology that's been involved over the last four years. We have a similar solid project there for Hyperledger Fabric and there's another project for CoreDAPS on CoreDAP which is you need to customize a little bit more to your CoreDAP. Those are really focused on chains that are worked really predictably. They are enterprise-grade features inside of them for streaming transactions to a predictable blockchain getting transactions there really quickly. But they expect those transactions to be really final very quickly. So once they're on the chain, you know that they're there. That's not the way most public blockchains work. Most public blockchains work. It takes a lot of time and effort and gas management and resubmission and maybe you're gonna need to increase the value that you've given to people to include your transaction in the block. Public blockchains work in a slightly different way. So we have this evolved architecture which has come along specifically for public blockchains. I'm not gonna go into detail here but come along to the community sessions which were on alternate Wednesdays to learn more about this. It's gonna do a deep dive on this in one of the upcoming Firefly community sessions. But here's the highlights. A new quite significant component, my service component inside of Firefly called the Blockchain Transaction Manager. This is responsible for nonce management now being pulled away from those connectors and it's responsible for things like having a policy engine that can talk for external gas station policy-based decisions on things like resubmission and look after your transactions for minutes until they make it onto the blockchain. And things like the event streaming which is traditionally the eConnect and FabConnect be all the way down in the connector to the particular blockchain and moving up into this blockchain transaction manager. So this becomes the heavy lifter. And then the blockchain specific API connectors and eConnect now has the first one of these there in the repo are really easy. You've got a new blockchain. I want to just add support for the way that it does some transaction submission the way it does encoding. I want to add that blockchain in building one of those connectors is now a very small job with this new architecture because you don't need to rebuild the heavy lifter. eConnect and FabConnect both have all of that stuff inside of that. So this is a really significant evolution of the architecture of the Firefly overall picture. And this means that plugging in to 10s you know, and personally we're saying hundreds of different blockchain ecosystems out there plugging your ecosystem into Firefly over the coming weeks and months is going to get much easier and easier. So I talked for a few more minutes tonight than I hope to that. Thanks for indulging me. I hope that was useful background and probably what we've done and what's happening next. Back to you Nick, I just wanted to do an open question session. Thank you, Peter. I appreciate the the recap and kind of the look ahead there. It's really exciting stuff. And as Peter said, you know, if this sounds exciting to you and you want to get involved in the discussion about the future of the project, the, you know, in addition to getting involved in chat and Discord are every other week. Community calls are a great place to have kind of the deeper discussion and dialogue with maintainers and other community members. All right. So at this point, we've got a few minutes left. I will open it up again. Please just, there's quite a few folks still on here, over a hundred people here and still, which is super exciting. So let's just try to raise your hand if you have a question or something you'd like to chat about. And I assume Westafa has their hand up. So you have the floor. About the connector, we built that using JavaScript, right? The connector that I showed today is built using TypeScript and Node.js. Yes. But there is, there's no restriction on what language that has to be built in. Okay. Then I don't visit this connector. Like it's being called using an API, using an HTTP API that is just an RPC or something. Exactly. Yeah. There's a rest API between the, between Firefly and the blockchain connector. Yep. And it's, and also I didn't get that you, this connector is specific to the, it can be specific to a blockchain or it can be specific to a contract on the blockchain. It can be both, right? I choose. It probably should be built because the token connector is, the idea is that the, you will probably, as you customize your smart contract, you probably want to customize the token connector that's working with a specific contract to be knowledgeable about the inner workings of that particular contract. Okay. So, my connector. Go ahead, Peter. Mr. Hi. Just wanting to be really clear, there's two types of connector that we've talked about today. Two completely separate ones. One is a blockchain connector. E-connect, Fab-connect, Corder-connect. Actually, they were written in Go, those connectors today, the example ones. And these connectors will talk to any smart contracts. And in the demo and the walkthrough, you actually saw Niko just teach Firefly about a new smart contract. And that could have been any smart contract in the world. As long as you can find his inspiration, you can talk to it, you can listen to the events, you can set the contract, actually. Then there's this separate connector that Niko was just talking about, which is written, the base ones, the examples, the SDK for writing these, is in TypeScript. You don't have to use TypeScript, but that's where the sample is. And these are tied to a particular contract standard. And here we have an API specific to tokens and Firefly understands things like what is a transfer? What is a mint? What is the burn? What is an approval? But you can then, inside of your connector, you can tie it to your particular token economy. Maybe you're doing a security token with an ERC 1400 standards, and you need to sort of customize to that. That's why you might actually need a connector for that as well. I hope that just extra bit of information was okay there. I know you had a bit more to your question, so I'll... Yes, actually, but I'm still a little curious about the point that are there like specific set of ERCs, for example, that can have those contract specific connectors? Like contract specific connectors, contract can be anything, right? So Firefly can work with any token contract, but the particular token connector in use should be designed to work with whatever specific token contract is deployed on chain. It has, for example, I should write an adapter for if I have an ERC 1155, for example. Exactly, and that's the repo that Peter's about to go to right now, so there's a different token connector for ERC 1155. Okay, so most of the contract specific connectors are focused on tokens. Token standards, token standards, okay. Yeah, and the reason is because for other contracts that aren't specific to tokens, they might be doing anything in the world, right? I've got a bidding system that, you know, like an on-chain version of an auction site, right? That's going to be very bespoke to the way that you've written that or a lending library for books or a supply chain use case or like 100 different things. So for those, you don't need a connector because Firefly will generate you an API just like that. You just point Firefly at your smart contract, but Firefly, at that point, it will allow you to invoke every method on your smart contract and to listen to as many as it has a connector for such network. As long as the blockchain technology is supported, yes. So if you're in an Ethereum-based blockchain technology, then chances are the support is there or very close. Even if it's public-made net, it's EVN-based, you're in a good place. It's factory-based, you're in a good place with the connectors that are there today. Some of the other ones are going to need extra connectors like a Solana connector or these sorts of things, but those are actually going to need a more blockchain connector. I mean, the existing members of the community are expected to be building some of those and we expect as the community grows, those to be contributed by those, some of those blockchain technologies themselves. And you can think of it this way, Firefly supports any smart contract incantations, but because tokens are such a useful contract in the programming model world, we decided to make it a first-class thing in Firefly's programming model, so specific token standards can be supported as a first-class thing. Oh yeah, the Firefly UI can understand specifically the workflow of different types of tokens. Yeah, that's it. Yeah, thank you guys. Quick question, David, do we have a hard stop at the bottom of the hour or I'm free for some amount of time after this. No, you have the room as long as you want. Okay, great. So I realize we're running out of time here on the official time on the calendar, but I'm happy if folks have more questions, I'm happy to take a few more here. And if folks want to take questions to Discord, we're also over there and we can continue dialoguing, hopefully even after today as well. But thanks, good question and thank you, Peter and Jim, for the detail on that last one. Anybody else have questions that they wanna cover while we're all together for today on the Zoom? Well, if not, I guess we can wrap up right on time then. Last call? If you have time and there's no other questions, I might as well hug the time. Sure, go ahead. So in my head, I have specific use case for Polkadot, so if I'm to write an adapter for, a connector for Polkadot, what I need is something that can talk to Polkadot blockchain, ask for deployed contracts, ask for the ABI-like thing of those contracts and convert it to a standard format read by the Firefly APIs, right? That's basically it. I think you've hit the nail on the head there. We'd love to continue this conversation. The Polkadot power chains ecosystem is high on the list. And there's a lot of active engineering just happening at the moment on this new connector architecture. So if you're literally looking to like start coding within the next five days, we should say because I think you'll find it's like there's components moving about a lot. But I think in about a week's time, there's sort of like instructions for like, what's the recipe for a new connector? In about a week, we should have that written down. And that will be a great place to start. Okay, thank you. Yeah, Mustafa, CK had a similar question, like what about supporting other layer one public chains? And I mentioned any of the EVM based or any chain that supports EVM and the JSON RPC will be a really good candidate for sort of the first wave of new connectors because we already got the awesome ETH Connect that does most of the EVM based interactions already. So a pair of chain on Polkadot, like Moonbeam for example, Evalon. Of course already EVM, so yeah. Yeah, great. But I was looking for others as well or a custom part chain maybe. Right, yeah, it's definitely possible but it will just slow it, it's a little bit more work but definitely custom power chain support is not a, would fit the firefly model. We thought about it along the way. So I'm sure there will be a way to fit it in. It will just need a little bit more because you'll have to think about, like you said, the modeling of what does the transaction look like? Because even if you get an idea, it gives you that for free. But we actually did that for Fabric, didn't we Jim? Yeah, so I think the fact that the architecture supported Fabric in Ethereum, which is quite different programming models and different consensus designs. It's a proof point that we can support all kinds of different blockchain layers on the cover. Well, I look forward to continuing this chat and I hope to see you on Discord over the coming days and weeks. All right, well, once again, thank you everyone for coming out today. This was a great session. I was just really excited to see the turnout and the participation. And I've had a chance to look over some of the chat going on in Discord and excited to continue the conversation with folks over there. Thank you very much for coming out and I hope you have a great rest of your day. Thank you all. David, do I need to do anything on my side to shut down the stream here? Niko, are you're done? Yep, we're wrapped up. Okay, I'll shut it down. Thanks everyone. Thank you, bye-bye.