 Hello, everyone. Welcome to the weekly TSC call. As I think you all know, this is a public call. Everybody's welcome to join you. However, you need to leave and be aware and live by the antitrust policy, the notice of which is currently displayed, and the code of conduct, which governs all our activities within hyper danger. So with that taken care of, we can move on to the announcements. Right. So you inserted that first bullet so I'll let you take it. Okay. It is what it says on the 10, due to the hgf being the week after the monthly dev route call has been pulled in a week. So it is next week on the second of June. And that's a chance for developers and marketing to get together and figure out how to work better together. Helen, if you're on the call and you want to say anything else. Yeah, I believe I added that as well. But yeah, we're going to be talking about a few things next week, just reviewing some of the work that's been doing happening on the white paper and greenhouse update task force. We're going to walk through kind of what's going on with with hgf global forum in terms of the technical tracks just to make sure that we're spotlighting ones on social media and helping promote the sessions that you all are in. We want to make sure that if there's anything we should call out or especially highlight, we'd love to have your input on that conversation. And then also the dev route newsletter which is here on next bullet point. Just if there's any other content suggestions or you know ways with that we could kind of hunt out some more information from the community. We just have appreciate everybody's thoughts and input on those those topics and would love to see you there. All right, thank you and right. I mean, you know, people always come to the TSC saying please can you help us get more people interested in a project. I mean, it's one way to get, you know, to socialize your project and possibly get more people to join your effort is to advertise it and take advantage of this kind of like, you know, marketing possibilities we have so not every open source project has that ability so we have it. It's a shame we're not taking in more advantage of it so please do consider doing so. All right, otherwise we just have two reminders the weekly developer newsletter. Again, this is yet another opportunity to advertise what's going on in your project, and then the, the Hyperledger Global Forum registration, please make sure you are registered and then the word out. Yes, I will add one more announcements for those who are maintainers you must have seen I sent an email to the maintenance list. I love the opportunity to give a TSC update at the beginning of the conference, and I figured it would be nice to give a little bit of an update on the different projects. Maybe I can get into the details, but if you send me a bullet or two that you want to kind of highlight about your project, maybe it's like a major release you had over the last 12 months, or that's coming up, something you want to draw attention to. Please send me this, and I will try to insert this into my deck. And I mean obviously you know I can't get into any details but my idea was to kind of, you know, maybe get people to pay attention and then maybe get their, you know, interest into finding out more about any of sessions about the different projects with demos and whatnot. And it's a way to advertise a little bit what's going on. So, if I can be of help. I have 20 minutes of a bunch of things I'd like to cover so I don't know how much I'll be able to say but if you send me, like I said the bullet or two, I will try to insert this. So, let's get another opportunity to advertise what's going on in your project. Any other announcements anyone wants to make. All right, let's move on. So, the hyperledger borough quarterly report is overdue. I actually sent an email to Silas a couple of days ago. I haven't received any response yet, which is somewhat unusual because usually he responds pretty quickly saying sorry I can't do this now. Now for now I haven't even received that. But let's give him the benefit of the doubt. Hopefully will respond to my email soon. And now, you know, either he will say when he might be able to do it if not now or he will say yes, I'll get to it. That's usually how it works. So otherwise we had two reports, one for grid one for transact, I have to give Andrea credit for always being on point and you know she's always submitting posting those reports and announcing them to the TSC list, which is kind of nice, so that everybody is aware. It seems like I was just looking at that before the call seems like most of the TSC members, the majority have reviewed those reports. They didn't, you know, raise any alarms or, you know, request for the TSC to do anything. So, unless there is anybody wants to get into one of those reports now. I think everything is good. This is your chance if you want to submit it. All right, if not, let's move on. So we have a pretty packed agenda. We'll see, you know, I'll do like I did last week. Well, we obviously have the firefly proposal. And depending on how long we spend on this, we'll see how far we go through the rest. But, you know, I think there's nothing really super time sensitive so I'm not going to kill myself over trying to cover everything today. We'll see how far we can go. All right. So, the fire, sorry, the firefly proposal has been out for now a couple of weeks. There was quite a bit of discussion. I spent a whole call last week pretty much on that. And there was some follow up. I know that the team has also been talking to various people, and trying to answer that questions they have expanded significantly the proposal, which more information. So, I'll give who is there, Steve on. Yeah, Steve, do you want to give an update on what happened. I mean you did send an email thank you for this highlighting a little bit what happened, and maybe you just do is some kind of repeat what's in your email or if there's any further changes you want to highlight. I'll let I'll let Peter take it away. All right, very good Peter. So we've had some great conversations over the last last week. I, a lot is focused on trying to make sure everyone understands what the project is, and, and what it isn't. I mean I would like to offer it's really trying hard to be brief to do a quick version of that maybe some of the key. The key highlights that that people got value out of from these from these conversations during the week to do a quick version of that on this call the proposal updates include some details on use cases some illustrative use cases. But we've actually gone through three levels, thinking about the big problem in blockchain which far fly is trying to solve around the consumability of the technology for enterprise use cases. And then to drill down through an example of one of hundreds of possible business use cases. So a more business example rather than just a technical example, and to show the kind of interactions that with or without firefly are going to exist in that kind sort of use case. So hopefully that has helped to address some of the questions around the, the kind of use cases where this mixture of on chain logic and off chain coordination with real applications that are meaty and large and exist off of the chain configurations to core systems where, where those problems intersect that far fly is trying to try to help with. I did just want to mention before maybe saying if you want to take me up on the offer of just going through a little bit of that that detail on on sort of how the, how the ping pong works because that really helps some people. So in order to mention there was an open question last week about licensing and the interaction between the Apache to code of if connect one of the plugins for firefly that's been contributed. And the LG PL code that's inside of the go Ethereum project and go actually do have an update on this we've done the work since last week. It's not much into master but it's fully proved out to split the binding code that's needed to to allow the core if connect Apache to code to talk to the LG PL code to split that into a separate repo. And have that as a separate build going into a shared a shared library a dog so far along on the next for example, and to be loaded by dynamic linking rather than static linking. So hopefully that addresses the concern that of the incompatibility between LG PL and static linking that was that was raised, and should allow the connect code base to go in with the firefly code base on day one if that's a program. So, so that was a few a few items there and an offer to drill down into a little bit more more detail. So is there any other questions from anyone. Tracy. So my question is around that latter point of the licensing. Does that limit the platforms on which this could work. It's, it means that if there were a company that wanted to extend the firefly community in a proprietary non open source way. And that's that company wanted to use the if connect piece, and that company didn't want to provide a non LG PL plug in, because there's a plug point now they could provide a non LG PL one using borough code etc. And they wanted to use windows rather than Docker that company trying to extend the ecosystem might hit a hit a challenge around specifically not being able to build on windows because the go, the go technology does not have support dynamic linking yet on on windows. They could build it on their laptops they can build it anywhere but they have access to the source and that would all be fine. They just couldn't create a paid private closed source distribution without doing the work that we talked about last week of implementing these 20 or so plug points that that that that would be needed on each connect to replace the LG PL code. Does that answer your question Tracy. I think so. I guess that a follow up with a slightly different question then which is what limitations would any enterprise using this have obviously been at that question. So, obviously with the patchy to the patent licensing and everything else that's given with the patchy to enterprises can use things as they desire right. So what what limitations would somebody have other than obviously the windows piece. I believe none that their solution would be using all kinds of dynamically linked LG PL libraries the, if they were using Linux or Docker they would be using hundreds of them so this would just be another LG PL library and in the mix that's been been dynamically linked to that code. Yeah, it sounds like you've managed to work around the main issue. Gary is next. Thank you are now. Sort of, you know, you know, in tune with Tracy's question but I don't really have a question about it but again I think sometimes we always like to bring this up we mistake the points here right so even if the as the code stands today even if you have that code in that repository and enterprise Peter specifically was very clear in the words right, a commercial offering where you actually provide the distribution to somebody else. Right, that's fundamentally the LG PL license and the GPL license right. And again, technically the license just says that you have to provide the source to any of your changes if you do it and of course the stuff that's in there. So, to me, you know I think this was a good solution right, it doesn't limit any enterprises ability to use it even on windows. It means that they can make it means that if I took it, and then want to make a commercial distribution about of it, then yes I might have an issue right, but fundamentally all that really says is you have to have specified a license and any changes you, you know, but our code was all the rest of the codes already open source. So I think this is kind of a, a no op in a way, I think the solutions clever. I've also said if we don't, if we don't include the code in the repository right then again you can also you know link to other stuff right this is how we do it with no with a lot of new JS stuff right we don't actually, you know the equivalent of go like we don't vendor code, we don't include no modules within the within our node repositories right with go we used to vendor them right because you need because go to have a good package distribution right with go mod. And, and the ability to sort of seal those right you can actually, you know, get reproducible bills, right. So anyway, I'll just leave it at that but I don't, I think this is a good solution to it I but I don't think that there's an actual really actually an issue. All right, thank you Gary, that was next. So my concern is that you still have to do extra steps if you want to release other windows, which is unlike any of the other projects we have if you want to release other windows. But legally meets the standard. I think it kind of misses the spirit point of the patchy to outbound code. But it meets the legal standard was much effort looked into it's trying to get pro to replace what go was doing go Ethereum. So what's happened over the last week is carving out the the interface. We haven't. This is obviously a project used very actively the. So changing the implementation of the RP encoding would be a longer piece of work. So a great piece of work it's available. Then or anyone else would be, you know, you should be a straightforward piece of work to do if somebody knows that code and wants to contribute it we don't see an imperative to do it as we understand that I think to Gary's point there's is not a problem here that needs solving specifically in the coming days is our understanding, given what we've done. And there's a straightforward path to, to, to, to someone who was in that that edge case of not using, not using docker and wanting to swap in that code there's a straightforward path for them to swap that code in. And we don't. I mean, if there's a real explicit requirement for collider was a member of this community to be the ones who creates a new implementation of the RP encoding binaries for this particular project would be good to hear that from from this community but but right now we don't, we don't see a reason where that's a critical action to take right now, and we think the code is in a great place. I don't think it's in a strange place for an Apache to project I think it's in a really good place and should be ready for community involvement and and commercial exploitation. Okay, no dano is used Iran. Okay, Tracy. Okay. So, the last piece that you said, caught me. It sounded like we, you've have a solution but it's yet not in the source base. Yes, the expectation would be that it would be there prior to bring it into hyperledger. Sorry, sorry, Tracy. The solution that was discussed last week of making it dynamically linked code rather than statically linked code, so that anyone reading LDPL license would go, oh yeah, that's dynamically linked, no problem. Like there's no, like it's conformant in either way, it's all understanding, but you wouldn't need to talk to a lawyer about it, it would just be, oh obviously it's dynamically linked, no, that's done, that's completely done. Yeah, that's what I was talking about, Pierre. It sounded like you said that it wasn't in master, it's a solution that is possible. All of those sounded like words that to me were or not such that you were quite ready to have that available for wider use. Sorry, Tracy, no, that was in response to what Dano was suggesting. There's another piece of work, an orthogonal piece of work that could be done, which is to take RP and coding code that's part of the Borough project that exists in Go under a different license, was done in clean room without any reference to the code that was created by the Go Ethereum community and you could implement a second dynamic linking library that used that code, and we haven't done that work. The dynamic linking library does still use the Go Ethereum code. I wasn't thinking of making a second dynamic linking library, I was thinking of skipping the dynamic linking library part and just using Borough, that was my initial proposal. Yeah, I think there's two pieces. One is pulling the code out in order to make it LGPL, dynamically linked library, and that's the one that I'm questioning. The other solution, which is using Borough to directly replace any of the code that's currently calling the LGPL piece Go Ethereum, that's a second piece. I'm mostly concerned right now with the first piece and making sure that that is available in the source space as we speak today in the master. It's available in the source space. The beginning of this call it hasn't been merged into master because there's just the practicalities of a days testing needed for that switch to happen. Jim, who led that work, has completed that. He has some commitments today, so it may not be today, but we can make it today if it needs to be today, but the code's approved, it's ready, it's there. It's simply just because this is a highly, it's two years further ahead from the journey. It's used in production projects. We just need to make sure, as with every open source community, that that last phase of it going into master happens when it's gone through all of the checks and balances. It's as simple as that. It's not because it's not ready. It's just not yet flicked from a branch into master. Yeah, I would say that's a prerequisite to bringing it into the hyperledger repositories. That's all I wanted to bring up. I think, Tracy, we can definitely make that requirement, you know, if you want to approve this with that caveat. I think that's reasonable, but it sounds like this is just a matter of time. They have the intention to do so anyway. Let's go to the queue. Angelo. Thanks, Erno. Not sure. I would like to move to another subject, not the licensing thing, if it's possible. Let's see if Gary still wants to talk about this. Well, I don't really want to talk about it. I just wanted to say, again, you know, people can put whatever dependencies they want, but I guess we should answer the question. Is the code as is, does it violate being contributed with an Apache license? And I don't think that, I think, as long as the LGBTL code is not actually in there, then it doesn't. This is what we do with all of Node.js. Every node thing that we do, right, we do not include the node modules in there, and that does not affect the source code. So I guess that's my point and I'll leave it with, by the way, Kubernetes does not allow you to build the control plane for Windows today. So like not having Windows support is not a problem. Sorry, Brian, you're about to answer my question. I think so. I was barging in and very rudely apologize for that. This question of dependency is something that the Apache Software Foundation has pages and pages on and there are categories of licenses they allow to be depended and that sort of thing. And it's in a critical question is, is it in the repo, a second critical question is, is it distributed from Apache Oregon for structure or in our case from the resources under our control, right? And for example, LGPL code cannot be contributed into an Apache project, even in a vendor branch or that sort of thing. It can be depended upon at build time and I believe it can't be distributed from Apache org servers. So I think any proposal that has a dependency on LGPL, especially upon an abstractly defined interface for which there could be a re-implementation under something else, completely fine. It's something I just want to highlight for folks who are coming into the project, but as long as it's not checked in on a vendor branch, then I think we're all good. And then a core question becomes, do we distribute Docker images or other kind of system images with that in? And I think we would need to come up with a policy for that because I think we've avoided having to answer that question previously. All right, thank you, Brian, for that clarification. Hopefully that helps people who are concerned about this. And I'm pretty sure that means I think this is a fine proposal. Well, that's what I'm getting from what you're saying. So Gary says that too, so I'll take your word for it. And there is work anyway to try to reduce the friction at that level too. So I think we're in good shape. Angelo. Yes, if I can switch a little bit. I still personally have some issue with it's just my point of view. I just want to stress this. So in the document it's written something like data privacy by default. Then the example that is given it's not really data privacy by default because the tokens are leaking and are leaking information about who is the owner of the token, the content of the token, the token itself. So can we can it would be possible to just scale down a little bit the the the the sentences, the magnitude of the sentences. Also in the abstract, it's written, it solves all of the layers of complexity. I mean, is it does it really? The shipping unit is a bit too to stretch it as a as Brian is in the sense. I'm saying this because if you really do that, I mean, it means that you have such a you have a global solution based on a strong cryptography like a paper like I don't know if you know the paper at the exit that gives a complete system that is privacy preserving based on on on zero knowledge. And to me this is the this is the firefighter doesn't seem to go in in that direction. So which message are we sending if we this publish if this this project gets published and I see the goal of the and I find very interesting the goal of the project. But are we are you really making it? Are you really delivering this? You said that the project has been used in production already. Do we deliver zero knowledge already in production? Can we see the code? I mean, maybe give it an open source in this. Can we see? I think this is a good point, Angelo. Maybe you guys need to tone down a little bit the expectation. Some of these claims may be a bit far fetched, but you know, maybe with less of a marketing hat on you can say that you aim at solving, you know, the layers of complexity and be a little bit more humble. Sure. So I guess it would be very expensive to do small word wrangling on a large call like this. So I'm suggesting we probably take that one off offline and really happy to make sure the words are accurate and really help people understand what they they do get that it's the layers of complexity that aren't solved by all of the components underneath that are being solved, not the layers of complexity inside of those components. So just a suggestion for that. Angelo, we've had dozens of comments in the document through the last few weeks. If you wouldn't mind just highlighting some areas where you have questions or where you think the wording could be clarified, we're happy to use to continue to use that mechanism to to improve the document. I would ask you to consider, you know, the link at the top of this document is a 404 now. I would ask you to consider actually filing this as a hip in GitHub. And then all these comments and pointers and stuff will be preserved in the TSC repo. We were trying to get away from doing Google Docs before. So I would just as a disinterested observer. That's a good point. And for that matter, if you go to, for instance, SoTooth, the Wiki page and, you know, it points to Google Docs that was the proposal for SoTooth, which no longer exists. And you get a 404 saying, sorry, don't know that document. So we seem to have lost a piece of history there, which is always the danger when we rely on external third party systems, even if it's from Google. So I second the rise point on that one. Okay, any other questions? Angelo, you agree with that? I mean, I think it's reasonable. You should just point out if there are things that need to be toned down, maybe make suggestions and rewarding some of the sentences. I think it's a quick pass that it can address the issue you're pointing out, which I think is fair. Grace? Hey there. My question is a little bit of a pivot, but I'd love to hear more about the community management processes that you all are putting into high growth and firefly. I think it's a little challenging when it doesn't have an open source history to turn to and say, oh, all of these, you know, activities have already been done. So we can see you're going to continue to do it. So I'd love to hear more details around, you know, if you're going to have contributor calls, how you're going to integrate with the hyperledger community. Just want to make sure that y'all have thought of that early. Very much top of mind. I guess we are saying that the hyperledger community is going to influence us here as well as being a place to bring those contributors together, being a place that has standards that we can follow and that we can use those as the template. Or are you saying that in hyperledger the intention is that there shouldn't be kind of that unified approach. It's much more each individual project should have its own sort of from scratch processes. It looks like Brian's having his hands up, but typically there's kind of a project organization and a hyperledger cost project organization. Go ahead, Brian. Yeah, yeah. So, you know, we are, as hyperledger staff, definitely signed up to help facilitate the development of this community. We've talked a bunch with the Kaleido team about the fact that, you know, when building this now as an open source project, it means there is engagement with the community that they'll need to do and ways to, you know, search for bringing people up the learning curve from being, you know, first timers to all the way to becoming fellow core maintainers on the project. I think, you know, there's still a lot of folks who are perhaps new to hyperledger, even new to open source, although certainly consuming lots of open source and so not unfamiliar with it. And we're very eager to work with the team on just as, you know, we did with Consensus on Bezu, just as we've done with other projects here to help set the conditions that when people show up, you know, they're met with a welcoming community. It is, you know, something we'll definitely want the TSEs up with too and, you know, and we'll get out there with, we'll get outward about the project to try to recruit more contributors. And I think just to turn it back to Kaleido, like, you know, the expectation is, you know, as this code is continues to be built, you know, and continues to be innovated that what previously had happened as kind of internal development processes, you know, against an internal whiteboard internal issue tracker, whatever planning tools, somewhat turns inside out, right, and becomes kind of exposed. So it's more than just the code. It's also the process of that further development and everything I've heard from Kaleido, by the way, for everyone else here has been that they recognize that and they want that and seek that because that's going to help make this a better product. We've been really trying to walk the walk rather than talk the talk there. So since, you know, since this this process has begun, we've taken every architecture document, credit issues and get pointed to them. We put it in gets knowing it was the wrong place, because we assume that once we go past this phase, there'll be the white place inside of Hyperledger, the white community whiteboarding tool or whatever, et cetera, for those sort of collaborative discussions on documents that they'll exist. But we we try to sort of turn stuff inside out, make sure that that's from that point on, all of the code changes are happening, and the comments, et cetera, where we can happening in the community. And we know that there's more to do in that space. And we're excited to do it. That's the reason for going through this process is an excitement to really bring wider community evolution, like all the way from architecture through to implementation of this. So hopefully, if you if you look to the repo, you'd see a real sort of demonstration through action of change. But you're right that it's still right now that those contributors are primarily there with a with a collido, you know, collido name badge. And that's really something where we're looking forward to changing. All right, let me interject here. I mean, a couple of things I wanted to say on that very point. The first is, well, you know, welcome to the club. This is, you know, what every company that's switching from proprietary development model to open sources to go through, it is not always easy. And, you know, it does require changing your mindset and the way you work so that you don't have internal meetings where you exclude de facto everybody else. And it does require quite a bit of an effort. And I speak, you know, from experience. But the other part is, you know, we have an incubation stage for that purpose as well. It's, you know, to get out of incubation to graduate, your project will have to demonstrate that, you know, it does behave the way we expect as a real open source project with all the, you know, bells and whistles that come with this, including having CIs and whatnot. So I think for now, we can leave that to later. I don't think it's a requirement to, you know, I think it's fair to assume that the Kaleido team does, you know, good intentions. And the reason they come to Hyperledia is because they want to be an open source project. So I think that shouldn't be held against them. I wanted to, if I may, interject a very practical question, which should be much simpler for you guys to answer. And I'm sorry, I didn't have time to dig further into the code to figure it out myself. But one thing I was wondering is, in terms of, from an operational point of view, so I understand you have these Firefly nodes, and then underneath you rely on some blockchain network to be there. But who manages the blockchain network? I mean, in your demo for development purposes, I understand the Firefly CLI will create a small network for you to play with. But in production, my impression is that you would have, you know, you would use whatever tools is appropriate to manage your blockchain network, depending on what blockchain framework you actually use. And then you would insert your nodes of the Firefly layer to basically connect to the nodes in the blockchain network. Or is it that no, Firefly is going to manage the whole blockchain network for you? Great question. It's the former on the blockchain network, but also the other networks, like the private messaging network, if you're not using the built-in just peer-to-peer, HTTP, you know, the open source plug-in that just comes with Firefly, you've got your ActiveMQ or Artemis private messaging network, that plugs in. Your broadcast data storage, something like IPFS or Swarm, that just plugs in. And the management of those, that's, you know, by architecture, that's decoupled from having Firefly as a sort of unifying component exposing the API and, you know, that private data interface to your applications. Okay, that makes sense. Thank you. Brian, you still have your hand up. Is that on purpose? Oh, sorry about that. Okay. All right. Any other questions? Tracy? Yeah, one of the questions that I think we have asked of other projects coming in is commitment outside of one organization, right? And I don't know if we tend to bring that up because that's part of the exit from incubation sort of peace or not. But I wanted to see, like, you know, obviously not open source yet. How do we get kind of the momentum behind this and bring in other sort of organizations such that we're not just looking at Kaleido as a single organization supporting this? So it's interesting you bring that up because I have to say my recollection was wrong when it comes to, you know, in a separate email, Arun actually asked me, hey, what does Sponsor, you know, what qualifies as Sponsor for project proposal? We actually had quite a bit of discussion of Sponsors for creating labs, but we never really got too much to talk about Sponsors for proposals. And in my mind, I was like, but in the project case, these are companies. And then I went to look and I realized this was wrong. All the previous proposals were actually sponsored, so to speak, you know, by individuals. In the very first case fabric, the affiliation is not even mentioned. It's just two people, you know, and so I don't know. I mean, here they have added quite a few people to their proposal. But so I just wanted to give the background there, you know, it is not well defined. I have to highlight that. Yeah, I don't think it's a Sponsor, so I'm sorry. I don't think it's a Sponsor, so I think it's the section that we have in there about resources dedicated. And I think right now what we have is six people from Kaleido and one person focused only on ETH Connect. Potentially, I think it's from another company. And so that's, I think that's the piece where I was thinking about the support from multiple companies. Yep. Okay, I get it. Yeah. And this is Dave kind of following up on that. More generally, I wanted to ask maybe some of the other TSC members that have been around longer than I have that have approved other projects. Are there other criteria that's been looked at in terms of making something a lab versus a project? What types of things should we be looking at for crossing that threshold? I think it's fair to say we don't have anything really written down with like very clear objective criteria. We have raised the question as to whether going through a lab was a mandatory step. And we clearly said, no, there is a record of that in the decision log. I'm sure somewhere I would have to dig for it, but you can trust me. I know we specifically asked that question and answered no, it's not a mandatory step. We never got to the point of discussing, well, where does, where do you draw the line? Historically, we have had a few projects proposal or project proposals come to the TSC where we said, you know what? We just don't see enough support for this at this point. And we suggest you go to a lab and that will give you an opportunity to increase visibility of your project and gain momentum behind it. And then maybe you can transition to a project. But, you know, in no fairness, I don't think this was very objective based on like very objective criteria we're applying. So there is room for subjectivity here, I'm afraid. Right. And what would, I guess, set this project apart from those other projects that we said they should start as labs? You know, one of the things that gave us, I'm sorry, I should have raised my hand. I'm sorry about that. Go ahead. Well, Hock maybe wants to say something. No worries, Brian. You can always cut in front of me if you want. All right. One of the things that gave us reason as we were talking with Collider to think that this might be better as a project rather than lab, at least not to dissuade them from that, is that it's in production use now, you know, a number of projects. There's traction, there's other people beyond their own company who are touching this and want to see it open source. We'd like to be able to give it the kind of publicity, frankly, and marketing, so to speak, that you get from something that's a project and we tend to kind of discourage from things that are purely in labs, although we do break that principle sometimes. And not that things need to be finished or in production before they become projects. I mean, Cactus is an example of something that did graduate to a project, but I think labs are for those efforts that are still finding their footing in terms of what they want to be or how they fit into the larger portfolio and projects are for those things where, you know, there's some real momentum there. And there's a commitment to go out and recruit and companies and developers, contributors, that sort of thing. It's a subjective call and that's something that we've never been really good at saying here's the specific metrics, but I almost think that's the nature of community development and what we're doing here. And this, I don't want to introduce the whole question about rebooting the greenhouse and other things that is a process that's underway to not make it feel like we're constrained to specifically 16 projects or only 14 projects or something in the greenhouse. All right, thank you, Halt. Yeah, so I'll take a stab at answering Dave's question. The TSC has never really been consistent about sort of, well, there have been some points that have been consistent, but what the TSC thinks is a project has varied highly over the years. The TSC has even forgotten that some things are projects on occasion. So the consistency is sort of all over the place and it obviously, you know, it's not too surprising given that it changes based on, you know, who's the TSC, whether some people think we should have like, you know, a small number of projects in hyperledger, some people think we should have a huge number of projects. So it all sort of depends. I would say one thing that has been consistent, and I believe Tracy has been addressing this, and obviously Tracy knows this because she's been around hyperledger since almost the very beginning. We have generally wanted projects coming in for incubation to have, I guess, committed resources from people that are not in the same org, so generally at least two different orgs. And I think every project that has been approved has had this. So that really has been sort of the only hard and fast requirement historically for bringing a project into incubation. I'll turn it over, I guess, back to Arnav or Gary. Yeah, Gary, go ahead. Yeah, I would actually, pretty much, I would agree with what, I was going to answer the same question as hard. I agree with what, you know, Hart said in there. I think the other thing I think when people look at stuff, right, is like, you know, where, or I can tell you, my considerations for many projects on them are, you know, is where do things fit, right? Does this make sense as a, you know, project? Is this type of stuff that we want to see kind of going forward, right? I mean, you look at, you know, some of the other, you know, projects that have come in like that are not, that are blockchain tech, but not don't necessarily have, you know, aren't, aren't, or whatever, aren't, aren't another version of a ledger. And, you know, I think that's where you kind of, you know, kind of look, right? Some of the lab ones, I think have been more like, well, these might be a good idea, right? We haven't done a lot on them. It's unclear where they would really fit if there could be kind of, you know, adoption of them or whatever, right? So it is, there are, there are some objective criteria, I guess, right, that you have to kind of pass, you know, per the whatever, but I think in general, you know, as, as Hart said, right, and Arnaud as well, right? I think it's, and Brian too, I guess it is kind of subjective, but I guess I would have said in general, it's been, does this thing seem like a, I don't know, does your gut tell you this seems like a project is almost kind of the way, the way it ends up going? Yes, I agree. That's a definition of subjective. Steve? Yeah, just, just a one point of feedback for, for someone who's in the frying pan at the moment. There are documents out on the TSC wiki about the life cycle and the phases. And, you know, the, there is a, the best definition is for exiting incubation into, into active status. And there it is laid out for, you know, to have more than one, more than a single contributor and community support alignment, etc. And so that, I can't play, paste the link for everyone to look at this chat disabled, but I wanted to point out that there are some specific pieces of information out there. As far as incubation, there, there, there is not, for what it's worth in the documentation, anything listed around, that I've seen around, you know, some of the other topics. So I just wanted to point that out because Tracy started this rabbit hole, I think, asking that question specifically. Yeah, no, but I think that's fair. I mean, you know, every time we go through these, we find, oh, we are lacking documentation and then we make an effort to, to, you know, develop that documentation. And here you catch us, you know, in another case like this, where clearly there is some common knowledge we all share, I mean, all, at least the old people like myself who've been around since the beginning of the project. But, you know, yeah, I know it's not ideal. Hart is back on the queue. Yeah, so I'm going to sympathize with Steve here. As I think we were, you know, I think Cactus was the last project approved. And even if you sort of know all the understood norms and conventions, it's still quite a bit to go through the incubation process. And it would be fantastic if we could streamline it so that for, you know, obviously some projects might, some submissions might change the direction of Hyperledger enough where they need larger discussion. But I would hope that we could, in the future, have, you know, well-defined enough criteria that, that sort of these project incubation discussions don't get dragged out forever. All right. So we're almost out of time. And it sounds like, you know, people are bouncing around as to whether they should be approved as a project or should we send them to a lab? Or there's another option I'd suggest, which is wait on approval for, say, a week, if Collido felt, I mean, I know Collido has customers using this who've engaged on a technical level with them. You know, in our conversations, it seemed like there was already some movement there. Others who'd probably be a part of the project once launched, they just couldn't speak to specific commitments or anything like that. It sounds to me like this is the one issue, this question of, you know, outside identified, let's, the word committed is strong, but outside identified additional maintainers on a project like this. Certainly that's required for graduation for incubation. But if that's the linchpin, maybe, you know, we could try to work with Collido on identifying the, you know, somebody outside of Collido who would be another additional, another maintainer on the project if accepted. Would that answer this concern? Well, Tracy, I mean, for instance, you raised that question, would that satisfy you or you feel like, well, yeah, just adding a name there makes no difference? It wouldn't be the first time, I think, that we added a name, but that's a different story. The, I think it's a matter of success, right? And, you know, how do we make this a successful project if we bring it into Hyperledger? How do we make it a success if we bring it into labs, right? I think there's a couple different paths there that we could think through. And, you know, I think until people can actually see this as open source, right? I think that's where the challenge is probably for a lot of people. You know, I will say that there are things that were submitted to labs that, you know, have learned a lot from that process, right? Learned a lot about how to work in a community, learned a lot about how to market themselves to a greater audience. I think there's, you know, I think some of the things that Brian, you mentioned could be obtained from labs. So I don't necessarily know whether or not I would say yay or nay to this at this point. And I don't know what in my mind would convince me to say yay, right? I'm a bit on the fence at the moment. And, yeah, I don't have an answer, I guess. No, that's fair. So we're quickly running out of time. Steve, do you still have your hand up or is it back on? Yeah, I just wanted to point out because maybe it's not obvious for who's currently signed the proposal. We do, to your point a minute ago, Arnaud, I just wanted to clarify that. We do have, you know, one of the largest blockchain consortium in the world, US-based insurance consortium called Ristream that has about 70% of the market. That's the Patrick from the institutes. To your point about, you know, real usage in the world, there are several other similar groups that are, you know, running this technology to your point. We're working our way through the legal process, you know, it's going way slower than anyone could ever imagine. We also have blockchain vendors. You know, one of them is a Tato who is contributing code into part of Firefly today to the point about multiple contributors, as well as some other signatories. So I wanted folks to just familiarize folks with that. And, you know, I guess I'd observe that other projects started with a seed contribution from a company that doesn't seem like an unusual path in. We're certainly committed to, as we started this conversation several meetings ago with the TSC where we are committed to doing proper open source to building a community. I think this, to Gary's point, this is a broad ambitious project that is solving a massive pain point. I think a number of you have told us directly that this is a top, probably the top pain point out there that the market is seeing right now. So as far as the potential value of this project, I think it's really significant. And I did, you know, so I definitely want to encourage the TSC to do the right thing and follow you know, the best practices and the processes. We've been, you know, working off the documentation that's there as well as the feedback we've been getting to go through this process. We have to catch up because we're running out of time. So I want to say, I mean, that's not the issue. We understand you're trying to do your best in presenting this project. And I do think Tracy raised an valid point, which is historically, and you know, I've been in the back looking again at the proposal, various proposals from many of the projects we have, there was at least always two companies committing resources to the project. And so I think, you know, we may not have written this anywhere else. And that's a fault, you know, I take that, you know, as a to-do for us to address. But, you know, we have been relying on a lot of common, you know, shared knowledge among at least the old timers in Hyperledger. And I think, you know, that's the situation. So given that we're out of time, I'm going to close the call and they said what I suggest is you take advantage of the extra week to, to, you know, try to see what you can do on that front. I think you have addressed a lot of the questions. So at least there's a better understanding of what this project is about. And I think next week, what I would like is, you know, based on whatever the collido team, you know, manages to do, we'll have a quick update on the situation and then we can make a decision one way or the other, either to send them to a lab or accept as a project. There's no point in dragging this on any further. All right. In the meantime, sorry, Sophia, we didn't get to you, but we have to close on this. So thank you all for joining. We'll talk again next week. Goodbye.