 and kick it off and get started for the day. Welcome everyone to another edition of the Hyperledger Technical Steering Committee. As always, everyone is welcome here. Please feel free to voice up at any time if you have any comments or questions or concerns. Hopefully you've all had a chance to read the anti-trust policy notice. So we will just move directly from that into the announcements for today. So I'll pass it off to Solana to talk about any announcements. Okay, so we still need more mentors for the internship program. And if y'all can help suggest anyone or spend some time with me or men on that, please let me know, or if you've got any suggestions in regards to it. Several of our members of our TFC members have been mentors before. And so does anyone want to, you know, encourage anyone else in regards to signing up and doing it on this call? Trying to sit there and see who we've got in here. About previously being mentors. Okay. The other thing is we had our first quilt reboot meeting. It went pretty well. The people who were originally in charge of the quilt, who are currently the quilt maintainers, were super happy with it. And we're planning our next one for next week where we're going to be bringing in, hopefully, Silas from Burrow and some people from the architecture work group to talk more about the different structures because there were some different pieces that were coming out. Some of them were like, are we just gonna expand out in a ledger protocol to be more languages or are we going to go and look at some of the other protocols as well? And it looks like the group is also going to be looking at some of the other protocols as well. And we need to make sure that we don't accidentally over scope things. So we're working on that currently. Any questions? All right. Thank you very much for that. We will proceed into the quarterly reports. So first up is Hyperledger Burrow. So, Sean, do you mind? It looks like most of the folks have had a chance to read through that, but maybe if you could just hit on a couple of the key highlights of that report, that would be appreciated. Hello. Yes. So since Silas is not able to attend today, I'll be covering for him. Just open up the page. I'll paste this in the chat as well in case anyone needs that. Thank you. I was actually looking for that myself. Okay. So we've had a couple of releases, but most of them have been fixes that we needed. However, in the meantime, we have been working on some new features. So one of those is Dump Restore. So we want to be able to introduce back as incompatible changes without losing account and contract states on the chain. So we can now dump the state of the chain to a file, and then when you create a new chain, you can specify the dump from the previous chain and it will create a new genesis which includes the state from the previous chain. So we can introduce back as incompatible changes that way. So when you dump the existing chain, that will include the height which is done and the hash for the state, when you create the new chain off the dump, then a new genesis will be created with the appropriate hash for the state. So there is some way of checking that you're back at the previous state. There is a plan to create a fork TX to mark in the previous chain where a new chain will take off and what hash it will have. But that's just a plan that we haven't implemented that yet. We've also done some fixes to our proposal mechanism. This will allow you to run a number of transactions in proposal mode, which means that they'll be recorded and executed. After that, it's possible to list the existing proposals and users with appropriate permission can vote on the proposal. And once it's reached enough votes, it will be executed automatically. So that's two big features we've been working on. We've started to look at storing ABI's on borough side. So rather than having as files, they will be stored on chain. This is making it much easier to interact with contracts. If you know a contract address, then you'll be able to retrieve this ABI and then it will be much easier to call functions of contracts. Client side wouldn't need to know anything apart from the name of the contract. It wouldn't need to know it's ABI. We're also planning to implement some premises for token economics. So we'll be working on this. Okay, so yeah, so we, I suppose it's working on a facility to Aspen compiler. So as that progresses, I'm also starting to look at having a wasm VM in borough. So when those pieces come together, then we'll be able to execute facility as wasm in borough. So we've had some contributions from folks from IBM. So we've had some bug fixes. So it's good to see more contributions from the outside. Sorry, yeah, sorry. No, that's a good overview. I had one question maybe for you, Sean. Just on the EVM and the WebAssembly stuff, is that, are you intending for EVM to continue to be the sort of smart contract language for borough, but it maybe would have a different execution engine with this WebAssembly VM? Are you intending to support sort of more native WebAssembly bytecode? So do you mean, do we intend to replace the EVM as engine with the wasm engine? Right, right. Yeah, do you intend to replace the EVM with WebAssembly? And then also what is the higher level language that your user base will be using? Right, so the language will still be Slidity. The existing Slidity compiler doesn't, cannot produce wasm at the moment. So as a side project, I've started the Solang, which is a Slidity compiler written in Rust, which will output wasm. So at this time, you say it's still a prototype. As it matures, well, I kind of have to wait and see where we are. But the intent is, we're hoping that at some point the EVM VM will be replaced with the wasm engine. Okay, great. Thank you. Have you guys considered making a Solidity plan for LLVM? Because if you get just a Solidity front end there, you should be able to output wasm on the back end. That's how so many languages are compilable to wasm these days. Sorry, so my Solang compiler uses LLVM. So all it is is a Slidity parser and then the ACSB sort of converted to LLVM IR. The reason that I can sort of progress out fairly quickly is because LLVM provides so much and I need to compile to wasm it knows how to write wasm files. So in actual fact, there isn't, code-wise, it's much, much smaller than existing Solidity compiler. Oh, that's exactly what I was asking about. Sounds like you're on it already. Yes, have a look at Solang. It's a code-based isn't that big, it's fairly readable. Okay, great. Are there any other questions for the borough project? Well, I saw there was a black stone. I have to admit, I looked a little bit, I don't know how much there is in there. I can't say that I fully understand, but it claims to be interesting to bunch up for the projects and so I would like to know more, but what's in there? We don't have to do that now, but. Okay, so, right, I work more on the borough side of the company. Blackstone is another part of the company and this is an API for running BPN on the blockchain using Solidity and this will allow you to implement legal agreements on a blockchain. As is written in Solidity in principle, it should run on anything which uses Solidity. I think Solace might be better suited to give a brief overview. Yeah, that's fine. Yeah, I'll post a few links in the chat to things that are of interest around this. I mean, there is a link to Blackstone. I had a quick look, I can't say I spend a lot of time, so maybe that's my fault, but it wasn't completely clear to me what's in it and so I would have, at some point it'd be nice to have some kind of high level intro. Okay, yes. So Blackstone is a part of that. We were hoping to make part of Hyperledge at some point. So it will allow creation of a legal agreement where you have multi-parties to an agreement. Yeah, and I read that much and that's why it got my attention from where I stand, which means I don't understand much of this space, but it makes me wonder, so how does that compare to what Klaus is doing, for instance, with that core project? Okay, yeah, that's an interesting question. I'll discuss with Salis and we'll maybe try to find ways of presenting this to the group. Yeah, thank you. Thanks for the update there, Sean. We will move on to the Hyperledger Performance and Scale Ability Working Group update now. I do know that Mark is not here on the call today and I wanted to reach out to see if there was anyone else from that working group that could maybe just give a quick high level update of the progress in the last quarter and then also open it up to questions after that. So just looking here, I see Mick, I don't know if you've had any chance. It doesn't look like there was a whole lot of activity in the past quarter, but didn't know if there were any issues that anyone that participates in the Performance and Scale Working Group wanted to call out before we open this up. I haven't been active lately, but the one issue in the update and then the comments was the whole discussion around the meeting they had with SAC and the potential to collaborate on a more formal benchmark by actually working within that organization and raises a number of questions about how does this actually work? Do we have to have legal agreements between Hyperledger and STAC and are we creating a standard benchmark or are we just providing input to what the STAC working group, if it was formed, would actually produce? So I mean, I don't think we're gonna get to the answers on this call, but I do think that it's something we need to seriously consider. I mean, at the end of the day, we can either get my position would be that either we can get involved and try and steer it in the direction that we think is the right direction or we can wait for somebody to come up with a benchmark that nobody likes, so. Yeah, I think, I wish Mark were here because it'd be a good, I think this is sort of the discussion because that group has matured enough and given the activities that they have, making sure that they are somehow connected to the rest of the organizations that are thinking about performance benchmarks and standards and those who are actively involved in it. So Mark and I were exchanging some emails about NIST being one of those that might be an appropriate one given their interest in blockchain, for example. One of the questions that I had there is how aligned has the PSWG been with the Caliper project? So it seems like that's a natural part or natural fit for actually reporting out on those metrics and I didn't know if there's been collaboration there recently. Sounds like maybe there isn't anyone from the Caliper team at least that is sitting in those meetings, is that a correct statement? Yeah, I think, Kelly, maybe what we wanna do is if Mark's on next week, we can just sort of key up a short discussion around this. Not, you know, maybe full update, but I think it'd be worth a lot of time. Okay, that sounds great. Are there any other questions, at least in the interim, for some of the members of the PSWG? Okay, well, then we will close out this quarterly report. We can always bring this as an agenda item next week just to talk briefly with Mark Hanne as well since he was unable to make it. So we'll now move to the discussion topics. So if you wanna introduce the various discussion topics. Sure, one is going back and revisiting the incoming freight work skylines. This is something that my staff needs because of the fact that we do keep having different code bases being proposed and we need to be able to talk with them in a more informed fashion in regards to additional frameworks. It kind of helps in regards to the screening process at the very beginning. So one of the things that I did is per, I believe it was Vipin's request. I took the new project proposal template and made it into an editable document so that people can add comments easily. And then I can go back and put that into when people are actually making those projects submittals some language about frameworks versus apps versus all of that kind of, all the different stuff that we've been discussing previously. So did you want me to go further or just that topic? So I think that's good. Maybe we could just open it up and see. I haven't seen a lot of activity on this on the mailing list. So I was just curious maybe in real time if anyone had some thoughts about topics or criteria that should be included in the sort of new top level proposal. I think on my end, one of them is really around is this a sort of multi-stakeholder type project? I think now that we have the labs, we sort of have a place to incubate and grow more stakeholders. So that would be one that I would want to consider adding is do we have a diversity of companies or at least two that are working on this project? I think for the vendor diversity, that's where we're trying to address that issue. And it is one of the qualifications that we talk about in the project lifecycle documentation. But this was a little bit more about clarity about what is a frameworks and what will the TSC be considering in regards to frameworks going forward? Because the fact that we do have fabric and sawtooth in a row hot. Yep, yeah, this is Chris. I mean, I struggle with this one because I think, I think no matter what type of criteria that you come up with, it's not gonna be correct. I do think that the diversity aspect is the multi-stakeholder is I think fundamental. And actually we were chatting yesterday with Brian with a group that's gonna announce today. I don't wanna steal their thunder, but that they're considering open sourcing some new capability. It's pertinent to fabric, but I suspect that maybe it could be applied to others as well. And yet they're like, so what do we do? Do we do top of a project? Do we start it as a lab? And I think Kelly, to your point, I think maybe the labs start as a lab if we demonstrate that there's diversity and interest and it's growing and then reaches that threshold that we're looking for, then maybe it's like Ursa, it comes out of the labs and then to incubation. And maybe that's the sort of the process rather than trying to have the staff or somebody sort of predetermine whether or not it meets some arbitrary criteria. For the most part. Well, I mean, again, I think what Brian was looking for potentially was, oh, it has to be something that's unique and we don't really have something like it. Well, okay, possibly, but then again, how do you get the code base into a place where we could then start sort of consolidating and bringing things together unless you actually provide a place where they can do that here within Hyperledger with the appropriate licensing and so forth. We meet with people who do wanna bring code, the very first suggestion that the CIT makes is lab first and to sit there and to do the lab and to sit there and see if they can get the vendor diversity and all the other different aspects first. But in regards to the frameworks, I think that ends up being a little bit more about what Brian's talking about in regards to uniqueness and that we don't wanna become. And this is me being cynical, but a dumping ground for a lot of these ICOs where they've gone and they've created some roll their own blockchain sort of thing and now they don't know what to do. So now they wanna open source it. And so it is kind of to help us a little bit with some of that. But yes, we definitely try to direct people to the labs first. Right, and we actually had an incident, right? I think maybe just before you joined, somebody was going to open source their thing and bring it to Hyperledger and then they proceeded to immediately go bankrupt. So it was exactly what was gonna happen. Maybe the question here is, maybe the status quo should be that you go into the labs prior to, I guess, incubation and then maybe really the question here is, well, in which cases would you switch or like skip the lab step, right? And I can see if you've got a diversity of stakeholders, there are obviously established projects out there like Quilt, for instance, that was bringing code and stakeholders along with it. And I think that one made sense to move towards a top-level project, but maybe that's really where the discussion is, is in what cases would you skip the sort of lab step? I think the one sort of nuance there is that obviously the labs does not provide either both the marketing as well as the sort of tools, right, in terms of JIRA and Confluence and what have you as the incubation projects. And so I suspect that it can be more difficult to actually grow a community without some of those marketing resources. And so I think there could be reasons that projects we would say, hey, you should skip the labs and this is unique enough where you've already got enough, you've got a small contributor, small diverse contributor basis that maybe you've already satisfied that. How hard is it to move like the code basis from a labs project over to a full project? Trivial, it takes me about two minutes. As I say, that wouldn't be bad. Yeah, even for a big project, getting them started there, getting all the infrastructure in place that's necessary and then do the conversion is not a bad thing. So we did this for Ursa. It's not too bad to move, but people were pointing out about the tools. And it was really painful not having some of those tools for kind of the last month or so, Ursa was in labs. I can relate to that. Yeah, and maybe this is a question for the Hyperledger staff is are those tools something that could be opened up to the labs? I understand that there is some maintenance there, obviously in terms of setting up and maintaining the wiki and the giras and all that sort of stuff, but for those that wanted, is that something that could possibly be extended? So that's one less reason for people to be looking for a top level project. Yeah, I think people would be much more happy starting in labs if they got some of those tools to start. So, I mean, we say got some of those tools and some of them doesn't cost anything to add another project, right? Jira Confluence, you just create another three-letter acronym or something for Jira and for the wiki, okay, you create a wiki page and child off, children off of that. That's not like additional work that the IT staff has to do other than maybe to add people's accounts and stuff like that. But I could see the case of something like CI where, yeah, you can add Jenkins jobs and so forth, but then now somebody is helping to maintain those Jenkins, the JJBs and the pipelines and so forth, as well as then there's some cloud resource that's being consumed to support the ongoing CI. So that actually does add to the cost of operating. And so maybe there's like a happy balance where we can let them use the wiki and so forth and Jira, but for CI, they have to use Travis or something. Yeah, Jira is not free. I want to push back on that. The number of tickets, the help desk tickets that we've gotten for people who want special, they want status has changed, they want new workflows, et cetera. It's a constant flow of tickets for people who want changes made to Jira. So even if we have create a Jira project, yes, that is trivial, but nobody likes to default workflows, right? And everyone has special groups, so it's not a zero cost. So the cost that you're talking about is our maintenance cost for doing what everybody else wants when they're coming in. Absolutely, yes. Yeah, that makes sense. The other one is my guess is, especially if we start in labs and start having every labs project have access to it, you're gonna end up creating a bunch of orphaned projects as part of that as well, so. Yeah, and I think the one other piece there that is potentially problematic is, is this marketing component, right? So if suddenly you have Kelly Coyne sitting right along whatever Hyperledger Composer or Hyperledger Fabric or what have you, right? Part of the reason was the labs was like sort of, hey, you don't get this full marketing piece until you prove it. And so I think by putting them on the, maybe we have a separate lab section in the Jira, the confluence, but that's just one other consideration that we should have. Yeah, I mean, I don't think the labs groups need marketing at all, but it might be good to allow them to sort of. Don't get any. To ask for some of these resources? I don't know. I think there's a, you know, there's a lot of variance between how involved and how sort of active lab projects are, so. I say we stick to what Github gives you, and that's it. I mean, we cannot talk about it. Yeah, I would say that if a group is getting close, it'd be okay to get them some rocket chat channels or a mailing list, or I think some of those collaboration items are helpful to get the project proposal over the finish line, but I think it should feel a lot like what happened with ERSA, where you're showing some progress towards moving out of labs to get some of those tools. Yeah, I agree. This is Leonard here, more than everyone. I think based on the lessons learned at what I'm hearing from everyone, we really need to sit and put together or work on a standardized tool set for the lab. It's a development environment, and therefore it needs a minimum set of tools to facilitate development in that area. It's not an incubation, the project's there, but they are being developed and looked at and amended in some way. So based on the lessons learned today, I'm sure we can come up with a minimum set of tool sets. And where additional capabilities are required, we also have a process that needs to be justified to improve to get any additional capabilities in that lab environment, very dependent on the type of project and the needs for doing so. But it's something doable and put together a standard set of tools for development based on our experiences today. Thanks. Yeah, thanks, Leonard. And maybe that can reduce some of the burden on hyperledger if maybe lab's projects are, you get, you sort of get what you get, right? You don't get to modify the Jira workflows and tags and that sort of stuff, but that may be a possible way forward. I would hate to spend a lot of resources on, from the get go. I think what Nage was saying earlier, that's a bit more reasonable to me. It's like, and maybe there is a middle ground, right? It doesn't have to be, they are close to being moving to incubation, but you have to get a feeling that there's a real project going on before you can invest resources in this. Because I mean, quite frankly, that was part of the deal is we made the threshold to enter into a lab, to create a lab pretty low, which means a lot of labs may not pan out and we shouldn't invest resources for just blindly. Sure, I was just wondering if there would be some way that labs could ask, say, the TSC or somebody for these resources. Yeah, so you were saying they could make the case that they deserve to have that kind of resources made available. Yeah, this would have been really nice for Ursa if we could have gotten some of these things like a month earlier. Yeah, that might be reasonable. Yeah, that might be reasonable as the case by case-based. And that goes back to also, if we're trying to push projects into labs before they come up for consideration for incubation, that would also provide a means to get them enough of the resources that we could do a serious evaluation. Yeah, I would say that seems reasonable as well. Maybe just before we jump on to the next topic, I just wanted to just ask very briefly if anyone had thoughts around what criteria folks think is reasonable for skipping labs. So are there any sort of must-haves that you think would need to be part of a proposal if it were not to go through labs first since it sounds like we're somewhat converging on. Lab should be the default. I think the principal criteria for me is it coming in as a multi-vendor active project or is it coming in as a jumpstart from the beginning? If it's coming in as a jumpstart from the beginning, it should go through labs. If it's coming in with an active community that's taking some existing multi-vendor code base and adding it to a hyperledger, then I think we can skip through that. Do you want to have a quick slide? Go ahead. I think we're going to see one more track that I think will become more common and that is I think we'll see projects that have been incubated within existing projects. I think some of the projects we have that came out of the fabric community meet this criteria where it may not have been incubated directly in labs but it might have been incubated as a feature in Sawtooth that is now kind of grown into its own project or a feature in one of the other frameworks. So I think whatever we kind of write up as a design here should probably also account for that case as well. Yes, and I thought last year we had some form of a template proposal in place or considering, you might say, requested projects for lab implementation and that would also have a checklist to go along with it to determine if that, well, the level of stability for that project and whether we would accept it to become a lab project. I thought there was a template proposal of some sort, correct me if I'm wrong here, but I thought that's how we were started last year. Was that about just a proposal for to enter into incubation? Was that what you're saying? No, for the lab itself. Oh yes, there is a template for the labs. With a checklist, that of course process being what it is can always be improved and should always be improved. So we should look at the checklist and see is it sufficient today for some of the projects really that adjust you might say an idea but does not have that solidity based in terms of support and back-end to become a fully fledged project that will be sustainable. So I think we need to look at the checklist associated with that template proposal and bring it up to snuff, so to speak, going forward again on best practices and lessons learned to date. Okay, thank you. So I think because we only have about another 20 minutes here I think we should move on. I think the key things that at least I've heard is that many folks believe that labs is a reasonable default starting point. If a community has an existing code base and an existing community around then that could be a reason to go sort of straight towards incubation. And I think one of the unresolved sort of issues is to what extent do labs projects get access at least to the collaboration tools. And it sounds like one potential path forward on that may be that they're not granted those from the get go but that they could come request those from the TSC. So I just encourage everyone to follow up on the email threads that are posted here. I think this has been a great discussion and I think we resolved a number of issues and got some good conversation out of it. Moving on, Selona, do you wanna talk about the next couple of discussion topics? So the next one and Arnod put in a good comment in regards to this about how it should read the role of the lab sponsors. And his proposed definition in regards to it as to what we're doing in regards to sponsors and what we expect out of them for the labs. This kind of rolls into the topic as to what we were just having because this is probably our biggest gating function is that they have to have a lab sponsor. So I don't know why I don't see the comment. I mean, I see you see it on Zoom but when I look at the page my comment is gone and I don't know indication there's even a comment. So I don't know if it's just me or the people who see it. I'm sorry, I don't know. We're hiding it from you Arnod. You see it, Mick? I don't see it. I have not looked. Did you put it on the agenda? Yeah, yeah. Okay. Well, I think I can see it all the way in Canada. It says the one that says on the Arnod they should read the role of the lab sponsors. Do you see it from the webpage? Yeah, I don't see it from the webpage. I see it from the webpage. If it's been commented. You just click on the yellow and it pops up. It's hidden. If you click on the yellow then it'll pop up and then you can see the comment. All right. Okay, I see how it works. Yeah, yeah. All right, thank you. We are learning the new Wiki at the same time. Yes. Well, that's nice so that I don't have to just put my comments down at the end. I can actually inline them. This is good. And now that we have this proposed definition up, I suspect not everyone's had a chance to read it, but perhaps everyone could just quickly read this and see if they have any feedback on this definition. And I am screen sharing it so that you can read it. But if you notice you can also go underneath and put additional comments there too as well on the inline. And you can put comments at the end of the document too. Yeah, I think it's, I guess from my perspective, I think it's a good definition. That's been consistent with sort of my view of the role of the lab sponsors there. Any other comments or feedback on Arno's proposed definition? That's good to me. If there's no other feedback, I suggest we move on to the APAC bootcamp topic. By the way, so is that approved? Should we just go ahead and, I think it would be good to have a resolution that we can add that to the lab description. I don't think that we have, if this is, I'm not sure that this is something that really requires a vote. So I would suggest that we move forward with this. We don't have quorum today, I do not believe. So we can do an official vote, but my recommendation would be that I haven't heard any objections. So I would suggest that we move forward and if there are objections, we can readdress it, but this seems like an appropriate definition to move forward on. I purposely haven't gotten super formal on the lab definitions. If you notice in the Wiki, the project lifecycle cannot be altered without a vote from the TSC. But in regards to labs, I think we're trying to be a little bit freer on that. So if we start making things more official, I think that might slow us down a bit. Yeah, agreed. Okay, so we can note that we're gonna move forward with this definition, but it wasn't voted on and if anyone has any objections, we can talk about those. Thank you. Okay, the Hong Kong boot camp, we, I don't know how many of y'all are up to date on it, but we opened up registration and we're filled in less than 24 hours. So I actually held back a fair number of seats. For that reason, we're also talking with the venue about expanding the number of attendees for it. So that we can, you know, because I did hold back spots for all of the, the session leaders, all the people who are leading the sessions and things of that nature. And then Julie and I are actually going through and we're gonna go groom the wait list to sit there and see who really must be there to get them all in to the event. And the sessions are now starting to fill up so that we've got a lot of different representatives from the majority of the projects that will be attending and doing their onboarding. A number of the projects have gotten really into it and they're actually creating reusable materials for the other boot camps. So even when the maintainers themselves can't attend the boot camp, they will have the materials ready so that someone else who's in that region can actually use their materials for it. And we're looking at translating some of those materials as well. So it's looking really good. Any questions on the Hong Kong boot camp? Okay, the contributor summit, I'm still in a little bit of a holding spot right now in that I'm talking still with events for location and I haven't heard back on that yet. Similarly with the boot camps in India and Brazil, though it looks like Brazil is probably going to be around the May timeframe because it'll be one month after Brian goes down there to visit and kind of rallies the troops. I can't get one ready, I don't think for their visit in April. But right afterwards, I think would be a good time to capture that energy that they've inspired. And so we're looking into that as well. On the contributor summit are you also looking at potentially appending this onto the member summit in Japan? Not currently. I was wondering if I was gonna suggest looking at having a one day of un-conference instead so that we can take advantage of who's there but not necessarily force everyone to go to two events. Okay, I think one of the things I recall hearing in last week's meeting is that there is a desire at least among some of the members to have that be a single event, both from sort of getting it approved from work but also just less travel for them. So I'm not sure if that's something that is worth discussing more here or if anyone has any new opinions on it. Certainly I think it would be my preference. I think it's easier to get a single international trip approved for a few days longer than multiple international trips. We were looking at the contributor summit, by the way, being in Canada. So not as difficult for the majority of members, but yes, all travel is always international travel. Okay, so maybe that's just, I know I think Brian had said in the last meeting we can look at doing that at a lower cost location like a university or something to that effect in Japan. So maybe worthwhile seeing if there is an option like that in addition to the Canada option. We should talk to our friends at Soar Mitsu because they may have some ideas. They're connected to Tokyo University. Yeah, so the Roha team might be able to help us out there. Yeah, I mean, I think we could also reach out any fee. They are steward on the sovereign network and have been involved in the sovereign community. So they might have some ideas on what could help there. Yeah, we can talk to people too. I mean, Brian said that I think the member summit was gonna be someplace like a little off the beaten bath in Japan. But if we're already gonna be in Japan, we could do a few days in Tokyo or something like that for a contributor meeting where we would find probably it much easier to get meeting space. I think the member summit was already in Tokyo. The member summit is, we had last week was, is it possible to have the contributor summit either just before or just after that? Because most of the maintainers are going to wanna be going to the member summit anyway and that would be one less trip to have. Okay, it sounds like there's some potential pass there. So perhaps some of us could, so maybe we can work offline and just have a conversation with Brian as well as to the feasibility of that. I know that there has been already some existing work going on for to have it in Canada, but it sounds like there is a preference for many folks to have that as a single trip. All right, and then I think the last update here under the discussion was around the election of a new chair for the Learning Materials Development Working Group. The Ask by the TSE, Bobby had nominated herself for that chair. The Ask by the TSE on that was for her to send an email out to the working group to see if there was anyone else interested in running or if anyone had an issue with her assuming that chair roll. It sounds like that is not yet happened. So this will be an agenda item that we'll push into the next week. Yeah, she hasn't sent the email, but there is another person who wants to be her vice chair that's also been regularly attending the meetings, but it's only been three to five people who regularly attend the meeting. So she does need to send something that's an outreach to the group in its entirety. All right, fantastic. Are there any other announcements or discussion topics from the Hyperledger staff? From the Hyperledger technical community, does anyone have any opens or items that they would like to discuss before we adjourn? Right, well with no objections, I will move forward with ending today's meeting. Thanks everyone for joining today. Appreciate all the TSE members getting in and marking the check boxes and reading the reports and updates in advance. I think that was really useful and gave us a good amount of time to discuss other topics. And Solon, I think you and I can chat offline. Maybe we can just look at maybe bringing in Hart or Dave or others to look for space in Japan and let's look at the feasibility of perhaps bringing the members and contributor summits together. All right, thanks everyone. Have a great day.