 Hello, everyone. Welcome to the weekly TSC call. I think everybody is familiar with this, but this is a public call. You're welcome to join, but you have to be aware and live by the antitrust policy, the notice of which is currently displayed, as well as the code of conduct by which we all live. All right. With that taken care of, we can move on to the announcements. There is nothing new that I know of. These are really just reminders. On the first, the first one is the ongoing newsletter, just a reminder to keep consider contributing to the newsletter. If there's anything newsworthy that happened in your project. And then the, the, the Hyperledger forum registration is ongoing. Please register if you haven't done so yet and spread the word. Is there any other announcements anybody wants to make? It's not very technical, but there's a brand awareness survey that we've pushed out to the wider, both open source community, Linux foundation community, and obviously over Twitter and LinkedIn, to try to get a sense for where enterprise blockchain as a whole and the perceptions of Hyperledger are. And I know again, it's not, not as cool and sexy as code, but I think it's really important for us to, to just help do this collect, get a collective sense of where the world is on that. I'll, I'll drop a link. But, but you might have seen some of us tweeting about that. Yeah, the more we can get that out there and people aware of it, the more helpful it'll be. Yeah, that sounds good. Thanks, Brian. Anything else? I think once twice. Okay, let's move on. So in terms of quarterly reports, we have two reports on going. I think Roja was posted already last week. I don't think there's anything new. It seems like, but everybody has had a chance to look at it. I don't think there is any specific issues. There was the issue with the, that we talked about. I mean, I don't know, right? Did you have a chance to follow up on the DCO issue they reported? No, I, I dropped the ball down. I need to do that. No worries, but yeah, let's, let's not forget completely. Thank you. And then we have the Aries report that came in. So here they actually asked, I mean, they want to do an audit of Ursa. And I understand from Brian that this is actually planned. Yeah, this is security in planning. I've got to work with them on kind of just nailing the specifics of what they want audited and then working to we have, we have funding available to do security audits and, and a good chunk of that for, for this year still hasn't been identified or allocated. So, so we plan to put some resources in and it sounds like there's a source for third party funding for it as well. So that's, that's in progress. Right. I, you know, I'm not sure why Steven asked for help from the TSC. I don't know that there's much we can do specifically here, but I'm, I was aware that we're planning on doing some kind of audit. So hopefully, you know, we can, I consider this in Brian's hand. Okay, I think he wants your help in pressuring me to move over quickly. Fair enough, and I, yeah, pressure is on. Thank you. All right. So, but so is there any questions on any of those, I mean, either Eroha again or Aries. If not, I think we can just move on. Seems like even though, I mean, it was posted last week. I don't remember the, at least I don't remember the name this, the weeks anymore, but it was quite a few days ago. So I think most people have had the chance to look at it. And so the next report due is borough. It'll be interesting to see how long it takes. So he lets to, to post the report this time. But so that's about the reports. So let's get to the crux of the agenda. We have several discussion items for today. The first one is looking again at the firefly proposal. So following up on the, on the, the call we had last week and the submission of the proposal by the collider team. There was a couple of threads of discussions. There were some comments against the document itself in the, the Google doc. And I think all the comments were basically addressed by the collider team and it seemed like, you know, I looked at it again yesterday and seemed like the common thread that died down. And I think that we have, we have several representatives from the collider team on the call now. And if there are anybody, if there's anybody who has more questions, you know, it's a good time to raise them. I know that there's another thread that Daniel actually started on the rocket chat, which had, which was not a technical issue, but more of a license issue. And it's still, you know, to be finalized or closed. Brian, I think took the action item to look into it. Do you have an update? I don't have an update on it. No, I think, I think the key question is so, so there's a static binary that's created. And that includes LGPL libraries, right? Because that's the way that Go works. If I'm understanding the issue, are we distributing the LGPL, the static, the static code, or is the static code just the result of something that happens is compiled locally after people have downloaded everything and started running it. So let's get to the bottom of this. So, Daniel, since you brought it up, it seems to have a good understanding of the issue is about $12. So the LGPL was a license generated sometime in the 90s based around the notion of GPL libraries. If I make like, say, C-Lib and link again, it's my program. Do I have the LGPL, do I have the GPL obligations to redistribute? And so they created the lesser, not the library GPL, but the lesser one. So that when you dynamically link to GPL code, you do not gain the obligations. And that's only really the structure is described in the LGPL really only applies to 90 style dynamic library linking that you would do is like .so's or dilips or DLLs. It really does not include when you combine into a single binary because there's no way that we're about to library replace with a different one. And that's the premise of the library of the LGPL, the lesser GPL, is that if you can replace it with a different non-GPL library, then you're just using it as a library. You can just plug it right in and right out. Now, go, not go. Java kind of dealt with this issue a little earlier. And again, they created their own version of the LGPL called the GPL with the class path exception. And they rewrote the legal terms of what would be the LGPL thing of if you're just using it as a library, you're fine. And they wrote it in terms of how Java uses it. Using the class libraries and the jar files is the boundary by which the obligations do not propagate as opposed to dynamic linking. So there is precedent that when you do a different language model for the lesser GPL that you really should be updating what the license is code for it. The Go Ethereum team, however, chose the lesser GPL for their code. And they didn't put any specific Go bindings on it. And there's many people in the Go community who feel that the LGPL is not appropriate for Go code because of that, because they feel that the LGPL obligations, because the way that you use it is you take the entire source code, you compile against that source code. There is no header file and you compile it together from that. And there are many in the Go community who feel that that triggers the general provisions, not the lesser provisions of the LGPL. And they recommend if you really want, if you use it and you just use it as a library, you should license your stuff under the Mozilla public license. So even if the LGPL license code was distributed separately, even if somebody, when they sat down to build it and run it locally, was separately obtaining that LGPL code from the Go Ethereum repos or whatever, that the provisions would still carry because there's not a number of alternative implementations. It's not a general purpose API. Right. Some of the stuff that I read, you're not a lawyer, you should get a lawyer to chime in on this. My understanding is because there's no ways to replace it with a different set of code. It's not really using it as a library. It's producing a combined work. And that's the difference between us as a library combined work of the main triggers. Now, the particular code that I've seen is mostly using the ABI stuff and Go Ethereum to access the smart contracts. And I think it's worth an investigation. I think the Bureau project had to write some of this stuff to do some of their smart contract integrations with Solidity and with the EVM. So I don't think this is, you know, a hard stop. I think that this could be replaced with code from Borough, which, you know, scores two wins. It keeps it a patch of two and it increases use, reusability of hyperledger based programming and Borough project is written in Go code. So I don't think this is a hard stop. I think this is, you know, I think there's a way out of this that doesn't involve going to the governing board and asking for an exception for this code. Right. I'm Peter here. This is one great summary. Thank you. We've obviously thought a lot about because actually it doesn't apply to the core of Firefly. It applies to code that's evolved over quite a long period of time, a couple of years now. So there is a step that can be taken quickly and efficiently, which has a technical implication that sorts out the licensing, which is Go does have a dynamic loading framework. It's a little bit immature because it doesn't work on windows, but it is sort of fully compliant with all of the concerns around being able to, you know, separately distribute the binaries, et cetera. And it also, but it pushes you to create a really clean interface in front of the code that you're using. And we've done this on other projects. So it's straightforward to do. You know exactly how to do it. And what it would mean is you basically split into two repos. You have a repo, which itself can be a GPL license, which becomes a dynamic binding library for the Go Ethereum code. And then there are no Go Ethereum dependencies get pulled directly into the Apache two license. It just depends on this one. It has a plugin interface, which is, which provides the boundary. So that's a piece of work that we know the size of. It's very straightforward to do. And it would just like said, provides the options for the community to plug in alternative implementations of those, of those, those interfaces down the road. And it would mean the one special case where there would be a need for developers to pull down Go source code. The Go Ethereum source code would be when building for windows on their, on their laptop, but there would need to be a bypass of what you wouldn't be able to build up for windows. But I think all of the distributions that we're doing certainly the developer experiences or builds around Docker that's, and obviously Docker fully supports it because it's going to be Linux based. So, so that was a fair bit of information there, but I guess what I'm saying is two things. One, it's not part of the core. It doesn't actually necessarily have to move into the foundation at the same time as the core. The ethernet code base, although we'd love it to move at the same time under the same governance framework. And even if we were looking at the time of the next couple of weeks, we know that if it was a, if it was a pre-req to, to be for, for hyperledger being confident to sign off on this, we could certainly have that boundary in place on that timeline. It's well understood work. So it would just be a real shame for this piece to sort of slow down the evaluation of the wider code, I guess. If I could comment for just a moment, I mean, I will point out that Gary sent an email saying he's agreed to become a co-sponsor of this project and his vote is yes. But the larger issue, if Firefly came in with whatever three repos that were fine and there was a fourth that couldn't come in, I don't think there's any requirement for the TSC to say, okay, now you can bring in this, this final piece. So what I'm saying is this project could be approved without that repo. And then that repo could be brought in later. I don't see this as a blocker. Great. So has any look, has any effort been put in looking to see if the borough provides adequate rub replacement APIs as well? Because that would also help strengthen the bonds between Firefly and hyperledger and the rest of the community and hyperledger too. Has that been investigated or has it just gone down the DLL and scope? I think what we're saying is there's multiple stages here and there's a lot, a lot of active development happening on the core at the moment. So we're looking for a piece of development that enables that investigation to happen, the really deep, multiple engineering days, investigations to wherever things work. And this is code that is used, like it's very highly adopted code, this code, it's a separate runtime. So that's sort of the investigation and development activity would take time. The DLL insertion point allows you to choose then which implementation you use through a dynamic linking, which means that the investigation of alternative implementations of OOP encoding, et cetera, can happen and isn't critical path. All right. Tracy has been waiting with her hand up. Yeah, I just wanted to make sure we clarify on Rice comment there. If we were not to bring in this now, we wouldn't want to bring it in later in the same format. Right. We would want to fix the problem before we bring it in. The, the ETH connect code base. So I wasn't clear. I'm sorry. Yeah, no, I just want to make sure that was clear. Because sometimes, you know, things get said and people misunderstand and we really do want to avoid this whole GPL sort of conditions on the surface. Yeah, what Tracy is saying is that, you know, just, you know, it's not because we're not looking anymore that then you can add with the problem. But so I think that's understood. And I think that I think really rice point is, is valid though, is that, you know, it's, we don't have to tie the approval of the proper project proposal to solve in that particular problem. I mean, you know, there are projects that start with that code for that matter, and it's not necessarily a showstopper. So this code could be left outside of the proposal for now and, you know, brought up later and brought in later on, if it can be fixed so that it can adhere to the, the hyperdager rules regarding licensing. So if that works for, I mean, so it sounds like there's more work that need to be done exploring the issue and possible solutions. I mean, I thought that Dano's point about the borough is an interesting one. It's definitely worth investigating if there is code that has already be written to kind of, you know, avoid the issue here that could be leveraged so much the better. Tracy, your hand. Yeah, it can back up. So, and you still love, is that the purpose or this? Yeah, definitely. So my, I did see in the chat. That Dano had a comment about the, the, each connect piece of this project being a pretty core piece, right? Connecting to Ethereum sort of ledgers. Yeah. I would like to clarify from the Firefly collider team, whether or not this is an accurate statement. It sounded like maybe it's not core, but I want to make sure like, even if we decide like, okay, let's bring in three of the four repos that we're not leaving off basically a critical portion of Firefly. Indeed, that's a very good point. I was going to ask that as like, can we still make use of, you know, Firefly without this piece? How useful is it? Yeah. So, yes. Absolutely for the, for the fabric and quarter. Communities that can be used without any need for, or if connects, if connects to the example of a use of the plugin infrastructure inside of, inside of Firefly. So the, it's a separate runtime with, with, with a network connectivity interface. So in terms of evolution of a, an open source project in the open inside of Hyperledger, not just plugging in inside of ethernet, but plugging in a different, a different implementation of a binding to Ethereum is absolutely possible as well. So yes, I think the projects could be very vibrant and active without needing to be very dependent on, on ethernet. Also, I think with the solution we talked about today, we, we could have that solved as well. So the ethernet would not be a barrier, assuming the dynamic linking is, is the solution as it sounded like it was from the, from the introduction, but that would be a solution. We could just have that, have that solved and pull it in. I do think it's important to clarify that I, I don't know, sorry, Steve here. I think that there are at least two solutions that, that are known and we're pretty confident in. And Peter's point was we could potentially, they're not mutually exclusive. We could potentially do both in the sense that, you know, if, if we do isolate the Go Ethereum, LGPL code inside of a DLL, you know, inside of its own repo and interface, that, that would also allow the opportunity for, for Borough to be considered as, as a second implementation as, as a sort of a plug-in inside of a plug-in, if that makes sense for, for the, the low level blockchain connectivity to Ethereum. So I do, I do think we have, you know, a pretty, pretty high degree of confidence in the path here. And just to be really clear, we haven't sized in days to, to do this. It's not a, it's not a huge lift. It's, it's just, you know, it would be great to hear from folks, you know, on, on the timeline of the next few weeks of, of, you know, how we want to schedule that in. All right. Thank you. Angelo is next. I know. Thanks. Actually I have questions on another side. I mean, you know, this one, I'm just raising my hand to check if it's possible to ask questions. Please go ahead. Yeah. So the few questions and that, and that remark, can you clarify if my understanding is correct, that the Firefly uses the blockchain as just a time stamping service? First question. Not, not quite. Firefly is about making patterns of use of blockchain that really happen for real in real enterprise scenarios, massively easier than they are today. And from an observation of what we'll enterprise production networks have been doing for the last few years, transferring off chain data and sequencing it is really high up there as a very high priority use case, but also tokens non-fungible and fungible tokens are also really high up there on the use cases. And there's many more besides that are, that are more evolving. So while there's heavy lifting, plumbing heavy lifting to coordinate a very simple on chain transaction of just a pin with loads of really complicated off chain transactions. And that's a lot of the code that exists inside of Firefly because it's a really hard problem to solve. And it's an important one as a foundational one. That doesn't include the use of much more sophisticated on chain logic in projects that want to do it. It's just in the enterprise space. It's quite interesting to observe that actually what that logic is is quite hard because the, because there are all the challenges of the immutability and the fact that you have to share the data where the logic executes and all the like. So we see quite a lot of adoption of the pattern of simple on chain transactions and complicated off chain data. So what I was going to say is that it's in the sweet spot. It's foundational, but you can use it for ordering and sequencing. But that's far from the end of where we expect multi-party systems used to use blockchain. We also expect multi-party systems to use technologies that are in the multi-party system space, but not explicitly blockchain like multi-party compute, like trusted execution environments, have a long, et cetera, and, and CKPs and being, and, and those can fit into the model as well. So it's intended to be quite an open model, but to solve some really hard and obvious problems on day one where one of the really hard and obvious problems that needs a huge amount of engineering to solve is coordinating off chain with on chain. And I must admit that to me the problem is not well defined in the proposal. So if I understand correctly, you either use the blockchain as a time-stamping service, or you use the full power of the block chains that you need, you want to use, I don't know, Ethereum, Fabric, whatever. And then at that point, you need a protocol to make them interoperable. So which like at the end you will use Cactus and other things. I must admit the document is full of words. So it's full of generic concept. I don't really see, you don't, at least maybe I'm missing this part. You don't, I don't see an example, a clear example. Say, say we are, this application can be handled beautifully with our framework, or this is the problem. We solve it in this, in this way, clarifying also where is the power of blockchain? Because again, if you are using it as a time-stamping service, what's the point of blockchain? We just use Ethereum mainnet to push some ashes from time to time. There is also the other point of zero knowledge. I would like really that you make an effort to clarify how, how would you make it possible to use zero knowledge on very different technologies like blockchain technologies like Ethereum and fabric that handles the life cycle of transaction in a very different way. I'm very curious about that. I think it's a hard problem. If you can solve them, please tell us the solution. I guess I have no idea. Interlock is not a housing thing. Guys, just, Peter, Peter, before you go there, I just wanted to react to one thing that Angelo talked about, which is, you know, integration across different types of networks. I mean, it happens that I asked that question to the Kalaido team when I first talked to them. And I mean, Kalaido, Firefly is not meant to work on multiple types of networks at once. When you instantiate a network, you choose which underlying blockchain you use. So they support different kinds, but not simultaneously. So there is no room for some kind of framework underneath. Whether you choose Koda, you choose fabric, or some Ethereum network, but you don't mix and match those. So I just wanted to clarify that because I have the same kind of question. I think it makes a big difference. Oh, that's a good point. Thank you. Indeed, I would say then, even if you do that, how would you make Koda and fabric compatible? Either you scale down, you say, you know, we really make something very simple with these two systems so that we can manage to get the same API dealing with both systems or the four weeks, which is like same time standing service. Or can you tell us what's, how do you solve the hard problems? So I'm going to pull Jim in here in a minute to talk about maybe one of the examples of hard problems delivery versus payment and some of the thinking that we've been doing now. And I'm not sure that's all written down. Sorry, I was trying to speak on mute. Yeah, let me jump in here. So, Angel, I think there's definitely a very in-depth discussion that needs to happen of how we create the fabric-based plugins for FarFlight and why that should happen for what kind of use cases. Because so far the problem we're trying to solve is on a blockchain that's designed for a uniform kind of notes that where all transactions are sent to everybody, such as Ethereum, how would this work? So the value of FarFlight is very clear there. But with Fabric, you guys sort of were trying to solve some of these problems with channels. And in fact, when we worked on quarter extensions for FarFlight, we sort of encountered the similar, very similar issues. Like the blockchain is trying to solve some of these issues as well. So how do we unify these two things? So, Angel, unfortunately, I'm in the hospital and the doctor is here. I need to talk to the doctor. So maybe we can take this discussion offline and really looking forward to talking with you on that. I definitely would appreciate it. And also more than even if you can in the proposal itself, if you can fill it with examples that really address clear statements of the problem solved and the solution to the problem, at least for me. Just so everyone knows I come from research, so maybe I'm very, I'm very, I mean, this mindset, I want to see the problem and the solution clearly stated, but definitely I would love to talk more about this. I do think there's a higher level point here as well. In the blockchain space, we often think very inside out. We think about the depth of the sophistication of the problems that we can solve using on-chain approaches. In an enterprise context, the majority of the projects, the majority of the engineering time, the majority of the coordination between the parties, tends to be building the business use case and integrating to core systems. And it's in the case where you're using an amazing piece of value that blockchain brought, I've lived messaging the whole of my career and there was this massive problem that could never be solved in multi-pilot systems with just messaging to each other. So I think we can solve universal sequencing. If you've got a technology that has that magic bullet that integration systems have never had before, and you can use it to solve the magic bullet of being able to have a great sequence of events, never being possible with pre-priority blockchain. And you've also got the magic bullet of fungible and non-fungible tokens there. We've given people a tool in the blockchain space that allows them to build applications extremely quickly. Now, it has not yet unlocked the full power. There are hundreds of other things that you should be able to do with blockchains, automatically swap assets, manage delivery versus payments, lots of other things which don't get sticky with the data scenarios that really are extremely powerful and we're not suggesting that in the current state of Firefly that we've written what the interface is, not the implementations, because it's not about the implementations, the implementations for interop, the implementations for bridges, the implementations for on-chain logic, the implementations for TEs. Firefly isn't about those. But we also profess to have written the interfaces for what do the inputs and outputs look like of those LEGO bricks, right? We're starting with the basic LEGO bricks in the box for Firefly. The ones that you can't build any application in the enterprise space unless you can do these really basic things. And particularly, thinking outside in, when we say application, what do we mean? We mean somebody who's used to writing in full stack applications in Node.js or in Java spring boots, trying to build a business API and trying to build a user experience to show business value as part of a business network that's got a certain amount of investment that has to show results in a certain period of time and trying to make it so that that organization can be really successful, that group of organizations can be really successful and arm gated all the time on just the one or two people in that very big sort of development community of that ecosystem that all of the parties trying to integrate their core systems with that, on the one person who understands how the inside of the smart contract works. And I'm sorry for waffling on a bit about sort of the ethos a bit of the project but I wanted to make that clear because it is very different to a lot of projects in the blockchain space and it's not trying to solve one really gnarly internal problem. What it's trying to do is take the patterns of the problems we see enterprises trying to use blockchain for and make it 10 or 100 times easier for non-blockchain developers to build apps on top of that and integrate with it. All right, thank you Peter. And I will add to that, you know that there are a lot of people still missing composer. I mean composer had this nice feature that it was very close to the business developer you know kind of person with a much higher level abstract model which you know some people were criticizing because it was hiding the blockchain and I see Firefly a bit at the same level and I saw Gary's message to the mailing list to say, I think this is the kind of project we need and I also feel a bit that way in the sense that I think this is an opportunity to move up the stack at a very different level and do something quite new in hypernetrics. So with that said, we have people on the queue. Arun, you're next. Thanks Arun. Hi Jim. Hi Peter. So I have a few questions right? So I know you tried to answer them on the proposal sheet as well but few of them are still not clear. So like for example I mean I understand that Firefly has an external mechanism for multi-party systems to exchange messages which is not relying on blockchain and rather use blockchain for finality purpose over there and also making sure that we have sequencing ordered through blockchain for these external messages exchanged. I mean this external messaging could be used for any purpose for file exchange or for coordinating different events which is happening outside. So what I don't understand over there is why is there a need of consensus over there because we eventually should be relying on blockchain and when I asked the question it was also told that we are still using blockchain but what I didn't understand is the use of word consensus over there and there are a few other missing points probably I don't know maybe we haven't used this framework or haven't seen it working in real so that could be the missing gap and it would be helpful if you can show us an example or maybe walk through one more time this framework if possible. So I think Peter is probably in the best position to do that I just want to add a quick comment about this sorry for jumping in here and I think this is tied to your question everyone but also Andrew's think about a scenario where the data just doesn't fit on chain even for a blockchain protocol that supports bilateral communications like Korda and or a channel that's created between two parties with fabric the data maybe it's because regulations or just because the sheer size of the data doesn't fit on chain so you need to keep it off chain and then how do you keep it in sync with on chain ordering so that's a sort of a primary kind of use case we're trying to solve here I'll leave the rest for you I understand so one thing which I found in the repository maybe I have not completely explored this repository within the Kaleido Ivo organization but what I observe is this tend to become a use case specific connectors for example I need to have my own connector or some kind of smart contract implementation for a specific scenario is that how the project is intended to grow further you think about how most infrastructure technologies that people just rely on they just work as developers databases being a great example existing messaging systems being a great example there were patterns which everyone just expects to work you expect to be able to create retrieve, update and delete in a database you want to do something a little bit more sophisticated than that then you may have to choose a particular database which is really good at doing it so that might be a choice of plugging into Firefly a fabric, a blockchain or an Ethereum blockchain that might be a choice of is my messaging technology going to be active NQ is my messaging technology going to be just simple HTTP you make those kinds of choices in databases am I going to use CouchDB or am I going to use Postgres so that's one sort of choice that Firefly tries to really embrace and then once you've chosen that particular technology exactly the same for databases in an application most of the time you're just doing very straightforward things in the application you're expecting to be able to access the data you're expecting to be able to do create retrieve and update, delete etc sometimes you need to do one of these special operations you need to be able to do that that custom item you need to be able to invoke it you need it to kind of be able to talk to it now we're in the Ethereum space and I guess we come a little bit back to eConnect the we did a whole bunch of work to make it super simple to be able to invoke any custom logic that anybody's written on-chain through a West API and event system but is great for developers right we haven't done all of that for Fabrec and Corde yet but it fits the model of Firefly to be able to do that and at that point if you could still say we've got lots of this custom logic we've got the on-chain specialised custom logic that's been built for this particular use case for everyone's doing today building custom logic for their use case but we can still those special team of crack professionals who are worrying about the internals of the blockchain interface can still make their smart contracts accessible to the person building the mobile app to the person building the UI the person in 10 different organisations trying to integrate with their core systems because it's got a really straightforward West API and it's got a really straightforward set of events and that ecosystem in a multi-party ecosystem is going to be using off-chain data as well it's just a certainty like it's I don't know how many nines you get to in the percentage between 99 and 100 before you're there an enterprise multi-party network is going to have some private data exchange so if you're building one of these networks you're going to make some technology choices on how do I build my private data network as well as how do I build my on-chain data network so when somebody comes and they want to onboard to your business network you're building the one for insurance or supply chain or finance or whatever you're building that and you've got these 20 different enterprise organisations that need to integrate with you what's the interface that you give them to integrate with that business network considering it's going to include custom on-chain logic, standardised on-chain logic, off-chain logic maybe trusted compute and others how do the poor developers and integrators actually get to that system that's really what Firefly is trying to solve just to round out your metaphor there I guess you're saying like a database the CRUD operations Firefly kind of has those in the box for the popular blockchain technologies but the stored procedures those custom logic is a big fancy smart contract or chain code and you can definitely still do those and incorporate those into the larger application that you're building and maybe some of the development of those smart contracts can be aided by the Firefly framework so if you have a smart contract that is sophisticated but could do with some coordination of on-chain and off-chain well maybe you've actually got a framework within which that's actually easier for that smart contract metaphor as well all right thank you guys Maria Teresa has been waiting for a while please hi guys first of all sorry because I was late in the meeting I have been reviewing the the document of the proposal and it doesn't it isn't clear to me how do you manage the identities because at the end you are going to use several blockchains and each blockchain has their own method to manage the transactions the identities that are same in the transactions so what is your plan about manage the identity in the project because at the end you are going to have if you are using Hyperlayer Fabric you have to use the identity of Hyperlayer Fabric in the case of so at the end the final users are going to be the users that have the identity that can work with many blockchains or is the own Hyperlayer Firefly the part of the solution that is going to manage the transaction to the users all right thank you Peter should I take this one or maybe I can go first yeah I'll go first that's a good question so Troy also brought this up on last week's call when we first introduced Firefly so identity is a core piece of Firefly Core and it's a pluggable and we define two kinds of identities and foremost is the organizational identities each member of Firefly framework representing a consortium member on the organizational level needs to register themselves so that's a verifiable identity on the organizational level and we are going to provide implementations for this plugin interface so that the identity can be at least verifiable within the consortium so you can think of using an Ethereum smart contract to manage the registry or even just use your own database to manage the registry so that everybody knows who they're talking to through a registered public key or X-File and I certificates so that sort of takes care of the signatures but then on the each instance of Firefly when every member deploys that they're going to have applications attached to that so there's going to be user level identities within the realm of every member home directory so that's going to be managed by each member and I believe Peter we're going to provide at least a sample of using open-source systems like a key cloak to make that work so at least for the getting started package you can see this thing working end to end and Troy and I have been conversations offline throughout this week talking about some of the DID based plugins that we could create on this interface and one of the real reasons why we want to be in a community where we can have the contribution can be wider to make sure that we're addressing a wider areas of the problems that we haven't come across yet so I'm just on top of everything that Jim said we're focused right now on the identities being backed at the moment by core blockchain signing identities so right now where you look at the state of the project codes you'll find it's assuming identity is established by signing transactions at the blockchain layer that's where it comes down to at the core and the plugin interface is able to deal with all the different blockchains way of representing that identity so we just have to make a choice but it's not yet got to the sophistication of plugging in an identity framework or DID framework etc and I think that's a great evolution that would be fantastic to happen inside of Firefly and I guess I can't remember who it was at one point someone sort of said this idea of an umbrella like a way to allow this great engineering that's happening in lots of specialized spaces to be able to kind of link together and collaborate together and deliver that like make it easier to be consumed because you can consume things together but that's one of the goals and one of the real reasons to pushing for a really open approach to a community developed project is to be able to plug those things in not because Collido fought with the Monday one but because the community evolves and gets the value and can plug in those frameworks and there will really need to be the scrutiny on whether the plugin points are the right shape to allow that flexibility and that's going to evolve and we hope that evolves not just in the weeks before project approval but that's what the incubation phase is for us is trying to evolve those frameworks make it so that together we're able to plug in more of these projects it's not just the blockchain projects that can plug in core blockchain it's not just the core data storage projects like IPFS that can plug in it's not just the core messaging projects like Kafka but also all of the you know the entrap projects the swapping projects the the off-chain compute projects the collaboration is on the plugin points to make it extensible that's the thing that matters the most I think about Firefly as it above us Alright thank you Arun we need to keep short because we are quickly running out of time the agenda I don't think any of the rest is really time sensitive so but please try to keep your answers so Arun Thanks Arun I'll make my question short so this question my question is coming towards from the projects charter perspective because this project talks about a lot of connectors which we are dealing with and plugins and interfaces and we are also we are also talking about multiple frameworks or underlying protocols being supported through this Firefly project right so the closest project which I can currently correlate with within Hyperledger which deals across multiple layers with within the application stack is grid project and so I mean grid has different scope where it is completely focused on solving supply chain related use cases so it has specialized smart contracts but when it comes to the application stack site it does have its own way of reading from the ledger and storing it to external database or probably those API kind of connectors which you are talking about right a while ago Peter so but that project has I mean for that specific project to work with other protocols the requirement has now changed a library dependency which unless other protocols support that library so grid won't be supported on those protocols so mapping that kind of just trying to understand the project's charter from that perspective because we will eventually not have a similar interface or we may not even have a single working model for all the protocols right so is that fine with I mean is that how Firefly is intended to work with so we may have a Firefly module could be same it could be doing same thing but we will have its own way of working for different protocols is that correct understanding quite hard to keep my answer short here it's a microservices plugin model not a library plugin model there's a little bit of complexity because of go but the intention is and it's already true for things like Corder where the only way to integrate the Corder is in Java you need separate run times that form part of the plugin and there's a lot of thought that's gone into that plugin interface we'd love to hear feedback on it but the intention is that it is extensible it's not that much that you aren't forced to sort of rewrite your tool and go just because you want to plug into Firefly all right we have few minutes left I'll go back to Angelou and then we'll have two problems very quickly thanks I want to say thanks to Jim because I understood this problem so the problem of leaving hashes on the ledger and then synchronizing the node the private information that we have to solve we solve also in fabric with the private data collections that's a clear problem thank you if you can write down in the proposal more of these problems and then you tell us how these problems solved together can address the use cases I think it's perfect just a small detail for Peter Peter it's more from my personal point of view it's more than connecting building blocks because if you don't connect building blocks in the proper way the integrity of the ledger the security of your system will just collapse completely so it's more about it's more than just the engineering part that definitely needs to be solved at the end but before we need the theory to understand how components can speak to each other without adding the integrity of the ledger collapsing thank you all right thank you any quick feedback on that yeah appreciate the comments Angel I think once we join the bigger family here we can definitely utilize the expertise on distributed compute and crypto like you guys so we can make the system stronger so far we are pretty confident with the security of the current design because as we mentioned earlier we do continue to rely on the blockchain itself to solve the hardest problem the ordering the identities and the point of the rest of the components we're building into Firefly is to sort of build the superstructure on top of that core to make building applications easier those are the problems that every application developer will have to solve and we're capturing those as patterns into Firefly to make that simpler but I think the core, the hard problems in terms of security cryptography consistency those still lie within the blockchain layer and I don't believe Firefly itself is creating new challenges for those but we're certainly happy to continue to discuss with you guys to make sure it's robust all right thank you Jim absolutely we're out of time so we're going to leave it at this for today I would really encourage people everybody to try to make progress on asking questions and answering them getting them answered offline in between calls because we just don't have enough time to go through everything I also would like to encourage the collider team to take into account all the questions that have been raised and look at the proposal and see where they can insert additional content that would address the questions even if you feel like okay we've answered them on the call but there are people who have not been on the call and in the future they might still look at the proposal have the same questions so I think it's a good exercise to go and improve on the proposal to address the questions such as the one that was raised on identity or the interoperability aspect and that kind of stuff it's worth improving the proposal so with that said I'm going to close the call on this I want to thank you all for joining good discussion hopefully we can make progress again next week and in between