 All right, welcome everyone. Thank you for coming out to today's webinar on Firefly 1.1. And today we're gonna talk about a lot of exciting new features in this feature release of Firefly. Hopefully you are familiar with Hyperledger Firefly, at least to some degree. I will spend just a couple of minutes talking about what it is, but not more than that because I really wanna dive into what are the new things in Firefly? So at Hyperledger Global Forum last month, we announced Firefly 1.1 and we had one slide on, here's what's new in 1.1. We did demo some of the things that are new, but I really wanted to spend some time to dive a little bit deeper and really just kind of unpack the new features and actually go hands-on and show the community how to actually use these new features, how to configure things and how to kind of go a couple layers deeper than what we've demoed in the past. So that's what we're gonna look at today. I'm gonna go ahead and share my screen and we're gonna go through some slides. The first part of this presentation will be going through these slides and the second part will be a hands-on kind of demo, walk through using and configuring some of the new features. So let's go ahead and jump right in. So like I said, hopefully you're familiar with Hyperledger Firefly, at least to some degree. If you're not familiar with it, we describe Firefly as a Web 3 super node for building enterprise blockchain applications. So what does that mean? It is a platform, so Firefly itself is not a blockchain. It is a platform that allows developers to build apps that are powered by blockchain and it provides an API and very developer-friendly features and patterns that developers are familiar with to help speed up building blockchain apps. So Firefly is middleware that sits between the actual DLT, the blockchain, at the lower layer and your application, your business logic at the top layer. It coordinates a whole bunch of different type of things, data flows, whether it's on-chain data or off-chain data, it handles token contracts, indexing transactions on the chain, keeping track of balances, performing transfers and a bunch of other stuff like this. So it provides a bunch of building blocks for building blockchain applications really quickly. And it's an open source platform. It is a standardized way of building blockchain apps. It's also very pluggable. So one of the things that we're gonna dive deep into is what are the new plugins and how do I configure them in 1.1? So as you'll notice as we go, just about everything in Firefly is a plugin and or a microservice. So there are a lot of different pieces of the architecture and we're gonna dive a little bit deeper into what some of those are today. So that's just, that's Firefly in a one or two minute nutshell here. So with no further ado, let's dive into what's new in 1.1. So this was the slide that we showed at Hyperledge Global Forum and we spent maybe 30 seconds on it. And I wanna just like take this slide and unpack each of these things here today. So the things that we're going to be talking about are gateway mode. We're gonna be talking about public blockchain support, specifically EVM support. We're gonna be talking a lot about namespaces and how to have multiple namespaces and what some of the use cases around those might be. And we're gonna be talking about the connector toolkit and we're gonna be talking about pluggable API security and Firefly's token capabilities as well. So this is kind of the high level of here's what's new. And now the next few slides are gonna unpack each one of these little boxes here on this slide. So I wanna start with the most exciting thing and kind of the high level thing. And this is not just one feature. This is like a bunch of new things that are in Firefly.1.1 all roll up to enable public blockchain support. So there's a bunch of different pieces within Firefly that allow you to now interact with public chains. And so we're gonna kind of drill down into each of those in just a little bit. But some of the highlights are there's a new transaction manager and a brand new EVM connector as well. So when Firefly 1.0 launched, we had ETH Connect and we had Fab Connect as the two blockchain connectors for Firefly. 1.1 brings a new connector for Ethereum based chains called EVM Connect. You could think of it as a new version or a completely rewritten ETH Connect. It doesn't like ETH Connect isn't necessarily going away but it is backward compatible with ETH Connect. So we still have production use cases using ETH Connect. So we plan to continue to maintain it. But EVM Connect has all of the features that matter out of ETH Connect and has a bunch of new features as well. And so we'll dive into what those do in a little bit. But so the transaction manager and EVM Connect and I'll unpack kind of how those two are related in a little bit as well as the new Firefly signer component which allows for signing of transactions and key management. These features combine to allow you to now interact with public chains as well. So I'm gonna be showing this in a little bit. It will probably make more sense like how all these things fit together as we go. So this is the big headline new feature though that we're super excited about. So along with that is what we call Web3 Gateway Support. And so we've always talked about Firefly as being a Web3 Gateway. And version 1.1 brings a bunch of new features that really enhance that capability. So the idea is that Firefly can be my company's access point to the entire Web3 world. Whether that is a public chain, whether it is a bunch of different DeFi apps on different chains or whether it's a private chain in a blockchain consortium network or something like that. Firefly can now do all of these use cases at the same time within the same Firefly node. It was not, so when Firefly launched it was possible to connect to either an Ethereum chain or a Fabric chain, but the same Firefly node was not capable in the original version of connecting to both of them in time. Now it can. So that's a huge new thing. And the way this works is through different namespaces within Firefly. And I'm gonna unpack how we use namespaces, how we configure them in just a little bit as well. So Firefly now has two different modes that a namespace can operate in. What we call multi-party mode, which is how Firefly prior to 1.1 has always worked in sort of a multi-party consortium. You have many different organizations that are all running a Firefly node and they're all talking to the same chain to perform business transactions together. And now there's also gateway mode. And gateway mode is more like if I am an enterprise and I just want a piece of software to connect to blockchains, that's gateway mode. And there's no other organizations necessarily involved in those transactions directly. They don't need to be... Nobody else needs to be running Firefly for me to run Firefly in gateway mode. So over here on this very high level sketch sort of have this idea of one Firefly node that it has two different namespaces configured. So my Firefly node could both be in a consortium namespace talking to a private blockchain and other organizations could have their Firefly nodes talking to the same chain. Meanwhile, my Firefly node could also be configured in another namespace to talk to a public chain and I could perform token transfers or exchange value on public blockchains that way as well. So really great new gateway enhanced support here. And really this is sort of the picture that we've had in our minds for what Firefly needs to become for a while. And this really rounds out the picture. So over here on the left we have... You could think of this as my enterprise and this dotted line is like the boundary between this is what my company runs and manages and this is the rest of the world out here. And so prior to Firefly and having a common platform to build blockchain apps on most of the solutions over here were custom one-off solutions. And there was no common framework no open source framework that fit this middleware that sits between the blockchain and my web three apps that I need to build and also integrates well with existing systems. And Firefly solves this need. Firefly can act as a web three gateway now for many different use cases. Like we said, whether that's a consortium whether that's a layer one or a layer two chain whether it's a some sort of exchange or a DeFi app Firefly can be the one-stop shop for connecting to all these different types of web three platforms. So moving on to, I wanna kind of... So those are kind of like the really high level features. I wanna kind of start going a little bit lower level a little bit deeper to talk about sort of how you enable these things in Firefly and the building blocks that are there to allow you to create these types of configurations. So in Firefly 1.0, there were lots of different types of plugins but you could only enable one plugin of each type at a single time. That's changed now and you can have many different plugins of a single type. So we'll actually go look at a config file here and I'm gonna walk you through it and I'm gonna actually gonna edit it and create some new plugins and new namespaces here in a little bit. But essentially you can think of, I can define an entire list of plugins that I want Firefly to set up and initialize and connect to whatever service it needs to connect to. And then separately, I can define a whole list of namespaces and then I can pick which of those plugins each namespace uses. So a namespace can have a blockchain connector, a shared storage connector, a data exchange component, et cetera, et cetera. Those plugins could be shared by multiple namespaces or they could be separate per namespace. Within one namespace, you cannot have multiple blockchain connectors. Within one namespace, you cannot have multiple databases. It's you pick one for each but you can have many namespaces within the node. So that's just kind of the mapping between all those things. So over here, we just have a little high level sketch of, you know, oftentimes it's helpful to, I think think of the question like, what use case does this enable? So one of the really pragmatic ones, which I'm actually gonna walk through in a little bit is if you have multiple teams that want to use a single Firefly node, I could set up a namespace for each team. Now those teams could be sharing some components such as the blockchain connector or the chain itself. They may have, we may want to completely separate the data between them. So they could be using different databases or they could be using the same one. They could also be using different authorization, which we're gonna get, that's another new feature that we're gonna get into in a little bit. And they could be using different signing keys, for instance. And so being able to create a separate namespace for each team kind of helps keep things organized. It also helps if you want to run different applications or just completely different use cases all on the same Firefly node. That's completely a thing you can do now. So lots of different use cases there are unlocked by just having a lot of flexibility in the mapping of plugins to namespaces. All right, so now we're getting really technical. We're not gonna quite go look at code yet, but we're talking about code here. So one of the really cool new things in Firefly 1.1 is the blockchain connector toolkit. And so if you go look in GitHub, there is a repo called Firefly Transaction Manager. And that's what it began life as. It maybe is not the best name for it anymore, but it's stuck so far because we haven't thought of a better name for it yet. But essentially what it is is a reusable code library. It's written in Go. And it has all of the logic that a blockchain connector needs. Minus the protocol specific code to talk to a specific blockchain. So you could think of it as, it's this reusable piece of code that has a bunch of the really hard problems of building a blockchain connector, things like gas cost estimation, managing nonces, handling event streams, knowing where it's at, reading a chain. And if it needs to catch up, if the chain has moved ahead of where it's at and it needs to catch up, or if you wanna listen to a certain type of event from a certain block number, knowing how far behind is that particular event listener? And what do I need to do to get this particular event stream caught up with the head of the chain? All of this stuff is written in Firefly Transaction Manager. And it can be used as a library. So if somebody wants to create, one of the goals here was to make it really easy for the community to create additional blockchain connectors. And so EVM Connect is sort of the first blockchain connector that uses the Firefly Transaction Manager or Blockchain Connector Toolkit to build out, sorry, could I just ask if you're not speaking, if you could go on mute, that'd be great. We're getting some noise from someone's mic there. So EVM Connect is the first Blockchain Connector to use the Blockchain Connector Toolkit but our hope is that there'll be many more. So if someone wants to sit down and create a new Blockchain Connector to connect Firefly to a completely different type of chain, not Ethereum based, the goal is that the Connector Toolkit has at least 80% of the code already there. And then it's just up to the developer to figure out, okay, the Toolkit provides this interface that I need to implement and I just need to write the bit of code that is the syntax for my particular chain, how do I query a range of blocks? Or for my particular chain, how do I submit a transaction and encode it in the right format that my Blockchain node is going to accept, that sort of thing. So here's another look at sort of a diagram of how all of this fits together. So at the top, we have Firefly Core. Firefly Core works with smart contract interfaces and token standards. If we go one layer below that, the thing that's running both of those is a Blockchain Connector API. And then so the thing that is backing the Blockchain Connector API is, oh, sorry, I'll unpack that for just a second. So what are the things you could do in the API? The API provides functions for submitting transactions, getting updates on transactions, querying them or subscribing to updates when transactions have new status. You can listen to events and it provides event delivery via a web socket as well. So that's sort of the API. And the thing that actually implements this API and is backing it, most of it, if we're looking at EVM connector as an example, most of it is the Blockchain Connector toolkit. Like we said, that's roughly 80% of the code. And so it has everything from transaction manager, nonce management, keeping track of confirmations for a particular transaction and event stream management all bundled up in this library. Firefly is a pluggable framework at every level, including the connector toolkit. So there are plug points for things that you might want to customize. And so for your particular enterprise use case or for your particular chain, you may want to, you may have a particular way that you wanna calculate the price of gas or you may have a particular way that you, a particular strategy around how to handle transaction resubmission. But if my transaction failed, but let me look at why did it fail? Was it, did it not provide enough gas? Was there a problem with the way I packed the transaction itself or was it a temporary network failure or all of these things? And the policy around what to do in certain failures is pluggable. So you could write a custom policy and if you need customization over that, there's a very basic policy that comes out of the box with the connector toolkit and it basically just will continue to retry to resubmit a transaction. So for instance, in setting up various demos and things oftentimes when I'm working with a public chain, I will forget to actually fund a certain account and I'll submit a transaction and it will fail. And oh, why did it fail? Oh, okay, I forgot to, I forgot to fund it. Well, meanwhile the transaction manager is sitting there going, okay, well, I'll just keep retrying this. It's a like, you know, conditions may change at some point, some day I may have enough money to do this transaction and it's sure enough as soon as I find the account the transaction goes through. So that's the basic policy that's out of the box. But if you need customization and control of that it's a fluggable thing that is totally something that can be customized. And then so, you know, over here off to the right like this, this tiny box in the corner is really like that's EVM connects. And it's basically just the implementation of all of this orange box here in the middle and with the syntax of like, well, how do I do this particular thing for an EVM chain? Which means how do I submit a transaction via Ethereum's JSON RPC HDD over HTTP interface? So that's the blockchain connector framework. Really excited about it. It's proved to, you know, just internally it has been very valuable for the team already. And I hope it is really valuable for the community as well as the community has ideas of new chains that we want to integrate Firefly to and providing a huge head start to be able to do that. I apologize for if the sirens are coming through my microphone. We're okay in this building, but I'm downtown here. So there's lots of stuff going on all the time around. But okay, so that's enough on the blockchain connector toolkit. We're not actually going to, it's a lot of code. So we're not gonna dive deeper into that. But a couple of other things I wanted to touch on before we go hands-on and actually use Firefly. Plugable API security. So this is a thing, this is, I would say, 1.1 is a start and it's a solid start in the right direction for API security within the Firefly ecosystem. So up until 1.1, the approach has been, yeah, obviously APIs need to be secured in production but probably having some sort of appliance that sits in front of Firefly's API that's handling your authorization scheme that you have, whether it's OAuth or some other authorization scheme, having some sort of other network appliance handle that. This is the start of building API security directly into Firefly. And I say it's a start because we know there's more work that needs to be done. It needs to be more granular. And that's something that's sort of on the roadmap for future enhancements. But like everything in Firefly, API security is a plug-in and API security can be enabled at several different layers. So you can enable it on the HTTP listener layer. You can also enable it in any other microservices within the Firefly architecture that are using the Firefly common HTTP listener, which is several of them. You can also enable it there as well. And you can also enable it in a specific namespace in Firefly Core. So I sort of talked about earlier and you could have two different teams that are using the same node and you wanna have two different authorization schemes. So that's something you could do. You could assign a namespace to each team and allow them to access their namespaces but not the other one. And like I said, everything in Firefly is a plug-in. So there's a basic OAuth plug-in that is there today. It comes out of the box. But obviously basic OAuth is, like I said, it's just a start. You're probably gonna want, you may want something else. And so you can write additional plugins to have custom authorizers within Firefly. So that is it in terms of slides. And then we're gonna go hands on here in just a minute. But I think what we'll do is we'll pause for just a few minutes and I will ask if there are any questions on anything that I can clarify that we've talked about so far. I'll open it up to general Firefly questions if we have time at the end, but we'll just pause here for a few minutes on any questions on the material that we've covered so far before we kind of transition and go hands on and actually try some things. I'm just pulling up the chat here to see. I hadn't headed up on my screen here. Let's see, Shane asked, why is it called a namespace? It's a good question. A namespace is I think a fairly common term in the industry to just, when you want to group something within a certain context, we just decided to call that a namespace. And so there's a space and it's all of that stuff that's in that space goes together. Our namespace is strictly designed for teams. Nope, so you could have one team that uses multiple namespaces. You could have a namespace per team. That was just one example that I threw out there of how they can be used. Other use cases for using multiple namespaces might be if you're building an app that needs to talk to multiple blockchains, you would need a namespace to talk to each chain because you're gonna be using a different blockchain connector and maybe other different sets of plugins as well. But you could build one application that has the ability to talk to both namespaces. It's essentially just a change in the URI of the API calls that you're making. And you could build one app that talks to multiple blockchains using multiple namespaces. Another use case might be, maybe you have a multi-tenant situation where you're actually running different applications and you wanna run them all from the same Firefly node but keep their data separate. You could do that. Another use case for namespaces is if you wanna build some sort of monitoring tool that actually runs transactions but you don't wanna pollute the data set of the real live application. You could have your test traffic run in a test namespace and it makes it easy to just completely separate that data from the data of the actual live application. Yeah, some other great questions here. Can multi-party mode and gateway mode run concurrently? Yes, they can. Again, it's bound to a namespace though. So a particular namespace is either a multi-party namespace or it's a gateway namespace but Firefly can use both of them at the same time in separate namespaces. Does the use of multiple namespaces make the data load heavier? Nope, shouldn't. I guess maybe if you're using different databases that might have some implications but it really shouldn't make the data load any heavier necessarily. Does Firefly support permission blockchain? Absolutely. So that's, Firefly started the very first use case that we tackled in the Firefly project was using private permission chains. And so I'm not spending a ton of time talking about that today because in the world of Firefly that's a bit of old news now. But yes, absolutely. That's where Firefly started was with private permission chains in consortiums of your sort of blockchain network consortiums of organizations and public permissionless chains is something that is brand new which is why that's why we're talking about it more today because we're just sort of highlighting the new features in 1.1, great questions. Anything else before we go hands on here? Does the namespace part of the data out of the public ledger? So yes, so I think I understand the question here and please correct me if I'm misunderstanding it but I think the question is asking does the actual data that I'm sending, does it end up on a public chain? And so if you're familiar with Firefly's concept of messaging and hashing and pinning that the data payload does not actually go on chain. So if I send a message or I want to share a piece of data with some other party what my Firefly node does is it hashes that piece of data and the hash of the data goes on the chain and then the actual data payload itself which could be very large. I mean, we could be a large document, could be a video file, probably not suitable to put on a blockchain that's transferred off chain. Typically that's transferred using IPFS or if it's private data, a direct peer-to-peer data exchange connector as well. Does API security assured in transactions on the blockchain level? Okay, so this is I think sort of getting at where where some of the improvements still need to be in sort of future roadmap items for Firefly's API security. And that's sort of defining capabilities within Firefly at a more granular level. And so things like having separate users that are able to read versus write and separate users that may be able to query the database but not perform blockchain transactions. Those are areas that we still need to define the different capabilities that can be carried out by Firefly and then map that to different forms of authorization. So more work to be done there but we're making great progress in that direction. Okay, great. So we've got 30 minutes left. I do wanna spend some time actually going hands-on and walking through like how do I set this stuff up? If we have time, happy to come back to Q&A and open it up to more general Q&A at the end but let's do some hands-on stuff now. So what I wanna walk you through is I was trying to think of something that I could do that basically hits all the new features. So what I'm gonna do is I'm gonna, I've actually done a little bit of this ahead of time just to save time. So you don't have to sit here watching my machine spin up a bunch of services and configure a bunch of things but we're gonna start a Firefly stack in gateway mode. We're gonna connect it to a public test net. We're gonna configure multiple namespaces. So I'm gonna walk you through this use case this hypothetical use case of like I have multiple teams that want to access the same Firefly node. And I also want to enable basic auth on each of those namespaces and use a different signing key on each namespace. I forgot to put that as a bullet point on the slide but so those are the things I'm gonna walk you through. So what I've done over here is I have gone ahead and I've set up a Firefly stack and I'm running it on my machine here. So I'll just kind of, I'll talk you through the things that I've done ahead of time so that you could track with me. So I basically went, oh, it says my screen sharing is paused. Sorry, hold on just a second. Okay, I think screen sharing should be good to go now. If you are unable to see my screen, please don't hesitate to speak up. Okay, great. I've got confirmations in the chat that screen sharing looks good. Okay, sorry about that. So what I've done is I basically just, I've gone through one of the new tutorials in the doc site and this tutorial is up on the doc site today. You can go take a look at it. And I've set up a stack to connect to a polygon test net. So this walks you through the different command line flags that you need to use to connect to it. So I'll just talk through real quick what I've done here. So I've called my stack webinar and then I've connected it to, I've set multi-party false. So multi-party equals false. This will tell the Firefly command line interface to generate the appropriate configuration to run Firefly in Gateway mode. So we're not creating a bunch of different members all talking to the same chain. We're just creating one Firefly node and we're gonna connect to a blockchain and we're not going to enable all them. We're not gonna configure the default namespace to use multi-party mode. It's an Ethereum chain. I wanna use EVM connect because I'm talking to a public chain. In this case, I'm gonna connect to a remote RPC node and then in my command that I ran ahead of time, I put in a remote node URL here for a blockchain node that's running on the polygon Mumbai test net and the chain ID for that particular chain is 80,001. And then I have an EVM connect config file that I passed in which there's some instructions on how to create that. And that just says that for this particular chain, I want four confirmations before I consider a transaction to be final. So on a private permission chain, you don't have to worry about this necessarily if you're using proof of authority or something like that. On a public permissionless chain though, just because one particular blockchain node says that yep, your transaction is in a block. Doesn't mean that all of the other nodes in the network are going to agree. In fact, several minutes later, you may actually get a new block that says up, sorry, actually that block that we told you about earlier didn't happen. The rest of the network decided that this is actually the next block. And so your EVM connect and the new blockchain connector framework handles all of those situations for you. So you don't have to worry about it. Basically, all you have to do is tell it, I feel confident that after X number of transactions that on this chain with the way the consensus algorithm behaves that things are not going to change anymore. So I've just set four here that's probably not an appropriate value for a public chain that you may be using. You should do your own research and figure out what the right value for your chain is and how many confirmations you wanna wait for before you feel confident that your transaction is final but that's what we're using here. Okay, so I basically just went through this tutorial. I have some accounts set up and I've funded them through the polygon testnet faucet here and I basically just kind of set up Firefly using this guide. So if we go over here, we can see Firefly is running. So what I wanna do now is I have my default namespace. I wanna configure two more namespaces. So I have a hypothetical red team and a hypothetical blue team and I'm gonna give each of them a namespace and I want each of them to have different authorization and a different signing key that they're gonna use by default. So to do that, I'm gonna do a couple of things. So first of all, let's go create the other signing keys and sort of install them on my Firefly signer. So to do that, I would run FF accounts create and then I would give it the name of my Firefly stack and this would be, I called it webinar. Now, so I would run that. I've already run this a couple of times to set up my accounts. So I'm actually gonna, instead of FF accounts create, I'm gonna list the accounts that I have and it should give me three. Okay, so here's my default signing key. Here is my, this is gonna be my red team signing key and my blue team signing key. Please don't use these addresses as I have now just leaked their private keys to the public internet had these are throw away. So don't do anything with them. That's my disclaimer. Okay, so what we're gonna do is we're gonna, there's a new guide in the docs. Actually, it's a PR that's open for us. So it's not quite in the docs yet, but here it is. I'm gonna walk you through this. So this is how to enable basic off on a namespace. If you're looking for general information on just, you wanna do more reading on a namespaces in general, there's a great reference guide that is in the docs here. It's under reference and it's under namespaces. And this just walks you through, kind of starting from a high level like what is a namespace, the difference in a multi-party and gateway namespaces, how to configure one. We've talked through a lot of this already today and I'm gonna show you how to configure it, but this is another guide that if you wanna, you know, kind of for your own information if you wanna read up on it afterward. But we're gonna go through just a couple of the steps here in this basic off guide. And so first of all, the basic off plugin for Firefly uses Bcrypt. So basically you create a file that has a list of users and their hash passwords in it. And you can use the HT password utility to do that. So I've gone ahead and done that and I've created a couple of those. So let me show you what those are now. So I've got, now we'll just use this terminal here because it has a good font size. So I could just cat, I've created one called test users. And so I have a Firefly user in here and this is the hash of their password. I've set my password to Firefly. You should set a more secure password than that but that's what it is. I have red users and I have blue users. So I have three different password files. One for just general test users, one for my red team and one for my blue team. And they each have one username in them. So that's what I've created ahead of time. And I just did that by following this guide here and using the HT password tool to create that. So now we're gonna go edit the Firefly config file and we're gonna enable some new plugins. So to do that, I'm gonna open up Visual Studio Code and I'm gonna edit my Firefly core zero YAML file and that should open it up here. I just, could I get a quick yes or no poll in the chat is my font size readable to everyone or would you like me to increase it further? Okay, cool. I have no idea. Sometimes it doesn't come through well on the YouTube stream. So hopefully it looks good on YouTube. I'll just bump it up one just to be sure. Okay, so thanks for commenting on that. Appreciate it. Just wanna make sure that people can follow along and they're not having to squint at what I'm doing here. All right, so this is my Firefly core config file. Like I said, we're gonna get really hands on today. So I have one namespace configured here. It's my default namespace. It has a default signing key that's configured and it has a list of plugins. They're using the very cleverly named database zero, blockchain zero, date exchange zero, shared storage zero and a token connector as well. If I go further down here in the YAML file, I have a plugins object that has some sections in it. It has a section for each of the different types of plugins that Firefly supports. So there's a blockchain section, date exchange, object, shared storage and tokens. And there's another one, a new one, auth which is not here yet, but we're gonna add that. So each of these is, so my disclaimer is I do not have a degree in YAML editing but I'm gonna do the best that I can here. So hopefully I get all my indentation correctly and this works, but yeah, YAML's a fun, it's great and I love it and hate it all at the same time. So each of these, so like blockchain is a list. So we have one item in the list and it's Ethereum and it is, we've said it's, so we've given it a name of blockchain zero and we've given it a type of Ethereum. So it's a list of objects here. And so you could continue, you could configure more than one blockchain connector this way. All right, so what we're gonna do so that I get my YAML correct, I'm gonna hop back over to my guide and I'm gonna copy this section here and this is our configuration for our auth plugin and I'm gonna go paste this in. So we're defining, this is a new type of plugin and so in the auth, so we're setting up like all of our different auth plugins here. So here I'm creating one, I'm calling it test user auth. Its type is basic auth, this means use the basic plugin that's built in and then the basic object here is, oops, sorry, is where we configure it. The basic auth config has one option that it takes and it's the path to the user's password hash file. So here I've given it Etsy Firefly test users. So the next step will be actually getting this into my Docker container and I'll walk you through how to do that in a bit, but this is where we're gonna put it, right now it's just in my home directory on my host machine. So I need to define a couple other ones for my red team and my blue team as well and I'm gonna get my indentation right here and then we're gonna call this one red user auth and we're gonna change this to red users and this is gonna be blue user auth and this will be blue users. Okay, so we've defined our three plugins. We don't have any namespace using those plugins yet though. So what we're gonna do is we're gonna scroll up here to our existing namespace and I'm gonna create some more namespaces here. Now I could use this test user auth on the default namespace if I wanted to. I'm actually gonna, for now, just for this demo, I'm gonna leave the default namespace unprotected just so that we can poke around in the UI easier and that sort of thing, but you could set up auth here by just adding test user, sorry, test user auth just like that. We're not gonna do that for right now, but what I am gonna do is I'm gonna copy the namespace config here and make sure this is all indented correctly because that matters in YAML. Okay, so we've got three different namespaces. We're gonna call this one red. It's name is gonna be red. It's just, this one's description is blue and it's name is blue. Okay, so we've got three different namespaces that are named differently, but they're all using the same plugins right now and they're all using the same sign-in key right now. So now we're gonna customize them a little bit. So we're gonna add to the list of red namespace plugins. We're gonna add red user auth and then to this one we're gonna add blue user auth. Okay, and then now let's change the default sign-in key that they're gonna use. So I'm gonna go back to my terminal and I'm just gonna FF accounts list and this one I'm gonna give, so this is my default one. I'm gonna assign this one to my red team and this one to my blue team. All right, so that should be good to go for the Firefly config if I remembered everything correctly. The next step is we need to actually, so Firefly when you run Firefly CLI runs all the different components in Docker containers. And so I need to actually, like I said, that those password files are sitting in my home directory on my host machine. I need to get them into the Docker container somehow. So the way to do that is by adding a Docker compose override. This is, in my opinion, the easiest way to do it. There's more than one way to skin a cat, but. So what I'm gonna do is I'm gonna edit my Docker compose override file from my stack now and we're just gonna open that up here. Actually, I think I have it. I think I actually have it open in another tab. Yep, here it is. Okay, so this is what it looks like by default. It's got nothing in it, but this section of the guide says, just add this, make it look like this. And so we're gonna add this here and then set path to your users file. And so this is gonna be users, Nguyer test users. And then I'm gonna add two more for my red and blue users as well. Yeah. I hit save. Okay, so that should be good to go. Now I have three different namespaces. I have three different password files. I'm mounting the appropriate files in there. At this point, if you're following along in the guide, what you would need to do is actually restart your Firefly stack to pick up the new Docker compose override and read the new config file. So you run FF stop, FF start. Again, for the sake of time, I've gone ahead and done this already. And so now what we should be able to do is we should be able to make some requests to our Firefly node. So first of all, actually we should be able to come here and see that we have three different namespaces now. We've got the default one, the red one and the blue one. We should be able to make some requests to the various namespaces. And so if I try, for instance, if I'm a red user, I've added a username and password here to my curl request. I try to access the blue namespace. I get unauthorized. Likewise, if I try to access my own namespace, I can query the API. So that's good. So author's working. The other thing I wanted to show is that when I submit transactions, each namespace, each team is going to end up using a different signing key by default. So I have gone ahead and I've deployed a contract already here. It's just a simple storage contract. So it allows me to, if you're familiar with simple storage, basically it just lets you set an integer on a blockchain and query it back and it emits an event as well. So I went down here, so we can go look at this. Again, this is using a public chain. So you can go look up this contract that I deployed earlier. I deployed that from my default signing key here and then I set the value original. I set the value in this transaction with my default signing key and then I set it as the red team over here. And in just a minute, I'm gonna go set it as the blue team and we'll see what that looks like. So I should be able to actually pop into these and see if I can see what I actually set it to. Yeah, so I set it to one in this one. And then I believe it was set to two in this one. See what was in this transaction. Yep, okay. So let's go in as the blue team now and we'll set this to three. So what I'm gonna do is I'm gonna pull up postman because that will let me set off very conveniently here. Let's do, actually before we set it, I'm gonna do a, I'm actually going to query, get, I'm just gonna double check my value. And then I wanna do this as the blue, I'm gonna do this in the blue names space. So it says unauthorized. So that's actually what I expect because I haven't given it any form of off. So I'm gonna go here and I'm gonna enable basic off and I'm the blue team. Make sure my passwords are correct. Okay, so the output is currently two. So let's set it to three. So basically where you're going to change this to invoke. If you've seen Firefly demos, you're probably familiar with how Firefly builds these REST APIs for smart contracts already. I've just gone ahead and set up all of that ahead of time just for the sake of time. So we're gonna invoke set and the, see, actually, you know what? I have this, I believe I have this query. Yeah, here's the correct payload for that. I'm just gonna copy this over here. And I will set our new value to three and make sure I'm doing it in the blue namespace and I've set my user off to blue. All right, so let's run this. Okay, so we've submitted a transaction. It's currently pending. The new value will be three. And so the ideally here, this would be your application submitting a transaction, not a human at sitting down at Postman. And your application would also be listening on Firefly's WebSocket for receipts from when the transaction is actually complete. So you would know immediately once that fourth confirmation has come in. I don't have a WebSocket listener set up at the moment, but what we can do is we can go back here and we can look at the, look at that. There's our transaction, came in 28 seconds ago. It was the set method. And look at this. It was from the other, from a new signing key that we haven't seen here before. And I bet if we go back to our Firefly config 0x1CE, yep, that's our blue team's signing key. So blue team just set it to, let's take a look at the transaction itself and it set it to three. So there we go. So this is a public transaction. Anybody can, if you're clever at copying and pasting from a video, you could go look up my transaction on that Mumbai Poly polygonscan.com and you could see those transactions coming in there on that contract. So that's it that I had for the hands-on section of this kind of walking through all these new features. You know, starting up Firefly in gateway mode, connecting it to a public test net, configuring multiple namespaces for our red team and our blue team, enabling basic auth and performing transactions with different signing keys for each on those different namespaces. So that's it for the demo portion. Just one more slide before we wrap up and then we'll leave a couple of minutes for questions here at the end. But I just, first of all, I wanted to thank everyone for coming out today. We've had a great turnout here and super excited about where we're at in the project. But most of all, I'm excited that so many other people are excited about the project and that you're here and wanted to learn about it. So I just wanted to take this moment to encourage you if you haven't already, please join, get more involved in the community. Join in Discord, this is a great place if you have, you know, after today, if you have questions for me or for the rest of the team or other maintainers, there's a Firefly channel in Discord. Go ahead and join there. And we'd love to chat with you there. Obviously you can go check out the source code on GitHub and we would love to have more people get more involved in the project. So just wanted to make a quick shout out for the community and encourage people to get more involved in the community and super excited that you're all here today to learn about Firefly though and thank you again for coming. So with that, I'll wrap up and I will open it up to questions that people have. I guess I'll start by checking out the chat here because there's probably going to be quite a bit of chatter here that I haven't looked at. First of all, was the video shared? Yeah, yes, it's on, it'll be on the Hyperledger YouTube channel but we're actually live on YouTube right now so you could be watching it there I suppose as well. Any Hyperledger tool training providers in Bangalore or India? Off the top of my head, I'm not, there's a great Hyperledger India chapter there. I'm not sure if you're a part of that or if you're aware of that but that may be a great resource for you. Okay, lots of questions coming in now here. I'm gonna try to keep up. Make use of, okay, yeah, but I think that was an answer to that question. Okay, in the demo, you start the note in gateway mode, briefly how to run multi-party and gateway mode at the same time. What kind of config should be in the override files? Why does the query API doesn't trigger the blockchain event? Ah, good questions. Okay, so I'll try to hit these as quickly as we can here. So yes, I started in gateway mode the Firefly CLI right now. So the Firefly CLI is a tool to create a local development environment. In its current state, it has the ability to set up a stack and configure a namespace in either gateway mode or multi-party mode. Firefly can absolutely operate in both modes at the same time. The tooling automation to just configure that based on one command line, this is not there at the moment to create like a local development environment. I have done it before. I've demoed it. That was one of the things we showed it at Hyperledge Global Forum and it was really cool. We talked to both a fabric chain running locally on my computer and a public chain test net as well. There's quite a bit of configuration that goes into that. So it's absolutely a supported use case and definitely something that you could use in production. There's just not a tool to set up like a local development environment that has many namespaces configured in very different ways. Why does the query API not show up in the blockchain explorer? That was a great question. So the query API actually does not perform a blockchain transaction. It's using a different, it is using a different JSON RPC call at the sort of the Ethereum protocol layer. And so it doesn't perform a transaction. It just queries the current state of the chain. So it actually doesn't need gas to do that. And that's something you could do for free that doesn't cost a transaction. Would it be right to call Firefly Middleware software? Yeah, I think that's a, as boring as the word middleware sometimes sounds. Yes, I think it is. If you think of it as a stack that sits between your application logic at the top and a blockchain at the bottom, it fits the definition of middleware absolutely. Is there any hands-on demo available out there with effective private blockchains like Fabric, Arthi, Corda, et cetera? Yes, absolutely. So basically all of our other demos, we're all using private blockchains, either Ethereum-based chains or Fabric networks as well. Only very recently have we started demoing public chain support because it was as a new feature in 1.1. How can we apply triggers in a hyperledger? I apologize, I'm unclear on what that question is asking. If you could clarify, that would be great. And I can try to come back to it. Is Firefly part of Linux foundation? Yes, absolutely. So Firefly is a hyperledger project. The hyperledger foundation is a part of the Linux foundation specifically focused on enterprise blockchain software. Oh, I see David already answered that one. Thanks, David. Oh, I'm sorry, I missed a question early about tokens. Thanks for bringing that back up. I'm trying to keep up with this scrolling chat here. Does Firefly support tokens other than ERC721 and 1155? For instance, a Casper CEP78. Yes, absolutely. So Firefly looks at tokens from a slightly higher level perspective. So Firefly's tokens APIs are Mint, Burn, Transfer, and Approve. So as long as a token can do those four things, Firefly can support it, no problem. The thing that's necessary to add would be if you have a token that has a different contract interface than a ERC721 or 1155, there are blockchain connectors. So we didn't look at the big Firefly architecture picture today, but there's a small piece that sits in between Firefly Core and the blockchain connector. We call it a token connector. And that token connector is usually written to know the inner workings of a particular token contract. And so it's a very lightweight, small microservice that knows how to talk to a specific token. So if you wanted to run something, so we have token connectors for ERC20, ERC721, and 1155 today. So those are the three that are supported out of the box. Firefly Core itself, though, can work with, I'll say theoretically any type of token, as long as there's a token connector for that type of token. Hopefully that clarifies that question. Multiple questions in fabric, where can I connect to get those? I would say if you have general questions about Firefly and how to use it, I hop in Discord and I would love to chat there. That'd be a great spot. Yep, cool. Any other questions? We've got one more minute here, okay? Well, thank you all so much. Really appreciate everyone's time today and super happy to kind of dive a little deeper into Firefly 1.1. And yeah, just thank you for all the great questions and the great participation for today. We're gonna, I see one or two more questions in there, but we're out of time, I apologize. We'd love to take those questions offline if we wanna talk more on Discord. Come find me there on the Firefly channel and we'd love to keep chatting. Thank you all and I hope you have a great day today. Bye-bye.