 Thank you. Hello, everyone, welcome to the weekly TST call. As everybody knows, I think, this is a public meeting. Everybody is welcome to join and contribute. There are two requirements to doing so, though. The first one is to be aware and live by the antitrust policy, the notice of which is currently displayed on your screen. And the other piece is the code of conduct, which is linked from the agenda as well. And we basically ask you to behave. All right. With that taken care of, we can go ahead and start with the announcements. We have a whole bunch of them, but for the most part, these are just reminders. There is the weekly developer newsletter. Please do think about what's going on in your project and think about whether there's anything that you could highlight and contribute to the newsletter. We have the global forum going on. I mean, the registration is still ongoing. It's coming up. It's heating up. There are new announcements of new speakers and keynotes going on. I do recommend that you register if you haven't done so yet. And, and socialize it within your networks. So that everybody is aware. Helen, you won't talk about the white paper greenhouse update. Yeah, I just wanted to remind everybody that this task force, which is still open to new members. So please feel free to join us. If you haven't joined us in previous meetings, that doesn't preclude you from joining some future meetings, but that will be on Friday. We'll be back tomorrow at 10 a.m. Eastern. There's the wiki there. And we have lots of interesting things to talk about. And it seems that this tax force is charged with numerous projects. So we'd absolutely love kind of more hands on deck there. And we're making good progress. So please join us. Thank you. And as I mentioned last week, there is going to be tough interest in the blockchain interoperability and new work. I mean, there's a discussion that has been moved now to the architecture working group, which has kind of woken up for the occasion. And so there's actually a email thread now going on and anybody. And I suspect at some point we'll probably have some calls. And so there are actually no fewer than basically three different approaches being, you know, considered within hyperledger alone. And so we're trying to focus for now on understanding the ins and outs of each approach, how they compare. They all seem to address the same use cases, but in different ways. So the primary goal is to understand how the different approaches compare and or not. So again, if you have any interest in this, subscribe to the architecture working group mailing list, because this is where it's happening for now. And then likewise, there's a renewed effort to relaunch the performance and scale working group. I think there's actually a call being scheduled now. I meant to change the link. But anyway, if you follow the link, there's discussion on what they are going to do. And again, if you have interest in this, I encourage you to follow the link and consider joining. Is there any other announcements anyone anyone wants to make? Okay. I'm not. All right. When it comes to quarterly reports. I'm not going to go into detail. So Explorer and D had been around. They were already submitted the week before. I just put them, carry them over in case anybody had any questions. I didn't see anything on the wiki. The new report we received is from the Roja. I don't know if there's any questions. I actually asked a question because they put, and I didn't think I got any answers. Anybody from the Roja team on the call. Yep. So, do you know? Because so I think it's Sarah submitted the report and she talked about how there were some issues with DCO issues that are not being caught up that have now been surfaced in the process of moving from master branch to main branch. Yeah, indeed. We had several problems there. Like, yeah, we have in main everything looks okay, but you will have a deaf branch and we had to force push it several times in order to fix DCO's and see and still it's, yeah, it's kind of painful to do it every time as we have several protocols opened and whenever we force push, yeah, the guys need to gain to rebase or take the latest version of deaf branch. But yeah, whenever we think we fixed everything related to DCO, like fix the messages in commits, then, yeah, we figure out that, well, that another commits remain that we still need to fix DCO. However, it's kind of not obvious what exactly commits we need to fix because there is a message in GitHub that suggests like which commits have broken DCO's, we fix them, but then it finds another commits. So yeah, that thing becomes a little bit problematic there. So I see that Sarah actually responded to my question on the wiki page at the end there. I see there's a few hours ago and I have to admit I don't understand the issue with the way she presented. She's expected. Kulvadini is something at ukr.net, but we got even Kulvadini K star star at Sora Mitsubi. What's the issue there? Yeah, the issue is there is not clear how the DCO both decide what is expected as an email there. I think it's the get author. I have to go and absolutely look at the code, but I'm pretty sure if you, if you look at the author of the commit, that's the one that expects to sign off from. And there is a tool that we have that John Marduk wrote, and I don't have it at hand. I'll send something to the TSC mailing list that does make this a little bit easier in terms of finding out exactly which commits are broken. Yes, I think we use that tool and well it also, I don't know, probably the issue is somewhere in DCO because I think we use that tool and it actually showed some commits that actually were committed like several years ago, but before we actually used that tool, we didn't even know that such commit exists because DCO bot didn't show any error there. Probably that also because that commit several years ago was from the Panda bot, so maybe it didn't, I don't know, maybe it doesn't use properly for the bots. But anyway, yes, that thing really becomes a little bit annoying and a little bit slows down development as we need to constantly like checking. Well, we see that DCO is not passing, then we need to force push the dev branch, then we need to again, there based our existing requests. Yeah, that thing, yeah, it's not very nice for us. Well, the DCO check is an ongoing issue. We have an open issue on that very subject, actually, or two. So I don't know. I mean, can we follow up with on this right and try to understand if there's anything that can be done to ease the pain? Sure, I'll take it up offline. All right, thank you. Thank you. Thank you, Kevin. All right, so we are missing just so you know, I mean, we're still missing a report from Aries, but I suspect they just have not realized. And if anybody's in touch, please let them know, somebody like Nathan maybe can ping them. All right. But I think that's all. Any other questions on any of the reports or your Roja in particular, which is the new one. Okay, hearing none. I assume we're good to go. All right, so let's move on to the main part of the agenda for today then. So as you must have seen, we received, we have received from the Kelly, the company, a proposal to launch a new hyperledger project called Firefly, which is based on some work they have been doing for quite a few years. And so I said, well, we don't really have anything pressing on the to put on the agenda. So I invited them to present to us today. I don't expect us to make a decision yet to answer, you know, Tracy's point. I mean, that would be rushing for sure. But I figured we could give them some time to present the proposal, explain a little bit what this is about. And hopefully, you know, people will get a better understanding of what the, this project is about and have a chance to ask questions. And then we can let that sit, you know, for a week or two and then look at it again, make a decision based on the, you know, we'll see. I mean, if people have more questions, they can be asked offline as well in between. So with that said, I'm going to turn to the Kaleido team. We have several people. I don't know, Jim, Steve, who is going to take the lead. One of you was to present. You would like to present. Yeah. Steve, Steve will present. Thanks. We've got. We've got some, a number of the Kaleido team is on as a guest this morning. So thank you for letting us come and walk you through Firefly. I'm going to. The guidance I received was to spend about 20 minutes on this walkthrough and then leave plenty of time for discussion in Q&A. So please hold me to that. I'll step through it. I created this exact summary just to make a few key points and then I'll step through the story very quickly. But Firefly, you know, we see as a larger system around a blockchain and I'll describe that in greater detail of going forward. So it's not a new blockchain protocol. It's not, you know, replacing a blockchain protocol. It's not an interop project. I know you were talking about those a few minutes ago. We see it as being very complimentary to all of those things. It's a, it's a larger sort of coordination system. And the idea is to take the plumbing out of building an enterprise blockchain. So there are a mix of technologies in a very. Plugable by design. Art system architecture. And we really feel like hyper ledger is the right place for Firefly to be it. It's a large, fairly ambitious project. It's really aimed squarely at the enterprise blockchain community and space. It complements many existing hyper ledger projects. And in fact, you know, fabric, basu from day one will, will be, you know, supported as, as the underlying blockchain runtime that's used by, by Firefly nodes. Things like interop, et cetera, will also, you know, very logically and easily map into Firefly as well. And we see keys to success of really building properly. Through an open governance structure, gaining broad participation, allowing the market to drive the evolution of Firefly. We recognize there are many promising emerging technologies. And, and we think of Firefly as sort of a larger system, a coordination system, you know, allowing the market and the community to drive that and contribute to that are going to be keys to its success going forward. As Arno alluded to, we're not starting from scratch here. You know, the seed contribution will be mostly private code from Kaleido, but it does represent several years of active engineering. There's production code. There are very large companies, some of whom are hyper ledger members are running on this, relying on this code. And we ourselves, or the founders of Kaleido are X IBM, some of you know that, some of you may not. And we've been in the blockchain space for six years now, hard to believe. And, and a really sort of core system back office folks experienced and contributing to enterprise open source and so on. So there's a quick snapshot. I'll sort of end on the timeline, but just jump into the story. I think the bottom line is we, what we see is it's just way too hard still to build out an enterprise blockchain use case. And I'll give you a simple narrative for that. You know, what we see over and over again, like the groundhog day movie is enterprises think the job when they start out on, on building an enterprise blockchain use cases, hey, I'll sort of write some smart contracts or chain code and then I'll start up a node. Maybe build a simple web app and that'll be it. But what we see is they quickly get sucked into a lot of plumbing work and a lot of it's off chain plumbing. There are a set of components like messaging, like document exchange and other things that we see almost every enterprise blockchain project needs. And so as a side effect of trying to build a use case, you find out that you're a plumber and it can really spiral. You know, we, I think we're all familiar with projects that have just gone on into years and they're not even live yet. And it doesn't have to be that way. You know, the, the plumbing can, can be taken out of the equation and we really think that's going to be a huge win for the market to put that in diagram format. You know, this is a, should be a somewhat familiar picture to all of us in an enterprise blockchain network. It doesn't make sense to just decentralize that the blockchain layer, what, what organizations do is, you know, you're really decentralized up the whole stack. So every member is running their own copy of the full application stack. And there are common layers that we know about from other, you know, generations of enterprise IT things like workflow and middleware and, you know, different data, data systems, data components and so on. And so some of, some of this stack needs to connect privately to your own back office. Some of it needs to be network facing. And, you know, there's things like tokens and digital assets and, you know, the immutable ledger, which we know about, but there's also private data exchange and off data, off chain data flows. And often there's broadcast data that you want delivered to all, all members and all that sort of needs to work together critically, crucially, you know, these, these flows all need to work together end to end. When you zoom in on these sorts of layers, you can see, as I was saying, and that prior slide dozens of components. And I won't get in those today, but by sort of overlay this, you know, I'm over generalizing here, right? But the idea that there's lots of open source activity, you know, down towards the bottom of this stack, but as of yet as to our knowledge, there really isn't an open source project that comprehensively tries to tie together some of these other layers in the stack and help, help companies to rationalize that. A quick example. You know, we think a lot about the, the evolution from Docker to Kubernetes. You think about Docker. The promise that it had was that all software could fit into the same box. And this was really powerful, right? Really cool. Think hard things like networking and security and, you know, scalability and failover to solve those sorts of problems once and deploy it to all your software systems is a, was a huge breakthrough. And it worked great on a developer's laptop, right? But how, how could an enterprise go into production on that without something like a control plane? And how could you manage, you know, not one, two, three, but 10, 20, a hundred, 300, a thousand Docker containers, right? You needed a larger system and companies also needed, you know, plugins for some of these other functional pieces around inside alongside underneath of Docker. And that's what Kubernetes brought, we know. And interestingly, Kubernetes sort of helped us realize the initial promise of Docker, right? That all, that all saw the power of all software fitting into the same box. And so in the same vein, we feel like in the enterprise blockchain space, there's this huge promise and it makes sense that we get it, you know, the coordination of a shared ledger and staying in sync and automating around smart contracts or business logic. It's really powerful, but in the same vein companies just really struggled to deploy that, to get into production. And so Firefly we see is that sort of Kubernetes that larger system taking some of the design principles like being very pluggable and extensible, we think is really appropriate in this space. We are using the term multi-party system. I know some folks have heard that or familiar with it. It's, you know, sort of something else that's complimentary and additive to a blockchain protocol. And, you know, as I said before, we could see a number of hyper ledger projects, you know, present and emerging and future that could really fit in and compliment to, to what Firefly is trying to do to get, get enterprises out of plumbing, right? The plumbing bits are solved. You get a really nice simple programming model to build to, you know, these components are fit together. They work together end to end and things like network management that really needs to span across on-chain and off-chain. There are, you know, new tools to help with that as well. And I know, you know, the goal wasn't really to get into the technical detail. We're happy to do that a bit in the Q&A and also offline and follow-ups and follow-on discussions. But just to give you a sense, you know, of these layers, the core is really the brain that sits alongside your application and gives you those really simple, clean APIs to work against. Then we have sort of a loose coupling philosophy where connectors can be plugged in and utilities like, you know, blockchain protocols themselves can all run. And the idea is, as a real quick aside, that, again, these are very plug-able. You know, anyone could pick up and build, you know, an agent or a connector. And with just implementing a thin shim can plug that into Firefly. We're not even opinionated on things like transport. And so just a couple more points and then we'll transition to the discussion. We mentioned plug-able. Well, that includes the blockchain protocol itself. You know, day one principle, we want to be multi-protocol within the Firefly node, you know, starting up, you know, one of these protocols, there's a lot of IP that's being contributed around this to make this possible. You know, when I said Clado's years into this, you know, as you guys know, these protocols are quite different. And we can go into great detail on how we're doing this. I will note that we have clients that are running across all of these protocols today on fundamentally the Firefly stack. You know, really leveraging blockchain for what it's great at, things that we know sound boring, but are really important, like global ordering and finality. And then building upon some of those, you know, data immulability techniques like hash pinning, you know, tokens, et cetera, all of that goodness from the blockchain being there, but building on that to further simplify and also to, you know, unify off-chain and on-chain aspects. And so that's what Firefly's doing. Do you want to, you know, just double emphasize the importance of the hyperledger community being really enterprise-ready, enterprise-friendly open source, clean licenses, open governance, very pluggable, open for contributions, steering, et cetera, and absolutely enterprise-grade ready for production. There is a UI that comes with this just to give you guys a snapshot of that as it's emerging. And finally, just a little bit of detail on, you know, the evolution within Kaleido. We started building, you know, these capabilities as what we thought of as individual plug-and-play services that a customer could kind of take and compose together to build their application. As we built, you know, as we ourselves helped our customers to build their solutions, we really saw the same services used in the same combinations and the same patterns regardless of the industry. And out of that emerged, you know, the first version of what I'll call the brain, you know, that core that really helps and simplifies the orchestration of all of that, we had called that Kaleido asset trail. And again, that was built as a closed source, you know, proprietary thing. And now we're really excited to propose the next evolution of that, which is to, you know, take this opportunity to really refactor it, to, you know, evolve it into a top grade enterprise, you know, system where we think the space really goes, is going and what it needs to really design, take a fresh opportunity and design from the top down, things like that you'd expect out of an open source project, like that there's a nice five to 10 minute quick start download runs on your laptop, get going, you know, quickly, but there's also a path there for a robust enterprise deployment. And there's a little bit of detail around that. And so that's what we're sort of right at this point and excited to make the jump. Quickly on the timeline, this is our proposal. You know, it's of course open to everyone's input here and feedback, but we're here at the early part of May and with the proposal in hand, I know we've been discussing this with a few folks in and around the community for quite a while. The code is available and ready for review. We'd like your input on how best to get, you know, all the folks that want to look at that. Very much appreciate all the feedback that's been pouring in over the last couple of days on the proposal itself and look forward to continuing that. If we're in a place for it, we'd really like to aim for a vote from the TSE by the end of the month. In particular, just because the hope of hyperledgic global forums around the corner and getting the word out on this community would be a great opportunity to do that. As you guys know, that's June 8th to 10th. And then we're planning some sort of intensive activities and workshops today after the event on the 11th and we're working with Brian and Daniela to, you know, plan for how to socialize that. So I promised 20 minutes. I think I'm pretty close. And I'll stop there and open it up for questions and comments. Yeah, I didn't mean to rush you that much. You actually took only 50 minutes. So yeah, if there's anything else, I'm going to add extra cup of coffee this morning, I guess. That's all right. One comment. I mean, I saw some of your slides with the tag collido confidential. This is a public meeting with the public record. So those are no longer confidential if they were ever meant to be, you know, just so you know, I assume it's just left over. Yeah, it is. We'll get that cleaned up. And there are people who actually have asked how to ask on the, we have a chat on the rocket chat. We use and how to ask if the slides would be made public. Can you make this deck available? Yes. Yes. We're happy to do that. And if you give us advice on how best to do that. Yeah, I would just. I would ask you to. They are sitting in a hyper ledger. Um, shared drive on Google drive. And so we can certainly add everyone on the TSC, but if there's some other wiki or someplace to put these, we're happy to do that as well. Yeah. I would just. I would ask you to, uh, Sure. Yeah. All right. I had one question to get us started. I'll abuse my previous chair to ask the first question on the technical level. So in a sense, you actually end up with two different networks, right? There's the firefly network with the firefly nodes talking to one another, which basically relies on a different network, which is really the blockchain network, the fabric order or some ether network. To, to, as you say, pin some of the transactions and data to that. Is that correct? I wonder, maybe I could take that one. This is Peter protest here. Um, uh, the, the reality that we see from production blockchain deployments today, like, um, not just the ones that we're involved in, but you just look at the space is that, um, it's almost universal that there are multiple connectivity networks going on that the blockchain is one way, one way that the members are talking to each other, but almost certainly there's other pipes. There's, um, things like IPFS, um, or some other way of broadcasting data. There's things like, um, messaging pipes, managed file transfer, um, you know, maybe it's, maybe it's an MQP provider like Revit MQ or, or, or, or another. And, um, firefly doesn't propose changing that status quo. That is the status quo. Um, but it does propose making the life of the developer living with that reality radically simpler. Instead of that developer having to become an expert in messaging and an expert in fabric or Ethereum or quarter and an expert in, um, uh, in all of the complexities that come with this sort of multi-party system design that's so different to what they do for web and mobile development, um, to date. But what they get is, as a developer is a unified API with things that make sense to them, things that are easy to understand. If you're used to using all of the other APIs that, that you're used to using, you used to use using, you know, infrastructure services and the like. Think of the difference between, in a database today, what most people are asked to do for blockchain is like writing store procedures in the database. You, you have to understand how it works internally. You have to really become very involved. Um, but that's not the way any web, modern web developer develops against the database today. They just use SQL or something even simpler than SQL on top of that. Or even a no, no SQL interface that's just designed and built for them to get their job done and not worry about what's happening inside of the plumbing. And that's what Firefly intends to do. So yes, the Firefly, the Firefly nodes, like any enterprise application in the job, blockchain space are connected together through the network. And yes, the network includes blockchain communications as well as non-blockchain communications. All Firefly has done is made that building the actual business API in the business UI, much, much simpler by unifying them under, under a common API and then encoding the patterns that are really common. And we started with some patterns that we just see day in, day out in production projects, like transferring your data off chain and pinning it, like coordinating really complicated business flows, but you couldn't coordinate before using blockchain to sequence the steps that different parties are taking, like NFTs and tokens. So, so those patterns can just become, you know, API constructs, like you'd expect and, you know, create retrieve updates and delete for a database. Well, what are those constructs for, for blockchain? It's trying to actually encapsulate those and make them easier to understand as a developer. All right, thank you. I also wanted to make one observation I meant to actually say before is that you guys refer to multi-party system, which interestingly enough has been a point of discussion in Hyperledger where in a recent member summit, you know, there was a recommendation from the members that maybe the charter of Hyperledger should be extended if needed, because when we looked at it, it wasn't even clear that we actually need to do an extension, but, you know, maybe make it clear that it could be extended to multi-party systems beyond maybe the pure what might, some people might think of a pure blockchain. So I just wanted to say that it's, you know, it's not a foreign concept to this crowd. It shouldn't be a test. So with that said, maybe we can echo one more thing. And before I turn to the rest of the TSE, you know, one of Tracy's questions, or I should say a series of questions, she seemed to be keen on a better understanding, you know, what exactly you guys were planning to contribute, which I think is, you know, is in part at least motivated by the fact that we understand that this comes from close source. It's basically your assets that you guys are built a business on top of. And the question is how much are you going to contribute? Am I going to have a system that I can really use? Steve, shall I start on that one? Yeah, please. So, yes, a system that you can, you can use the system you can use in minutes and you can see a path through to production. That's what success looks like for this project. And that does mean there's a lot of, you know, there is extra engineering that we're doing to decouple the latest generation of the Firefly Brain from the types of services that you would use if you were, you know, you're deploying to the colloidal. Then, you know, we've got the off-chain messaging buff. We've got the, you know, we've got the peer-to-peer messaging system when we've particularly chosen IPFS there. We've got all the three blockchains. They're all there, right? And obviously being able to deploy Firefly apps against colloidal is something that we really care about making a brilliant experience. But the open source project is not an open source project in our minds, unless it is self-sufficient and pluggable. So there's actually four repos that are sort of constitute the, you know, the initial contribution. But they are likely over the coming couple of weeks, even a couple more repos that will come as well. And that's Firefly, which is the Firefly core. And I don't know if it's maybe useful for me just to share my screen briefly as I'm talking about this. So you can see what you will be able to see. Hopefully you can see my screen now. So this is the Firefly core repo. And you'll see it talks about that there's actually two generations of the technology inside of here. There's the current generation, which is a go code base, a built for community, pluggable code base. But it's also along the journey picked up a lot of, you know, improvements that are from feedback from developers who've been running projects on this over a long period of time. So that's the current generation. And then inside of here as well, we've also, we're also sharing the complete code, which is being used in a number of production projects of the more coupled to collider original version, which happened to be type scripts for that original version. So that all of that is there as well as a reference as a starting point. So we really are sort of bringing that history with the project to be able to help people understand the evolution. And then the project itself for the current generation in go, this is a sort of view of the sophistication component layout. So, you know, an API server and everything you'd expect with open ID generation and WebSockets interface for applications to have an event connection as well as an API. And then a whole bunch of internal components, which are the heavy lifting of the engine, including batch performance, optimization that we've worked a lot on over time, core concepts like broadcasting or sending data management, privacy management, the sophistication, really hard bit the plumbing of the aggregation that's needed when everything arrives at different times. And it needs to be brought together, managing subscriptions and dispatch as well as the registry that's deployed. That's the core sort of engine, but that doesn't include any actual persistence or infrastructure. Those pieces are all pluggable. So the code is pluggable in its DNA, it's pluggable. So the blockchain, none of that code above, knows about a particular blockchain. All of that is pluggable. There's even a fake blockchain thrown in to help with unit testing. Although the local developer experience does use, does use Ethereum by default. P2P file system, we built on IPFS, but that again is made pluggable. So you want to put in swarm or et cetera, then you can just plug that in. Data exchange, the off-chain transfer of data. Well, colloid has got a lot of sophistication there, but we, and this is still work in progress where we have a completely self-sufficient way of building a decentralized network that allows the data exchange to work. And like most of the existing sort of projects in this space, whether it's the Tesla evolution, that's part of the BESU project or et cetera, but actually all of these applications, all of these instances can just talk directly to each other, but that's just a pluggable implementation. And then even the core database itself is pluggable. So both SQL, but it's extensible beyond SQL as well. So for performance reasons or which query reasons you could even plug in additional databases. And then the core code base as well is designed with enterprise in mind. So things like standard utility frameworks for rest and web sockets, translation, a very carefully thought through logging framework and a pluggable configuration framework, all the sort of stuff you'd expect from a proper open source project, particularly one that's thinking about an enterprise landscape. And then in addition to that, you've then got the CLI project, which is like the super simple init, start, stop to show me my logs under the covers using Docker compose, but doing file system management and all the stuff you'd expect just like snap. I've got my own firefly network up and running and I'm developing against it and exploring the API, having that true in a very small number of minutes rather than having to go and make a whole bunch of choices before we can get going with it. The UI, which you saw the screenshots of and that's under really active development at the moment. And then another piece of I guess about 25,000 lines of go code that's evolved throughout Kaleidos journey is sort of under this umbrella. And this is one of three of these such plugins, which is a blockchain plugin. So this project started well, very early on in Kaleidos history. It's two and a half years ago now, which was building REST APIs and the streaming of transactions onto the blockchain and the detection of events off of the blockchain. So that project is sort of separate, pluggable components, but also necessary to be able to have something like firefly plug in. So that's sort of remote agent or connector. And that's, we have the quarter one, although the open sourcing of that will just won't be today for the team. And Jim Zhang, who I'm sure a number of you know from previous lives is leading the completion of the fabric plugin for this as well. So that's the sort of landscape of the attack that will be there. And these four repos are the ones that you'd have access to as soon as we work out the right way to do that access today. All right. Thank you, Peter. I mean, yeah, people are eager, you know, at the end of the day, most of us are developers and they want to see the code. So even though we don't have time to go very deep into the details here, it'd be good to give people access. Are there any questions otherwise from the TSC members specifically, but anyone for that matter? I saw Daniel raise some concerns with regard to the timeline. Obviously, we can't commit. I understand the appeal right from the collider team to want to grab the opportunity of the global forum as a way to advertise this project. But I mean, we're not bound to this. I think it'd be good to do if we can. But we'll take the time to text. But are there any other questions from the TSC members? Yeah, try here. One question that I have is, is there out of the box blockchain functionality that you're putting in from the sounds of it? It sounds like one of the main uses of the blockchain in this proposal is effectively event ordering and getting off. Off chain objects to that ordering. Is your thought that is primarily out of the box chain code like in fabric terms, or how do you deal with somebody adding like custom blockchain logic across different blockchains? So I'm just trying to see, do you mostly see this as a prebuilt objects that you yourself put onto the chain in terms of code? Or do you really think there's plugability? I guess. I'll start, and I'm sure Jim will contribute here as well. The reality is that blockchain, the blockchain space can't go as fast as it needs to. If the only people who can develop against it are those that are willing to invest in becoming that deep specialist in working the on chain contracts. So we do think, you know, that the philosophy of the of the far from my project is that you can be a web developer, you can be a business API developer, you can live in typescripts or beautiful mobile APIs, and this projects for you. And there's no barrier to getting starters. And that that means that, yes, having plugable, the patterns of blockchain becoming plugable. And we have had to sort of start one that didn't seem to be standardized around sequencing and ordering and multi-party business processes. But we're also expecting to be able to encapsulate everything that's already been done by communities like Tried by Fire, Ethereum, ERC 20s and 720 ones can be in that bucket of pre-existing on-chain logic as well. That said, if there isn't the escape valve to be able to use your own on-chain logic, if there isn't the, you know, the stored procedures of databases, then the project also hasn't met its goals from our perspective. So it's a mix of the two, but we really do hope that blockchain can get that massive adoption boost that will come when it's possible to do a serious business value without leading to, you know, white contracts from scratch. All right. I see Brian on the queue to speak. Maybe just to ask it a different way. What I think Troy was asking, and I'm curious about as well, is the intent of Firefly to abstract you entirely away from what's going on at the ledger layer, you know, to not be able to not only not have to write chain code directly, but to not be able to, or is it possible to bring pre-existing smart contract logic, pre-existing, you know, networks that have been launched perhaps purely on fabric or purely on Bezu or Quorum, whatever support you've got. Is it possible to migrate to something like this, or is it really presumed that you're living within Firefly and seek to nuts for the development of the network? It's very much the last of Brian. I don't know. Jim, do you want to talk a bit more about that mix? Yeah, sure, sure. I think this is going to need quite a bit more discussions to properly go through what this looks like compared to my chain code base or smart contract base solution. Fundamentally, at the very basic level of Firefly, we care about two things that are critical to a multi-party system that are fulfilled with blockchain. One is data immutability. The other is global ordering. And we will provide the corresponding on-chain logic to make those true. So chain code and smart contracts and core-dabs will be contributed as part of the code base. But then if your logic requires more on-chain, more sophisticated on-chain logic than ordering and hashing, then you can definitely contribute your own. And as long as you still is compliant to the interface that Firefly requires for the on-chain logic, still preparing those two fundamental capabilities, then the rest of the extensions is your free to add for your applications. I guess I would just add one more thing, sort of zooming back out even a little bit further. Every business application has custom business logic, right? But almost by definition, right? That's what makes it unique. It has unique business logic. And so a core part of Firefly is the idea that that business logic can live in different places. It may be part of your web app, your Node.js app, right? Some business logic is there. Some business logic goes on chain. Some may go in an Avalon trusted execution environment, right? Some may be ZKP based going forward. And so the idea, and some may be low-code, no-code, sort of tools. I think Firefly embraces custom business logic in different places. Some of the core operations, though, and how off-chain and on-chain, we're talking about messages, events, documents, things like that. The connectivity, the sequencing, how those things are reliably delivered back to the application and from party to party across a network. That sort of gorp and that plumbing is really where Firefly intends to step in. And some of that simplification means there are, as Peter and Jim were saying, some base contracts that sort of come in the box. But that's certainly not like a design principle to say, that's it, right? Like that's all there is. It's more of a me too, like an add-on, right? That they're there to handle some really operations that we feel like should be more standard over time. And then absolutely we understand real-world applications have custom business logic in many places. All right, thank you. We're running out of time, but let's go back to the trial. Yeah, I was just going to post a quick comment to the document. I was curious if there's also any design concepts around decentralized identifiers in Firefly. Yeah, at the moment, the identities that are used involved in the multi-party system are only verifiable within the consortium. That's what you get with Firefly, the current contribution. But as Peter was saying repeatedly, this is a pluggable system. So identity itself is pluggable. So if you want to plug in a globally verifiable DID system, then that's absolutely possible. All right, thank you guys. Well, I mean, this is only the beginning of this discussion, obviously. I hope this presentation and Q&A session has helped people at least get the beginning of some better understanding of what this project is about. I invite people to continue the discussion. There are mainly two channels available. The first one is on the proposal itself. As it was pointed out earlier, some people have commented on the proposal using the Google Doc comment feature. That's definitely something that can continue. We also have the TSC mailing list that can be used if people want to post there. I think it's fine as well. And I invite the Polido team to subscribe to the TSC list and be on the lookout for questions and answer. And we will continue the discussion. We'll see where, you know, that leaves us within a week, maybe two weeks, see if we can make a decision or if people feel like they need more time. We'll play by ear. Okay. Excellent. Well, thank you all. As we started this up, maybe you'll end it and say, thank you all again for the curiosity for the questions. And we look forward to continued discussion. I mean, we also just make ourselves available if you want 30 minutes, you know, one-on-one to go deep or anything like that. You know, we're available. All right. Well, thank you guys. And for the rest of the TSC just quickly before I close the call, I wanted to highlight the issue that I put on the agenda at the end, knowing that we might not have time to get into it. And I don't actually expect us to have a full discussion on this now. I just wanted to raise, you know, people's awareness. The situation we have right now with regard to the implementation of a decision to have a common repository and specifically, you know, using the repo linter tool is kind of bogus in the sense that if you look at the resolution, it actually direct people to copy the repo lint json file into each repo, which we've agreed is the wrong thing to do because it's going to be a Metna's nightmare. There are some challenges in using a common configuration for everybody. So in recognition of that, I think we can find some kind of middle ground, but I do think we need to fix the record because as it stands, we are asking people to do the wrong thing. So we will leave it at this for today, but I do want us to, you know, get to that and fix it. So with that, I think we can close the call with actually one minute to spare. Anybody else, anything before we close? Just a quick follow up from us on the best way to get folks access into the firefly repose. Does anyone have advice on that? Open the repo. Okay. That would be a straightforward way to do it. Yeah. If that's not trackable for some reason, there is a list of the TSC member to get hub IDs from the TSC page. So you could also invite them. And I would ask that you invite me as well. Okay. Got it. Thank you guys. I would like it as a private access. Private access really doesn't do anything for me, even if it's to me. If you need to keep commit history to keep customer data out. Maybe you should do a squash commit and make those repose public. You hear that speed. Yep. And I'm counting on the fact that that makes more sense to Jim and Peter. All right. I think we got the information we need. All right. Thank you again. Thanks everyone for joining. And talk to you next week. Bye.