 All right, we are recording. So, as always, our anti-trust policy notice. We do have a new slide that we're inserting in here. As Dan would normally say, we do welcome everybody to join us in the community. We do have a code of conduct that you should follow, basically stating, you know, don't be a jerk. And then, yeah, so this is our agenda for today. I'm offended there's not a French version. I'm sorry. How many different languages can you fit on one slide? I don't know. You just got an AR. Make one. Pull out it. All right. So event reminders. Obviously, the APAC hack pass coming the week of March 4th. We're finalizing on the venue with the hyperledger global forum is coming up in just about two weeks, just under. And that's in Basel, Switzerland. If you haven't registered yet, please consider doing so. And then the last reminder here is just that the Linux Foundation IT is going to have limited support at the end of the year due to the holidays. So December 17th through January 2nd. You'll see limited support. So I just got a note from Dan. He's at the hospital with someone. So I'm guessing he will not join us. He did say he sent a note to Kelly, Brian, and Tracy. Oh, well, I haven't checked my email. You might want to check your email. Okay. Tracy. Yes. Also, it's not just the IT group that's off, right? Most of the staff will be off at that time. That's true. So we shouldn't expect immediate responses. Well, we never. But stuff may take a while. It may take a little bit longer. Yeah. Yeah. That's true, Mark. Thanks for that. All right. So the first thing that then we have on our agenda is the Hyperledger Bureau quarterly project update. Silas, do you want to take us through that? Yes. Hello, everyone. Hey, Silas. So yeah, I'll dump it in the TSC mailing list. I know it's on the calendar invite as well. So there's the update. There's also some attached. I usually try and do a roadmap for the next quarter and a post-mortem of my last roadmap, although basically everything off the last roadmap got kind of abandoned. So, hey, never mind. So Project Health. Yeah, I don't know whether no news is good news. In some ways it is. In some ways not. It's largely the same as the previous update. So we've added quite a lot of features, particularly around governance. And we're now in a state with what we're doing with borrower, when I say we monax, that we need to not throw away user's data and operate without us having quorum. So we have a proposal mechanism which allows you to vote on an atomic batch of transactions to upgrade smart contracts. We have a governance TX that allows to change different types of network parameters. We're working on a fork TX, which says if you dump this version of this chain at this height, restore it in a new version of borrower, you should get this app hash. So it's a somewhat principle way of making breaking changes where you need to throw away blocks or at least archive them through an old chain. So that's a kind of general focus of the work that we're doing. A bunch of sort of fixes and hardening. We found that there are various types of EVM errors, so they're getting swallowed. And there's some reworking around that. But the big thing would be the governance proposal mechanism. In terms of the project itself, we are still rather lacking in maintainer diversity, although there is, in particular, one individual who I'm, although I have been here before in saying that I very much hope to add as a maintainer. I hope for you this one will follow through. He'll be joining us in Basel, actually. We seem to have a steady stream of interest. It hasn't gone up or down really. Several messages a day on the chat and many lists are quiet, but that's a bit of a chicken and egg thing. I don't put a lot there, although I am planning to announce the next major patch release we do because I want to add some docs to the proposal mechanism before I go on with that. In terms of issues, this is, again, similar to last quarters. The biggest area we can help on it is documenting our tooling and general documentation, so how you get started. I have added a couple of example apps on our borough.js, which is our JavaScript library for talking to borough, which currently lives in a repo outside of Hyperledger because it relies on GPL code. However, we are in the process of changing that. We found a MIT licensed ABI decoder, which looks like a fairly simple switch, so hopefully we're pulling that into the, I think, into the borough repo. David Boswell has put me in contact with a potential technical ambassador to mentor on borough who might be able to help with documentation, although he has gone quiet since last email. But, yeah, if we can get anyone to help us on that, that would be great. The release cadence is good, as it was having me bad. Before the last quarter, we made three releases, one of the major, including the proposal mechanism, the improved error handling I've mentioned, and the EVM stuff, as well as upgrading Tenement. One of the things that we're working towards is Tenement hitting 1.0, which may happen around March time, which is really the trigger for us to try and start thinking about moving from 1.0 status ourselves. We've built quite a useful thing called VENT. Again, this lives in, we have a single satellite repo called VosmarMot that contains borough.js and VENT and a couple of other examples. Again, I'm planning to deprecate this, particularly if we can get borough.js out of GPL and put it all into borough, kind of monorepo for the win. VENT is a service that listens to Solidity EVM events. Based on some declarative specifications, you give it, it will build a kind of event sourced table structure. It's a query-side scaling. We use it with Postgres. It supports a SQL-like backend as well. One of the standard things you often build with blockchain applications. In combination with some stuff we overhauled before around our event and block storage, we now have this kind of block and transaction execution structure that gives a complete history of transactions. From that, we build SQL tables, a bit like with something like Kafka. It remembers the height as an offset. If it dies, it will always recover because it writes atomically when it updates a table, it writes the offset there. It's quite nice to build event-pipy things. That's what we're using it for. It's nice to get a bit more use. It's quite a nice thing built from the ground up. Also, in terms of the way the specifications work and how they interact with the Solidity data formats, it might be interesting to see whether we can adapt it for use in both Fabric EVM and Sortie SES. That's something to flag. Mailing list, quite chat active, all you said about. Current plans, you can see the borough roadmap, which is linked there. We're looking, as I say, about this fork TX mechanism, which we think we can use for doing a bunch of interesting things, including upgrades and kind of a state channel-like use cases where you fork to a smaller borough with a few evaluators. We're also looking ahead, and I think relating to some of the conversations on the TSC, I'd like to mount a Wazem engine within borough. One of our team has got a kind of proof of concept using LLVM and Antlet, a Solidity grammar, something that rather surprisingly doesn't exist. Solidity is all hand rolled. He's managed to get a basic contract compiling to Wazem. So I find this is a potentially interesting migration case. We have a whole process engine written in Solidity, more on that in a second, and migrating some of the functions over to Wazem would be good in itself. But also, if Wazem and Wazem-related standards are something that Hyperledger frameworks can maybe atomize around, then that's kind of an interesting direction for borough, too. In slight side news, although I think it relates to borough, we've been building this business process on a blockchain functionality in a project called Blackstone, which is linked there, which is mostly a Solidity implementation of business process modeling, but also has a Node.js API for kind of a builder API for building up these graphs. We're working with borough to kind of give it this process focus by giving it some native, like, process graph traversal and process-related S-natives. And one thing I'd just like to put out there, and stuff around the supply chain, which is kind of toolkit framework type things is a new direction, we would be interested in potentially in Hyperledger hosting the Blackstone project. Off the bat, it would be compatible with SES, well, it ought to be fairly easy to make a battle with SES and Fabricivium. Maintain a diversity, so yeah, a lot of Monax, we've got a new person in Monax who has been added as a maintainer. A very good contributor who came out of nowhere is a guy called Purik Himbert, who's coming to Basel, the largest of Hyperledger, which I'm very grateful, or well, 75% largest. So he's introduced some nice stuff, including like some RFC type, we're calling it VIP, although that does clash with Bitcoin Improvement Program. And he's done a bunch of code changes and has been great to work with so far. So I think if he's able to keep up contributing, I'd very much like to make him a maintainer, which would be a non-Monax maintainer. He's in, he works for a type of fintech company. But a lot of the work he's doing extraneous to that. And we've had some useful issue suggestions from Kenneth Koski of Sawtooth, and a few other documentation stuff, a little quiet on the contributors, but they do appear. Yeah, so I think that pretty much covers it. Questions? Go for it, Rupin. Two things. One is I just met with two weeks ago with Jan from Monax. He showed me the BPM engine. And he showed me also the how it works with the agreements network. So does your BPM, I mean, your BPM engine, I assume is similar or the same as the one in Monax, because you guys are, I mean, Monax is open sourced everything, right? So that's a question. Yes, I mean, we've open sourced almost everything. The BPM engine is implemented fundamentally in utility, and that's open sourced in Blackstone. And as is the API, the Monax platform stuff you might have seen is our version, our Monax flavored UI layer, primarily UI layer on top of that. But Blackstone is meant to be general purpose business process modeling in the utility context. And like I say, we want to look into having some process supporting features in Burrow, because a lot of this stuff is not ideal running in pure utility. And that's where things like Wazen and our existing S&A to functionality become interesting. But yeah, that there are no two implementations. What you saw under the hood was Blackstone. Yeah, I didn't have enough time to go into depth on that. But Jan did say that I should come back to the offices on, I guess, to the to the Monax offices to look more at it. The other thing I wanted to ask for your help is in the identity working group, we're preparing a paper about identity in different DLTs under Hyperledger. Of course, that includes Burrow, and we have very little material on it. I was poking around your documentation to see whether I could create a 200 or 300 word output about identity from what you already have. If you do not have that, pretty accessible, any pointers would be helpful. Once we write that 200, 300 word of explanation of identity in Burrow, we'll send it back to your guys to get feedback on it. That's the first thing. And in terms of technical ambassador help, I'll be, I'll be in Basel too. And I want to get a little bit beefed up on Burrow so that I can help people with Burrow. I know quite a bit about fabric and about sawtooth, maybe a little lesser amount. But, you know, I want to improve my knowledge of Burrow. Thank you. And I mean, that would be great. I think that Burrow between as various things have been combined is in a good position to have documentation explainer added to the repo. In terms of identity, at the keys level, keys slash contract identity, there's some stuff that will be relevant to Burrow. Identity writ large is a harder thing. We do have some in the smart contracts that we use. In Blackstone, we do have some ideas around user proxies and how we model stuff out. But not usually broadly. I was going to stick around for the indie call after this, actually, to talk about some related issues and wallet stuff. But yeah, let's, let's, let's chat at Basel Whippin. And I can give you a tour of what we've got and where we're going. Yeah, Ian did mention MetaMask. I didn't, I did not, I know whether it was a generic, you know, Ethereum product or whether, I mean, how it would be changed to adopt to Burrow. Yeah. So it's, it's a little difficult to get it working directly because it requires a method on the web three interface, which, by the way, Burrow doesn't have at all. Cess has a fabric moving along on that. Neither of them have the send raw transaction method, which you need from MetaMask in its default operation, which involves using the encoding and signature scheme of public Ethereum. However, I think what can what can happen is at the JavaScript level, a web three provider, a kind of shim can be written that would allow its use. Now, I know there was some, some web three provider stuff going on in the context of Truffle on Cess on Burrow really being led by a lot by agreements network and Monax's needs. We've, we've been working with our own GRPC interfaces and stuff. So at some point, I think it's very useful to have something like MetaMask. So ultimately, this allows you to control some private keys in your browser, sign and send transactions locally. You can do that with Burrow, but you don't get the web, the Ethereum tooling. Thank you. So we don't need to do it on this call, but I definitely like to hear more about Blackstone. I think one thing the whole community could use is projects that span the different frameworks that we have. So to help pull things together a little bit across across the community versus separate silos. So I think that would be great. Yeah, well, let me let me post in the TSC. I wanted to kind of plant the seed that not the rail was too much as an update. And obviously, if we went through with this, we'd be looking at a proposal, either in labs or somewhere else. But a couple of things that occurred to me on that is exactly as you say, yes, there's definitely potential for this to generalize across at least the EVM transaction processor and chain code. The other area where I think this would be an interesting and all project now that EA is a co member or whatever the exact relationship is. You know, given that this is a process engine written in acidity, to large degree could be run on public theorem at vast cost. But it does seem to sit in an interesting intersection. So it would be potential for an inaugural kind of collaboration with EA members, perhaps. Sounds great. So this in your update, you alluded to possibly considering a Wendetto sometime in the near future. I think, you know, obviously, some of the challenges that exist there are around the maintainer diversity, and that sort of thing, right? I think we should probably try and figure out how to increase diversity of the maintenance ship and contributors just so you know, that hurdle is addressed before you reach that point. Yeah. Past March kind of feels like the far future. That would be when tendering was one point over. But yeah, no, I understand that that the maintainer and contributes to diversity is to come up. Again, actually, something like Blackstone, if we could drive a bit of interest in that. I think the issue is being with Barrow is that we're kind of just weird enough with respect to normal Ethereum, that we get interest from Solidity people, but part of it is not really communicating some of the features and the sort of way that Barrow works effectively enough. And some of it is not having implementation, things like Web 3, whereas our fellow projects of Cess and Fabric EVM have had a bit more muscle and a bit more interesting directly appealing to public Ethereum people and have built out some of that stuff. So it wouldn't be hard to build some some similar public Ethereum facing stuff. But yes, open to any suggestions for that. Okay, maybe we can spend some time offline kind of thinking through some some things that we can do. Yeah, cool. I'm in Basil. Yeah, sounds good. Any other questions for Silas before we move on? Okay, so the next thing that we have then is the Hyperledger cello update. Who's going to be doing that one? Hadris, I will make the report. Okay, good. Okay, I just posted the reporting to the RocketChair channel and feel free to open the page there. Our project is going as a plan and the healthy is good. In the past quarter, we made the release 0.9 as planned. And mostly the discussions happened at the RocketChair and also the WeChat group. And also we have questions and our sounds at the mail list. And our regular weekly call, it is going every week. And usually there are almost 10% present there. And from both Asia and North America area. And majorly, the Pellset gets actively reviewed and response within two days. And we have a good signal in the past quarter that more and more user keys are related to cello. In the Montreal Hackfest, one of our maintainers, Tom, present cello there and also help collect the feedbacks. We reviewed the 10 plus suggestions one by one. And we think some of them are very helpful and we put into the roadmap. And we also propose a new design spec related to the new architecture for cello. One of the major purposes to enhance the support of the consortium governing model. And for the next quarter, we plan to release the 1.0 there. And about the diversity. Currently, the cello diversity has become the stable. We have no new maintenance come out in the past quarter. And we hopefully can have new maintenance in the next quarter. And the major issue is still related to the contributor diversity. Currently, most of the contributors are still from like China and the United States and also India. And we hopefully can find more contributors, especially the code developers appear from other countries. And also, in order to resolve the issue, we do have plans like to promote cello more in the locally meetups and also for the global forum, I plan to attend that and help promote cello there. That's majorly the summary of the quarterly report of cello. We are open to any questions and suggestions. Thanks. Any plans to support other DLTs other than fabric? Yeah, that's a good question. Actually, it's also one of the questions that appear at the Montreal Hackfest. We do discuss this at the meeting. But the conclusion now is that since we do not have enough developers that familiar with other DLT technologies, we may first focus on the fabric and make sure the one-point-all release come out. Does Saututh, Iroha, Burrow, Quilt have similar deployment and orchestration products? I mean, I know that I'm asking you that question, but anybody else who knows about this could talk about it and then see how they could all merge some of those functionalities or code into cello and suggest architectural changes to make that happen. Yeah, that's a really nice suggestion. And I will highly encourage the person from other projects to help review our new architecture spec. It's to support the new construction governing model. So if you think that cannot match your own project, please let us know. Feel free to leave the comments there. Where is this document? Well, let me post the link into the rocket chat. It's in the weekly, in the quarterly report, actually. It's there in the rocket chat channel now. Thanks. Okay, other questions for Bawa? Okay. Just from the hyper literature side, we should talk about the the one-doto release and kind of the sorts of things that we think about as we want to move towards that. And obviously, there's the process that we have now for any projects that want to go to one-doto. I guess this goes to both Silas and Bawa about getting the TSC approval before doing that or approaching that. So those are some other things to think about. But definitely I'll reach out and we can talk about that further. Yeah, thanks, Tracy. Yep, no problem. So as far as other quarterly updates next week, we expect the Hyperledger Explorer. And then we are over a month since the Hyperledger Composer update was due to the TSC. So those are the two that we have coming up next week. Alright, no quarterly updates this week from the working groups, because we have done all of those for this quarter. So we will expect to start those up again in January. Then we have some open discussion items. The first one there that we have is probably the biggest one that we have. It's the project versus sub project discussion that has been spawned from the fabric desktop proposal that went out a few weeks back. So there was obviously this question of, you know, should this be a sub project of fabric or should it be a full blown project? And, you know, we've actually had some discussions in the past about kind of what is the scope of things that should be coming in as full blown projects versus something that is a sub project of our existing project. So we can start that discussion. Obviously, I doubt we'll finish it today. Maybe before we get there, though, I just want to maybe touch on the other two, which might be a little shorter. So the community survey one, just this is just FYI, I sent out an email this week that was a summary of what we discovered in our last community survey that we did last year about this time. And we're looking to kick off another version of that to see kind of what's changed since we did our initial survey. So we're looking for feedback on any additional questions that people in the community, the TSC specifically feel are useful to gather as we look. So definitely have a look at that email and that Google Docs and add your comments and feedback there. And then Arno, did you want to talk quickly about the roles and responsibilities for lab sponsors? I think that might be shorter than our project versus sub project discussion. Yes, I guess I would be happy to talk about it. I don't know if it's shorter, but it seems like those issues do excite people and everybody jumps in very quickly. It really has an opinion. We do not. Well, otherwise, you could listen to yourself if you didn't want people's opinion. Anyway, Arno, go ahead. So I mean, there are really two issues that are somewhat related. And you know, it had to do with the role of the lab sponsors. And you know, when we put the labs together, we had discussions, one of the fears, right, was, well, if we make it too easy, anybody can just come and dump whatever projects is not going to be very good for the hyperledger overall. And so we were discussing different ways of mitigating the risk of, you know, the labs becoming a dumping ground for everything and anything. And so I honestly don't remember the exact details on how this came up, but we came up with this notion of requiring some sponsor. And we define what a sponsor, you know, who could qualify as a sponsor. And I think we went through a few iterations, but eventually we settled on something like the TSC members, a working group chair, somebody like this, who has already some role within hyperledger and can back up the lab proposal. And we left it at this. And so the documentation today says, when you put a proposal together, you must have a sponsor, and it doesn't really say what is expected of the sponsor. And so the question came up, you know, in the context of somebody trying to set up a lab and somebody trying to figure out, can I volunteer to be a lab sponsor? I would like to know what my responsibilities are. And so, you know, as I was indicating in an email yesterday, you know, some of us, the labs towards basically some kind of discussion. And, you know, we were trying to figure out what is the right thing to do. And, you know, in kind of brainstorming several ideas that came up. But my concern was, you know, if we put too much burden on people to be a sponsor, we're going to first limit how many people, you know, I will be willing to be sponsors. And that will eventually limit the number of labs, which I don't think was the intent initially. So I'm in favor of trying to define what a sponsor is in a very limited way. And of course, there are some ideas that were brought up as being a mentor for the project on an ongoing basis, maybe reporting to the TSC every now and then. All of that, I think should be left to the discretion of the mentors. And so, you know, it does, and I'm happy to separate those two questions. But, you know, there was a separate issue that I raised earlier that came up in the context of, you know, a different proposal where, you know, Dave Husby was, you know, asking if he could be the sponsor. And I thought he should be able to. But so I had suggested we extend the list of possible sponsors to include the staff. Then took issue to this several people expressed support at the time. And then took issue saying, no, I think it should be somebody more technical. And, you know, we never had a chance to discuss it further. So, but there is a combined, there is a connection there because the shorter the list of possible sponsors, the worse it gets, you know, as we put more, as we, you know, the responsibility we put on the sponsors increases. So we have to be careful. I think, you know, I'd be, I would be more comfortable asking more from the sponsors if the list of possible sponsors was bigger. But it's pretty small right now. And so I don't, if fundamentally, I don't want to limit the number of labs, just because we don't have enough sponsors we're willing to do to sponsor the labs. That's really what it comes down to. Okay, the second question, I think should be deferred because Dan was a personal expressed. So he is not here due to an emergency. So I don't think we should even take it up. Second thing about the mentorship and about, you know, who's what are the duties of a sponsor? I mean, let's, let's be very clear. In open source communities, there are no real duties. Nobody's held accountable. Anyway, people volunteer all the time to write sections of the paper, and they never show up. So what do I do? So this is a list of suggestions on what a sponsor can do to make a lab healthy, right? So, of course, the initial thing is that the lab should make sense to the sponsor. Otherwise, why should the sponsor agree to put their name on it? But even that cannot be really insisted on, because unless somebody questions a sponsor, have they read the actual proposal? One never knows. So to be a responsible sponsor, you have to at least read the proposal and to agree to it. That's the first thing. Second is, maybe help them write the proposal in the right way, because the sponsor is presumably already aware of this. So it's all got to do with onboarding the lab, a sponsor saying, yes, I'm standing behind this project. The other part which was basically be a mentor, you know, that's an open thing, right? Meaning, be a mentor is such an open statement that it can be like somebody asking once in a while, how's the lab going to somebody saying, you know, we haven't seen any activity in the lab for this many, what are your blocking points? Can we put in touch with others and so on and so forth? But I don't think the intention was to have all these as requirements or no, so these are not like, you know, these are some suggestions. So no, but okay, and that might be fine. And so that's that's what we need to decide as a, you know, so that's that's where I would put my support, which is as a lab stored and as a potential sponsor. This is what I I would say, you know, at least be aware of what the proposal is. And what are the potentials before you put it in? I totally agree with that, because if they don't do that, then I don't know what they do. And what it means at all to have a sponsor. So I agree completely with this, I think that's not a question. So that's why my proposal was to say, yeah, this at least is part, you know, is the main responsibility of the sponsor. I don't have a prime listing other, you know, tasks they might take on as optional, you know, I think it makes sense for the sponsor to have some involvement, not just to be a rubber stamp. So it may be good to have, you know, here's the minimum set of requirements. And here's some other suggestions. The sponsor should be able to come into the TSC and, you know, at least for the proposal, you know, help write it and come in and be the one who presents it. To show that they they do have some knowledge of it and can answer questions. And maybe if we're doing any kind of updates to the TSC, then, you know, the sponsor would be involved in that as well. With, you know, there could be technical backup. But but Mark, currently, the labs do not require reporting back to the TSC or in any way connecting to the TSC, at least formally. Well, the other thing that seems interesting here is we would like to say that the lab is being run by whoever the actual maintainers of that code are. And the sponsor is really more of a facilitator for kind of bringing it in, not the the primary contributor necessarily, they're really more vouching for this is something that should be, you know, pursued under the hyperledger umbrella, not necessarily something they themselves are pursuing. It does seem fair that they would be able to help answer questions or, or at least help the code maintainer answer whatever questions that folks have of them, especially the labs, maintainers. But I don't know that we should encourage them to take the primary responsibility. It seems better that we're using labs to onboard new maintainers of new projects, rather than having to maintain or the sponsors take over that kind of primary communications role. That's right. Otherwise, we're falling back to something that becomes very close to the what we currently have with main projects. And then we I think we kind of lose sight of what the whole point of having labs was in the first place, which has to have, you know, a very loose way of allowing, you know, communities to work on projects together and within the umbrella of the hyperledger, with that, the whole, you know, governance of, you know, full blown projects. I was just looking around the original proposal, the original labs blog post and some of the other proposal wiki stuff. So I think I agree with Arnaud that the, that we don't want to have a dumping ground. And then the other tension is we don't want to raise the bar too much to get a sponsor. I'm wondering whether what might be missing is, if we want to make it relatively easy to launch a lab project, then that's fine. But do we leak labs projects? Like, there doesn't seem to be a way that they get cleared up in activity. With normal projects, there's the status kind of spec that describes process towards end of life. But if we're satisfied that we can avoid a dumping ground by cleanup, then maybe we don't have to worry so much about sponsor requirements. So that's a good point. And the labs reported before, I mean, the lab stewards reported before, and we are just talking about having another report, putting a report together for the TSE. So we do have this kind of overall, you know, monitoring made by the labs. And I have to, I have to salute Tracy, who is really on the forefront doing most of the work. Yeah, and I was gonna say, I think in our original charter, we did have a, if something has gone inactive for, I think it was six months, then we do archive it, right? Obviously, after having a conversation to find out what's happening. But I think there is an archive mechanism, we've created an archive directory already. But I don't think we've been out there for six months yet, right? Because we've only done the one quarterly report, we're talking about the second one now. So I think with the second report, we can see if anything is inactive, right? And then have start to have those discussions around, should we be archiving this particular lab? What do we post the typical metrics that we're using for that? Is it complete in activity for six months? Or and are we doing any type of regular check in with the people to see what's going on with them as to why it hasn't occurred? We don't do regular check ins with our labs, and I believe if that was, that was intentional because we didn't want the overhead. Exactly. Exactly. And I think that we had, I think we were only looking by commits to answer your other questions, Samona. Okay, all right, thank you. So why are we even talking about archiving? If we don't have additional overhead on this, then, you know, if the project is silent for a while, it could very well be revived later. And if we are not spending any cycles on it, either in time or anything else, then why are we talking about archiving and all this other stuff around archiving? Because currently, the labs were an area to have very little governance, except for the presence of the sponsor to say yes, the lab is good to go. Yeah, I know the reason why we use it is it gives us a way of being covered by the hyperledger development agreements that we have, right? So it covers intellectual property and all the rest of the stuff. It gives us a way of doing collaborative development for kind of speculative work. That's, that's its value to us. And it's been perfect for that. Whether or not a real project comes out of it is a separate issue. But what is, do we have, and I've looked for this a couple of times, do we have a list like a wiki page that's just a list of projects? Because the only the only other way that I would say, you know, there's a difference between archival is that, you know, there's a list of these are the ones that have commits in the last six months, these are the ones that don't have commits in the last six months, have fun. So on GitHub. But there's nothing, there's no references to the list in the wiki, right? I don't think so. I couldn't find it, but no, you go to the GitHub lab space and you find what's there. And that's the only thing. Yeah, okay. But the other thing I wanted to point out, you know, we don't really have a problem we're trying to solve here. The only problem, you know, if anything is there is absolutely zero definition today of what a sponsor is. And it does raise, you know, it has led somebody to say, Oh, can I volunteer to be a lab sponsor? What am I volunteering to? Which is a fair question, right? But so I don't think we should go crazy on trying to put this under heavy control of any form, because today we don't have a problem of like too many labs at two, you know, too many labs not functioning be dormant or whatever. And so it's always time to increase control if we need to. But I'm happy to try to be, you know, lenient in and say, No, let's keep it simple. Right now, we have had people who have volunteered to be sponsors. I don't know what their expectation was. I did, I just did one. And, you know, I've helped these people. And, you know, I did some of what's listed there. But primarily, I was like, Okay, I had discussion with these guys, I know, I know where they're coming from. And I know that it fits within Hyperledger. And so I just said, Yeah, you should do this. And the second we use it as sponsor, I said, Yes. And, you know, because I did some kind of assessment. And I feel like, Okay, this is what's expected of a sponsor. I don't have expertise in the project whatsoever. So I would be uncomfortable if now I'm being, you know, asked to do reporting and all that. That's all I'm saying. So I think we support, I think everybody supports that view, which is that, you know, we put some verbiage in our charter about the sponsor's initial responsibility, and then have suggestions on additional responsibilities. But now I'm seeing on the chat hard saying that labs towards role is to enforce the quality of the projects. So, you know, now it's it's become a wider conversation. So that's just what I had assumed. I don't I mean, I don't know if this has ever been codified really well. I don't think we've ever had to to kick out a labs project, have we? We have prevented labs project from coming online, especially there was at least one, right? Yeah, yeah. Actually, there were multiple. One was the ID um, what do you call it, a project that was brought by the Italian group. And we, and I'm supposed to be the sponsor, and we said, look, you have to follow these rules. And then we never heard back from them. But we haven't kicked out a project yet. No, no, no, no. In fact, I think we shouldn't kick out project because that immediately brings in, you know, lots of different governance rules. I mean, inactivity is one thing, but judging the quality of the code and whether it is fit for purpose and whether it can be deployed and all that. I mean, that's a completely different animal. And that, you know, I don't know what almost views on that are, but I don't think the labs towards should take that on right now. Anyway, Alright, so we're just about done. We've got about 10 seconds left to our meeting time. So maybe I don't know if we've been, we should take this back to the lab stewards with kind of this additional input and see if we can come up with just a verbiage for what goes into the charter. I agree. Okay. And so, yeah, we'll hold off on the project versus sub project until our next meeting. And again, Explorer and Composer updates should be the next meeting that we have. All right. So thanks everybody for joining. Thank you. Thanks a lot. Thank you. Thank you. Thanks. Otherwise, have a good day. Bye bye. Ciao.