 Hey Eddie. How are you? I am doing well. How are you doing? Well They changed up the zoom link on us and I'm wondering if people are still looking for the new one I've tried to post it as broadly as I can but People may need a couple extra minutes to join here today No worries. All right here they come Hey folks glad you were able to get the new meeting link Thanks. Yeah, we clicked on the meeting invite. I think there's a few people in the other one Well, I'm Andrew and the guy called pass is on there. So I'm I'm just gonna paste this link into the chat on the wrong one Perfect. Yeah, I only found out about the change yesterday. I've tried to Circulate it as widely as I could but I think if it was stuck on their calendar already, I don't have a way to Update that But Matthew should we give those folks a few more minutes to pop over to this call? Go for it. Yeah. Sorry, Anika. Yeah, so I did post it in the everyone chat on the on the other link. So I think it looks even like some people are coming across now Okay, great. Perfect. Yep. I see some more folks joining Okay. Well, we are a few minutes after but I think we can probably go ahead and get started Now welcome everyone to today's firefly community call This call is being recorded as you were probably notified when you joined so just wanted to point that out just a couple quick housekeeping things as a Public hyperledger community call this the recording of this call will be posted afterward And we also need to abide by the Linux Foundation antitrust policy and code of conduct Which are both linked in should be on your screen right now and both linked in today's agenda So if you have any questions about those you haven't had a chance to read them before please go check that out and With that we can jump into today's agenda So the the first item on the agenda for today is a As a proposal for new maintainers, which I'm really excited about I want to introduce to the I'm sure you probably had a chance to meet or have interactions with Both Matthew Whitehead and Chen and they have both been making fantastic contribute contributions to a variety of places in the the firefly project, but primarily in the EVM connect connector, which is one of the One of the more foundational one of the lower level layers of the stack and a really important piece of the project so Matt and chime have have demonstrated significant thought leadership in in the future in the direction of the blockchain connector and Have just been making fantastic contributions to the project I want to bring them on as maintainers so they can move to actually approving pull requests as well Which they have been actively participating in already And so so the way the process works is I'm I'm proposing I'm sponsoring them as the existing maintainer and at the next community call We will have a vote if existing maintainers are not able to attend the call They will be able to vote via email as well, which I will I will send out an email to coordinate that amongst the maintainers and then after the next community call they will I'm assuming that the votes will all be unanimously in favor, but They will be brought on as official maintainers and added to code owners at that point and the appropriate github user groups, so Um, yeah, I just wanted to briefly introduce Matthew and chung I don't know if you just want to say hi to the group here But thank you guys so much for all that you've been doing in the project and I look forward to continue to working with you as potential maintainers going forward Yeah, great. Thank you very much. Nico for very generous introduction yet. I'm nothing particularly tired at this for this point, but Thanks, Nico. Yeah We'll wait for the next call Thank you guys. All right. Now moving on through the agenda So one of the things that we wanted to talk about today is Some of the things that are interesting and exciting coming up in firefly 1.3 So some of those we're just going to talk about and just briefly touch on in the bullet points But one of them in particular Enrique has offered to actually do a little demo of So to most of these things that are on this list are things that are with the exception of the last one Are things that are already merged into main and are there and if if you like Bleeding edge software you can go check them out today They have not been in an official feature release of firefly yet though So that's just kind of where most of these changes currently stand But with with no further ado, I will turn it over to Enrique to demo one of the new upcoming features in firefly 1.3 Sounds good. Let me share my screen All right So yeah, so as as Nico mentioned, we did a lot of MTLS work and recently one of the big change that went in is the ability to configure MTLS for webhooks As I think most of you are aware there's ability for you to listen to certain events through webhooks And now we've made it to be able to configurable The configure a different TLS configuration per subscription Um, so now when you create a name space, um, or when you specify in your Configuration YAML you can specify a set of an assuring a second a set of TLS Um certificates or PEM files That then you can reference when you create a subscription Um, so if we quickly look at the, um Docs so under each of the namespaces that you are predefined you can add a TLS configuration where you can give it A name, um For that TLS configuration that you reference afterwards, you'll have a path to a CA file A path to a certificate, a path to a client auth in the case where you're doing MTLS So this is TLS or MTLS If you want to enable it and you can also do some verification checks as well You also need your your key file as well because that'll be your private key for the MTLS communication And that will allow you to then use that as part of the subscription So we take a quick look at the API And I'll show you one that I just pre-created So I have a little sample express.js Server running locally, which is secured with MTLS So it has a server key a server cert the client CA cert that it trusts And then it's requesting That The client provides a certificate and it rejects one size unauthorized Has a sample one that says hello and has a one that just console logs events from firefly So here all my testing that did earlier. So when and it's not filtering So at the moment, it's whatever event that comes out of firefly. We're able to just log it to the console At the same time, I have using the firefly cli Run a stack With two members in it And and its own chain And I've specified a TLS config for my predefined default namespace. Hopefully that's big enough. Let me know if you want me to zoom in And there is a TLS config here Which specifies a path to those certificates that generated. So that'll be the CA for the server The client certificate and the client key So if we go back to the API, you can see that I create a subscription To my local 3000. That's where my express app is running I want the data to see the events and here I've referenced the TLS config name that was in my Firefly configuration. So when an event Is produced in in firefly that I'm interested in at the moment, as I said, no future. So any events really I will be able to use it will use firefly will use those TLS certificates to call my workbook endpoint So if we Quickly check that. So I have a sample contract that I deploy this part of testing And I'm just going to invoke one of the functions, which is just the owner function And if I execute that and I go back to my terminal You should see a series of events have just occurred. So there's a little bit of debugging here That I put in express that tells you that there's been an effective a TLS handshake that's happened Um And you can also see another TLS. So first you get the was I submitted and then you get the operation succeeded So yeah, that's a quick demo on How and you can configure your namespace with a set of TLS certificates and keys and then use that as part of subscriptions for webbooks today Um, yeah, that's that's mostly what I had to show. Um, let me know if you have any questions or if you try out Let me know I guess Thanks, Enrique. I really appreciate that great demo fantastic new functionality there building on on what's been there and Thank you for the demo any any questions on the What Enrique has shown here before we move on to just chat about some of the other upcoming features Okay, cool. I'll go ahead and share screen again so we can Pull up the agenda here Yeah, so just I really quickly wanted to just touch on a couple of the the things that are in the new In the upcoming release of firefly again Most of these are merged into main and I'll touch on the ones that are still in active development here um, one of the the the really exciting things and Maybe Andrew can chime in and correct me if I'm wrong, but I think this one is is mostly in main, but there may be a few smaller sub work items that are still outstanding on this one, but So firefly has long had Really powerful messaging features and functionality In uh, what I think from what the earliest versions of firefly one of the really compelling features was to be able to attach a message or associate a message with a A token operation whether that was a token mentor token transfer And it sort of allowed you to associate extra data with the transfer as well as having a link on chain that Says that they go together and to be able to prove that on chain While keeping the payload of all this extra data, whether it was metadata or or even another image or whatever it is off chain as well And so so this is a really powerful feature of firefly. We are extending firefly's apis to now allow you to To do the same type of thing with custom smart contracts and not just through the tokens apis so there there will be an ability to Basically in your contract if you add another parameter a data Parameter which or argument which is the the last argument of your function of type bytes It will allow Well, it's for for solidity in ethereum contracts. It's type bytes. I believe for fabric. It's just a string It will allow firefly to associate a firefly message with that contract invocation as well Um, I think andrew is on on this community call. I don't know. I know he's done a bunch of work on this as well I don't know if he had any details that you want to chime in on there or anything else you want to add or maybe correct me If I could miss folk there in a way Yeah, yeah, I definitely can can you hear me all right? Yep um Yeah, so I think you covered sort of the basics Um, I do you want me to share the the fire and just kind of the overview for people to reference it? I steal the screen share for just a minute. Yeah, if you want to All right, I'll let it play on the spot here. I didn't check with you if you wanted to Yeah, no worries. So this is um, if anyone wants to go see it um in the the firefly fire repo number 17 It's an open pr still um because like nico said the major functionality has been merged um, but there's still a lot of sort of edge cases And basically this this opens up some more of the core firefly functionality in terms of how on and off-chain coordination works So it essentially gives you a lot more ways to shoot yourself in the foot if you use it in the wrong way So I think there's still some work to be done here before we can consider it ready and shipable but uh fire 17 is pretty fleshed out at this point has gone through a few cycles of review and amendment um, and and like nico was saying essentially if you've used the firefly invoke apis at all This should look very similar right um, I can say You know, I'm going to invoke an interface uh at this address I'm going to invoke this method with these inputs and then there's this new bit. It's been added Which looks very similar to when you're sending a broadcast or a private or potentially a token transfer with messages We're thinking that this might even become the main way to send messages with some other Firefly transaction whether it is a token transport or just some custom method that you've defined You do have to Add some parameters right you if it's a an ethereum method. You have to have a bytes parameter on the end Where some data can get packed if it's a fabric method You have to have a string parameter on the end of your signature And basically firefly is going to pack this message. It's going to assemble a message the same way it does Um in the normal messaging queue And send that message offline and then it's going to pack depending data about that message in a predictable way That if you follow these instructions, you can unpack it and basically do a batch pin Yourself in a custom contract in either ethereum or fabric. So definitely a more advanced Feature um for for those who they're you know comfortable with the sort of basic API invocation and the basic messaging capabilities But I think this opens up a lot of really powerful ways Um to actually do custom on and off-chain coordination. So that's all I'll say about it here I think we have discussed this in an earlier form on a community call So happy to continue discussion on the fire or on discord And definitely look out for this pr to get updated as the remaining pieces get merged And hopefully is you know fully baked and available feature in 1.3 down the road Awesome. Thank you, Andrew Yeah, any questions on that on uh Associated messages. Yeah. I know this came up on a previous call, Andrew Um, and so would it would an accurate summary of this be that you you now have a way of invoking a batch pin from a contract Rather than directly from firefly. Have I understood that correctly? Exactly It's it's taking what firefly sort of codified has really the only Opinionated smart contract that firefly provides this very simple batch pin And it's exposing that in a predictable on-chain way So you can invoke it from another piece of on-chain logic And then tell firefly, you know how to get off-chain stuff into your contract and have it pop back out Um with a coordination message on the batch pin contract So, okay. Thanks. Yeah. Cheers Awesome. Yeah. Good good question. Matthew. Thank you Um any other questions on that one? Cool. Okay. Uh, I'm gonna probably go through these next few a little bit more quickly. Um, that was Yeah, I think we've kind of touched on some of the most exciting things that are in 1.3 Um Well, there's a couple other ones on here. Um Yeah, so I think in 1.2 Maybe we introduced an API that allows you to delete local data, uh, which can be really useful for if you have You know data retention policies and things like that It can allow you to purge data from your local database and from your local blob store in data exchange as well Continuing on that theme 1.3 will include additional API methods for deleting other resources like token pools, contract interfaces And then there will also be this A distinction between I'm just creating something and That's Can be a separate Operation from Actually publishing that thing to the network if you're in a multi-party network. So For example, you could create a 1.3 will have the ability to create a contract API and not publish it To the rest of the members of the network In in prior in the current version of firefly and prior versions in a multi-party network as soon as you create a A contract definition or contract API or or a data definition Those things are immediately broadcast to all the members of the network Um, that that made deleting them more complicated and so so there's some some Features that kind of work in parallel here Giving you more flexibility more control over where data goes and the ability to remove it when necessary Um, and rikki has has already demoed a portion of the next bullet point But there's configurable mtls across all of the different firefly microservices that use fire there's a common htdb request library that's used by Not only firefly core, but some of the other services as well And so anytime firefly makes htdb requests out It uses this library. And so there's a common set of configuration that can be applied to All of the different plugins that utilize this within firefly core For enabling a secure service to service authentication and encryption Um, another new exciting feature that's in active development right now is postgres support for evm connect persistence right now it uses level db and you'll be able to select between level db and postgres for Storing events and receipts and event streams and all that good stuff So that that should Probably come with some noticeable performance benefits as well. And so that's that's an upcoming change Um There's there's have been some improvements to the erc 1155 connector I believe this one's already merged that allow it to work with a wider variety of It's more flexible in the contracts that it works with In terms of different flavors of 1155 There are numerous performance improvements in transaction throughput Throughout the different layers of the stack If that could be a whole other community call is to all the all the places that We've we've improved small things here and there but Yeah, I just wanted to just briefly touch on that don't have time to go into all the the nitty gritty details there And although the last but not least is a new area of this will be the biggest Or one of the biggest That the first bullet point we touched on Is associating messages with with custom contracts is a pretty significant architectural change and improvement But but the other one that's coming in this release is Active active high availability as well. This is currently in the design phase There has done a little bit of coding on it But still a lot of design and just sort of figuring out the architecture side of things There is an issue on github that Has all of the the running list of work items that are related to it That is up there if you're curious as to what it all entails but the idea is that The goal is to be able to run multiple instances of firefly core simultaneously and Each instance of firefly core will use leader election to determine Which runtime is responsible for the critical threads That need to be sequenced and so so one of the the really core important principles of A blockchain and a firefly is sequencing and so anytime that there is a a Deterministic or distinct sequence that needs to be established the firefly core nodes will coordinate to elect a runtime to be the the leader for that particular threat and so Specifically that that comes in a couple of places One is the event aggregator So per name space there will be A runtime that is designated as the leader for the event aggregator And the other place that that is important is on a subscription. So When a web socket client connects to firefly core node and Begins listening on a subscription. There will be one runtime that becomes sort of the the leader for for driving That event subscription and delivering events to to their So lots of lots of work still to be done on this one, but it is in the early phases and really looking forward to to seeing the Just the maturity of the product In this area and I think it's going to be a pretty exciting one That is it for kind of the areas that I wanted to highlight I guess any questions on on the the 1.3 roadmap or anything that we've touched on thus far Hey, Nico, um, do we have a sort of a timeline in mind for 1.3? Do you have a sort of a finger in the air timeline for when when we might get out? Soon Nice Yeah, so I I think most of these are Close to ready with the exception of of active active. Um, I suppose there's possibility that we might That if active active continues to get pushed out, um, we there's enough other interesting things that we might cut a 1.3 and active active might slip to the next feature release, but Uh, I I think I think a 1.3 is is due at some point. I would say in the next month Or two at the most Okay, cool. Yeah, it sounds about right I know this is being recorded, but that's not a commitment just to be clear to to everyone else who might be looking at this Yeah, good question. Any any other questions? Hi, Nick. What are the other contracts? This is my first call. I'm ball. So what are the other contracts that you are trying to implement for erc one fund five five because that is that's what Well, hey, ball. Nice to meet you and welcome to your first community call. Um, yeah, great question Uh, I don't know Andrew is that one that uh that you could take there? Um, you may know more of the specifics of New things that it supports now that it didn't before Yeah, definitely. Um, essentially We started out with a pretty opinionated A set of erc 1155 that we supported right um because What we've kind of come to embrace I guess is that 1155 is a really really open-ended standard It's not even as opinionated as some others like erc 20 and erc 721 um, so we wanted to kind of get the best of both worlds in terms of Making it useful to do things that you want to do with tokens, but also making it flexible um, so when we started out we defined our own extension on top of uh, erc 1155 that had some constructs for defining what would be a fungible token versus a non fungible token and Defining a very specific way of partitioning the whole contract into different tools of tokens Which are are two common things that you can do with 1155. You don't have to do either But we wanted to specifically support a sort of opinionated notion of fungibility and of partitions um, and so what we've done kind of this past month or so is go back and adjust the connector to not only support that opinionated extension 1155 But to let you specify a little bit more how you would use it So basically there's more input parameters when you create a token pool that's backed by an 1155 contract So you can specify if it has a factory or not, you know, and if it allows you to create a partition Or if you're just using an existing contract you can use the whole contract as a single token pool Or you can use a partition of the token id space by saying a start id and an end id and say, okay, you know all tokens from zero to zero x f f are Going to be representative of a fungible pool, right? So just a lot more parameters to hopefully support a wider variety of custom 1155s out there So definitely looking for people, you know, kind of sponsored use that Because because you know, I've mostly used the sample that that we came up with But but trying to support other flavors and looking for people to help Make sure that we're addressing those Yep, thank you. I will try it out. So thank you then that would be great Cool. Great question ball out and thank you, Andrew for the added detail there. I appreciate that All right. Yeah at this point, uh, happy to open it up to general discussion on any firefly related topic whether it's about Things that we've discussed on the agenda for today or just kind of general Conversation the folks want to have or questions that you have about the project. The floor is now open So if anyone has topics that they'd like to discuss We've got a number of maintainers on today and we would be happy to chat about them Um, I'm going to throw one other plug out from the maintainer side. Um that we in addition to 1.3 We are trying to get a 1.1. No 1.2.1 a new patch release on top of 1.2 um I opened a pr with some backports that I think are needed for that Enrique, I know you had tagged some changes that you might Have wanted to you might you know have thought are necessary for a patch release. So just kind of a Bump for maintainers and contributors that are on the call. Um, I would love to tie that off Sometimes soon because I think there's some really important fixes. I started a thread on discord a while back I can kind of bump it back up. Um But yeah, we'd love to get those fixes out to everyone because I think there's some known deficiencies in 1.2.0 Yeah, it's a great call out. Thank you Any other topics that folks want to discuss today? Well, if not, I'm happy to give people the time back Thank you, Nick. Yep. All right Thank you everyone. Thanks for coming out. Uh, looking forward to Uh, the the vote to bring, uh, Matthew and Chung on for uh, as maintainers The next time and uh, yeah, thank you all. I hope you have a great rest of your day and we'll talk to you later Bye-bye