 Good evening, good afternoon, everyone. I'll remind you of our antitrust policy. I'm sure this is burned into your retinas. Don't do anything I wouldn't do. So on TAP for today, we have our usual reminders, TSC election process, nominations come out, or start, I guess, on the 9th. That's correct, right? That's when people send them to you, right? And Tracy? Yeah, that's correct. Yeah, right. So today, we're going to get an update from Iroha and IC Alesson. So either here in Nikolai, I guess, is going to give the update. And then Health Care Working Group, do we have an update? Yeah, that did come in yesterday. So we should be good to go there. Awesome. And TWG China and IC Valois on. So awesome. And just as a bob, just as a, before we get into this, we didn't have any updates scheduled for next week. And I don't know that there is going to be anything for the agenda, especially if we get all these done. And so I want to just sort of get a sense of the TSC as to whether we should maybe cancel next week's, give everybody an hour back, thoughts on, I mean, is there anybody have any agenda items they plan on submitting for next week? I don't have anything in mind. All right, then I suggest that we will cancel us in an email and remind everybody and Todd or somebody will cancel the invite. OK, so Todd, do you want to get going? Sure thing. So a couple of quick reminders. Next HackFest, October 3rd and 4th. We've already seen a lot of folks register, so that's great. If you haven't yet, please get registered as soon as possible. We are planning for the next HackFest in APAC, likely Hong Kong or Singapore, kind of trying to figure out January, February, March. Avoid the Chinese New Year holiday and whatnot. But we'll let folks know once that's firmed up. And then we'll be bringing that back to Europe probably April, May, June, somewhere around there. Beyond that, the other pressing agenda item is the annual TSC election. We've talked about this the last few weeks. We have pulled together the eligibility list. We continue to update this in real time. But please check to make sure that your name is showing up on there. I will drop this into Rocket Chat in just a moment. In a second. So on this, we're including labs. We're also including, similar to last year, the work groups under the TSC. So the work group chairs are providing us names and emails of those that have contributed. So please just double check the first tab, the master tab, make sure your name is on there if it should be. And correct email. If it's not, please get in touch with both Tracy Kurt and myself. As of 5 PM on August 8, we will consider this final for the election process that the TSC approved. And we'll get nominations kicked off on August 9. Hey, Todd. Just a couple of additional comments on that. There are quite a few no reply email addresses that are coming from GitHub. So if you are one of those people who have a no reply, I'll also let Todd or myself know. And then I did reach out to everybody who had multiple email addresses yesterday. Please let me know which email you prefer to use for the election purposes. Do you want email addresses, as well as names from the working group? Or do you guys have the email addresses? I have a list of names I haven't sent you yet. But I don't. But both, please, if you're struggling to find a couple, we may have them. But both is preferable. OK, we'll do. Cool. From the working groups, the only way to find those email addresses is to look through the mailing list, because there's no other way to really. I mean, we had contacted people to have them contribute their email addresses. But last year, we combed through the mailing list. And that's how we found the email addresses. It's not as obvious as the GitHub contributors, because there is a GitHub username and a email address associated with each. We'll get it figured out. We'll help you out. Just get in touch with us, and we'll get this done. Don't worry. As far as nominations for the TSC, I had somebody ask me a question. And I think it's just you self-nominate yourself, or somebody else can nominate you. And you send that bio-pitch, which I guess is maybe optional to write that up. But it's just a note to what, the TSC list? Yeah, we'll send out instructions. But yes, it's effectively an email to the TSC list, short bio-pitch, et cetera. It's exactly the same as last year. So I can copy and paste that from last year's Dan, and give you a heads up of what it's going to be. Great. OK. Yeah, so everybody definitely check to make sure you're on the list. And Todd, I assume that the reminder about getting on the list is also going to be sent to, like, announce or something, so that for, I don't know. Well, announce, that would hit everyone on the business side as well. Maybe just the spam all the projects and working groups. I don't want the only way that people will find out about this to me if they listen to the recording a month from now. Yeah, I mean, one suggestion is for the maintainers to hit the various channels that they're in in Rocket Chat or on upcoming calls. We've notified all of them. Yeah, but that can get missed, too. I mean, I don't have a problem if maybe each of the maintainers sends to their respective or work group chairs sends to their respective list. That's also fine, I guess. But they're not all here either. So all right, we'll figure out some other channels to keep people on. Thanks. OK, all right. So, Alish, are you on? Yeah, I'm on. Hello, everyone. Actually, I will let Nikolai walk you through the report. Will you be able to show the report? It's on the official page. And then I might jump in at the end with a few remarks and maybe some questions for you guys at the Hyperledger. Obviously, the next big thing for us is the first stable release, and then hopefully working together with the Hyperledger on the promotion. We are also expecting David to visit us for the review. Unfortunately, I did not hear back from him. I ask how we can support his visit. Hopefully, he will let us know. I'm coming. I just want to let you know I'm coming. I'm doing emails right now. Yeah, great. So, Nikolai, are you on? Yes, I'm on. Thank you. So let's go through the report, and then maybe I will jump in on a few topics. Yeah, so I'm going to tell you what's the progress of our project, which is ROHA. It's the distributed ledger technology written in C++. Since the last report, we have released twice with second and third beta. And we are going to release today our next beta version. We have delivered a two open source code base for Nakayoshi Chatbot, which helps us to connect RocketChat, Telegram, and GitHub. So whatever any of our contributors writes in one of these channels, we receive them in RocketChat and Telegram everywhere. And it's really helpful to build community that is really independent of the tools. Also, we publish our updates in the ROHA weekly digest on our mailing list. And we distribute this with Nakayoshi as well. We've got, in turn, working with the design of UTXO model. And we're looking forward to see his contribution in the code base. We have explored the possibility for Ethereum breached. And we're going to release this code base soon in open source as well. As for hyper ledger activities, we are looking forward to build a better interoperability with hyper ledger cell. And I've reached out to Vauhua later this week, I mean before. And also, we have dedicated team members participating in performance measurements, working group discussions, and metric paper. We have updated our public information in hyper ledger web page related to the project. So far, it's so good. And our final release seems to be ready in fourth quarter. So that's a brief update for the project health. We've got some issues. So we have to improve the openness of the project and diversity of maintainers and make our public design discussions more public. We're going to resolve this with process changes. And also, I think as soon as David can come to us and help us more with his experience, we're also discussing things related to tooling with Brue. We're right. I'm not sure how to pronounce his name, actually. So we're also asking Tracy and me to help us. And we think that can help with our process overall. One of the issues related to technical side is we need to build a better system for network progressions. So our next release will include network testing automation. Right now, we do this manually and well, semi-automatic. So we have to run for each release. In terms of quality gate for each release, we have to run all the scripts manually right now. And we need so-and-so to make tests and build more network simulation tests. One of the issues that is preventing us from transition that is preventing us right now to transit to hyperledger JIRA is a lack of confidence. But I think this can be resolved as well somehow in the future. And the fact that JIRA has an old version and some new cool features like split of issues in JIRA are not available. But this is just a minor thing, of course. As for releases, I've mentioned before that we're going to release in force quarter as our release candidate. And after some period of stability, we expect to ship final release. You've got some scope defined in the report that shows what else is remaining right now. Some of the items on the list are actively in development. Some are in the backlog. And we're working to improve our velocity as well. And to add more contributors. So now you can see there are new contributors to the code base. And they come with a different experience in their technical skills. Some contribute to our Java code or C++. But still they help quite a lot. And we definitely notice more interest to the project. Overall plan right now is to gather more people to contributors and use case partners, reach, quality gate objectives of code coverage and acceptance tests, increase diversity of maintainers, and just continue with time-based releases and seal release candidate. And then releasing final version after stability period. I've sent some links into each channel. You can check out our Nakayoshi boat code base. Maybe it can be helpful for your projects as well. To increase number of contributors, maybe they don't use rocket chat a lot. Maybe they would prefer to use telegram or Gitter. You can check what we write in our weekly updates. And it's really helpful to write then a summary for our release. Overall, that's it. And if you've got any questions, I would be happy to answer. Hi, yeah. Thanks for the update. This is Dan. Hi, Dan. I don't have a great way to explain what Yeroha is when I speak to other people at events. How do you pitch the uniqueness of Yeroha? OK. Just a second, Nikola. I will jump into this. So we sent the updates for the description of Yeroha for the web page. Hopefully, there will be on the web page this week. So what we think it's a key difference is, of course, the architectural approach that we don't have smart contracts for now. We are dealing with the commands. So we have two types of commands. And then we have a very great permission model, which can be used and it can serve in the financial applications, so applications of the blockchain for the financial sector. And now Nikola will probably add a few things. Sorry, Nikola, that I jumped in. But I think it's important that we update also the information on the web page. Right, exactly. So my elevator pitch is, well, I usually say that Yeroha is really straightforward and simple. So we've got built in financial and identity management capabilities that allow creation of blockchain powered application in less than, well, let's say, five minutes or something. It is trusted. So we've got a fast and highly secure consensus algorithm called Yet Another Consensus, which protects Yeroha networks from failures or adversary participants. Well, Yeroha is secure, so all actions of users are verified with high speed, independent and publicly available ED signatures. They're all supportable. So we support Linux, macOS software environment, with hardware layer, including x86 and ARM powered systems. And we really client centric, which means that we can easily substitute existing backend systems without any noticeable changes for the client applications. And we can easily integrate into mobile desktop or web frontend applications with our help of broad range of SDKs, which are JavaScript, Java, C-Sharp, and number of languages that support Rotobuf and SVAG. In short, that's it, but we definitely need to put this somewhere in a way that we are compared to the rest of hyperledger greenhouse platforms. And I think it's also really important to mention that some use cases are really better for the other platforms. And we think that our use cases are those that are not really sophisticated, and that involve a lot of mobile platforms. We were positioning ourselves before as a mobile first or mobile centric, so something like this. And it was interpreted incorrectly, something like we were the platform that is able to be deployed on a mobile phone, but it's not. We just have a wide range of SDKs, and we are easily integrated into existing mobile applications. But we will continue working on that as well, I mean, on the comparison with the rest of platforms. So just to add to this, so we. So on the mobile. Yeah, so what we did with the descriptions, we followed the structure on the hyperledger web page. So to go from the very high level description of the platform, deeper and deeper to two more levels. And the last one is a little bit what Nikolai did right now. Talk about the technical differences of the platform, but there are also two levels above that give you some overview of the platform and its characteristics. I would also like to go back to the, in Amsterdam, we were talking with Tracy about this comparison. How is this going? So that to provide on the hyperledger web page, easy to use tool to compare different or all five platforms. Are we are we planning to proceed with this or no? I don't think that we've had more progress on that front. I think there's a lot of difficulty in trying to fit each of the projects into a narrow bucket that gives you a decision tree for. So we had a long afternoon discussion at the Hackfest. And the general sense, certainly from my perspective, from others that were present was we shouldn't do this. I mean, I think the more that we try to sort of differentiate what project X, Y, or Z is from project Y, X, or Z, it doesn't. I'm not sure how that actually helps hyperledger. I'm not sure how that actually is going to help us start to be a lot more collaborative across project boundaries. And certainly the intention of the umbrella slash greenhouse was to bring projects under a common intellectual property regime, under open governance, under the Linux Foundation so that they could basically build off each other's successes and to start working towards increased componentization, potentially sharing of components like with the borough EVM and so forth, and the crypto library. And all these things doesn't really help us if we're continuing to treat these things as somehow or other competitive with one another. People should choose whatever their platform choices based on their experience with it or their confidence in it or whatever. But I don't think hyperledger should be going around trying to make that case. I don't think it's appropriate for any of us to go out there. I think it's fine to say what the projects are working on. I think it's especially important that we highlight where they're collaborating and what release they're on and all that kind of stuff. But trying to pigeonhole a platform that's, you know, I mean, seriously, it's almost a fool's errand, right? And I think that at the end of the day, it doesn't serve our purposes here. So this is my, I think that there's an implication behind your comment that I want to make sure we understand, which is are you implying that there is one platform that addresses all of these issues? I am not. I am not. OK, so then maybe focusing the differentiation on which problems is a particular platform good at might be the appropriate way. Well, which ones are they focused on trying to address? Exactly. That's exactly right, Mick. But that's a different position. Exactly. I'm just saying that there's value in differentiation, but the differences should be focused on what are they, what problems are they good at solving rather than, you know, this is a particular company's version of it or whatever it is. Yeah, no, I think that's right. And I know that, you know, and I don't know how many others are aware of this, but there's ongoing work from the marketing committee, Meredith and others to do another series of greenhouse videos for each of the projects. And, you know, it started out in the direction of, oh, you know, let's try and, you know, pigeonhole them. But instead, you know, I think that they're going in the direction of the conversation that we have at the HackFest, which is more exactly to that point, Mick, of highlighting what are the projects working on? What problems are they trying to solve, you know, and also to demonstrate how, you know, that those efforts are, you know, are valuable to the whole community and not just to the single project. So again, you know, I think it's a mindset kind of a thing, right? You know, so, you know, there's going to be continuing for the next two, three years, I think, various experiments to see how do we get, you know, consensus at scale. I say this all the time, consensus at scale with, you know, high throughput and low latency and privacy. Solve that problem and, you know, you get the Nobel Peace Prize, right, because it's really hard to do. And there's all kinds of compromises that have to be made in different explorations and how to do all those things from a technical perspective. And the various projects are working on different aspects of this total problem domain. And I think, you know, at the end of the day, we all benefit from each other's work. That's how it's supposed to work anyway. I'd completely agree on that. On that other in there, Chris, is it's really easy, I think, for people to fall into the mindset of going, okay, so you use this for that and this for that and this for the other. And it's almost like there's this mentality there of trying to construct our product line. You know, it's like a company thinking, which if you're not careful can lead you into saying, well, we shouldn't have anything which has got overlap. You know, like overlap is a sin. You know, we should have, you know, well, this is your answer for this and this is your answer for the other. But that is very much a product line thinking mentality rather than saying, well, yeah, there absolutely will be probably lots of overlap between these because we don't know. We really don't know what the answers are. So yeah, it's just a way of thinking that. Yeah, but if I go back to the discussion in Amsterdam, I think there were several ways how we can help the end users. So people that want to use different platforms, not to say just, hey, guys, you have so many choices, now go on and try them all and spend, you know, half a year discovering what are the differences. So we were discussing to give them something like the comparison that they can do quickly to see the key differences between the platforms. And I still think there are some that we can list. But then we were also talking about the Sandbox project so that we maybe provide them the possibility to try the same problem on different platforms or different problems on the platforms so that they can see how they work in reality. So I think we should continue with these efforts to somehow make a step forward to the end users that are at least in my experience, in many cases confused which platform to choose and then they just follow the mainstream, so to say, and always pick the same which might be good or not for their use case. Yeah, so I'd like to just pick up the collaborative angle there. I think that your project might be the only one that's using the Edwards curve for signatures right now. And we do have this CryptoLib project in a good discussion yesterday about a simple signing interface. So that might be something that you might want to take a look at because that would help round out the list of signing algorithms that were incorporated into that definition. At a later date, because I don't think we'll have time for it today, I would like to also better understand your not smart contracts model because that sounds like that might be interesting to interesting for all of us to understand what that looks like a little bit more. And then the third thing that they came up and the last thing from my perspective that I thought was interesting to dig in a little further is on your consensus. So I think that there was originally PBFT variant in mind when Iroha was launched. And I see that you've mentioned that you're working towards a Byzantine fault tolerant consensus in your notes there. There's another consensus collaboration in point that's interesting for you that over on the sawtooth project, there's a consensus interface that's been worked on recently that seems to be able to accommodate Raft, PBFT, Poets and a few others. So would very much like input on that. And then also understanding of course from the Iroha perspective, obstacles and opportunities on the particular Byzantine fault tolerant consensus that you're working on. Okay. And also. Yes, please. In the same spirit, you mentioned identity management as a special case. And we have in the identity paper sections dealing with different DLTs under the Hyperledger Hot House. Iroha, I just lifted stuff about a year ago from your website, which basically just said something like unique style permissions. So I would like to invite you guys to come to the identity working group and contribute on that section of the paper because we are sorely missing contributions from Iroha there. If the time is not convenient, please interact using mailing lists or any other form of communication. And I do second all of these things in terms of what this update means for the community is what we should be focused on, which includes all these distinguishing characteristics, which can inform development in other DLTs, which is, of course, very good thing to do. Thank you for the invitation. We have definitely, we'll definitely try to join. We already joined the performance working group and we tried, as Nikolai mentioned, cello. So we are looking forward to changes in cello. So we will be able to leverage on this tool and contribute to the tool in the future as well. We are also using Caliper. So I think there are a lot of common points for all the platforms. Yes, I just want to jump in really quick. You had meeting yesterday, we saw that. And I think next week we'll definitely participate in identity working group. Discussion. So as for the things that Dan has told, I'll start with the design of our smart contracts. The biggest issue was always how to deal with our relational state. And while we were designing the platform, we definitely had some trouble understanding how to put virtual machine into that. So for now, we think that the logical step in order to let users use more sophisticated API than what we provide and more customized is to provide them an ability to compose their SQL queries and SQL commands. So our vision for the next version of ROHA would be to provide them such capabilities so that they can compose something similar to the transaction processor in soltus but with means of SQL. And we also have found some researchers that were really interested in ROHA and how to make smart contracts applicable for data processing so that it can be made on a really high-scale in SQL databases. So smart contracts thing. Yeah, we definitely want to have a more customized API but we don't think that we will support virtual machine in the next release. But what we're going to do in next release is to provide our users an ability to create customized commands and queries with SQL as for a cryptography library. I've seen that you're working right now on the shared crypto library and we would be happy to participate in that but I think we're just liking resources and we definitely need to allocate somehow in between working on that because we already have our crypto library and if we had previously discussed this while a crypto library was this project was starting in lab maybe we were, maybe crypto library was a different one. I'm not sure. So yeah, and as for the third point can you remind me what was your third point? The consensus. Yes, as for the consensus we have started with Sumeragi and we understood that there were so many design so many tricky parts in design. So we decided to change this a bit and split consensus into two steps. One is let's say order consensus. That's where the consensus for ordering phase is happening and then have a state consensus or consensus of peers on the contents for the block. We delivered the first one under the name of yet another consensus and right now we're working on BFT ordering service as at the moment ordering service is unfortunately single point of failure and we are working with, I think we are discussing right now, Leveness and some proofs with the creator of P-Chain algorithm. So she's really thrilled with an idea of leaderless BFT consensus and our biggest issue right now is we just don't have enough people to help with an extensive description of how it works and we've got a draft of paper but we need to finish it as soon as we will finish with description of ordering service and with its implementation. We've got a plan to release the paper but we just need to finish with implementation of ordering service first because we need to also show results and comparison we just don't have so many main terminus. If we, maybe if we had more contributors and more diverse community, the result would be different and I think that's what we need to focus on as well so that people in hyperledger and not only in hyperledger are better informed about our design decisions, something like this and we've seen that SOTUS architecture supports pluggable consensus and I participated in the discussion in 2017. We think that in the future, maybe SOTUS can reuse the implementation of YAK but we need to look deeper into that and check how to implement this in interfaces. Okay, great. Do you guys think you could, I mean, a lot of this stuff sounds really interesting and I think, you know, it might help you get more contributors if you present some of this more broadly. So I was going to ask if you guys could give a talk on kind of some of your technical features at either the hack fest with it or at the member summit this coming October because I think that would be really useful for everyone. And, you know, just telling everyone about your features might get some people to help work on them. Yeah, actually the answer is yes because we were already on the hack fest in Amsterdam. We will probably be in Montreal and we also submitted, I think, three proposals for the event in Basel. So hopefully they will be accepted and we will be able to present this and discuss and also in addition, we are trying to record sessions, technical sessions explaining about the platform and doing the hands-on on the platform. And I was thinking, I was reading the hands-on blockchain with Hyperledger Fabric. They have very nice examples. So I was thinking maybe we can do side by side comparison. I don't know if Hyperledger would be interesting in this and if the authors would allow but I think it shouldn't be a problem for the example to be reused and then we can do a side by side comparison on how to do the same thing in two different platforms and then maybe later on other platforms can join and do the same. All right, thanks guys. Thanks a lot. This is Dave Huseby. I wanted to jump in with one last suggestion. One of the things you can do immediately to try to grow your contributor base would be to just start recording your meetings that you guys have, even if they're in Russian and publishing them because at least you'll be able to reach the Russian speaking community and you don't have to worry about doing your meetings in English or anything like that. So it's really just about getting transparency on your process, your meetings and things like that. And you can do it immediately. Don't worry about necessarily getting it into another language. And then that'll be a good first step and you can go from there. Okay, so we have two more updates on tap so I suggest we move on. So thanks guys, good update, good discussion. Next up is healthcare. I'm not sure Todd who was going to present that. I believe Nate is on for that. Nate are you there? He's on the call. Nate, you may still be here, didn't you? Yeah. Nate, you need to let me in. I'm meeting myself. There you go, there you are. There I am. Cool, so yeah, this is Nate DeNarrow. I'm chairing the healthcare working group and just to go over our update here quickly. We started evolving the group earlier on this year. We've had a few starts over the past three, four years with the group or two or three years with the group and so in this iteration, we did some organization, we did some surveys of the group to get to direction. So I feel like we've gotten a pretty good direction now. We decided to split up our activities into subgroups based around different areas of interest in the healthcare industry. And I think we touched upon that previously but very simply we broke out into a payer group that focuses on insurance type issues. And then of course we have, we also had the challenge of dealing with the healthcare system. Healthcare is different around the world. Healthcare in the United States takes up a lot of the air in the entire industry globally. So we do a lot to try to, we do pay some attention to try to balance things and not make it too US centric because given that's the organization's based and a lot of the participants are based in the United States that's where a lot of the thinking and the perspectives come from. So that's something that we're certainly paying attention to. But we have about two or three groups that have now formed and have gotten very active. We have a patient subgroup that's focusing on patient focused issues around the technology use cases. And in particular they've decided to take up this donor milk database use case. A as an important use case but B because we've also had some contributors and people that are interested in the problem. So we're starting to form some activity around that. And actually there's a potential that we might even have a code base to either build or have donated in for that particular use case. So we're kind of shepherding that newly formed group and those newly formed activities into some work product on that vein. Same with the payer subgroup. They're working on writing a white paper. So structuring the white paper, finding out use, figuring out use cases to dive into and then of course getting working on writing a paper. It's kind of the next phase that they're in. Our EMR subgroup is another one that's recently started. They have literally just recently started. So they just had their first meeting this week. And I just got a report back from them here this morning. So I didn't include the details. But again, they just had a meeting this week to organize the group and move things forward there. So yeah, I mean, and we're also a group that's starting from subject matter as opposed to a group that's starting from a particular technology or a particular project that's been donated to the Hyperledge project. So our sort of approach in our little, probably then a project that is technology-based in terms of work products, we're working on growing the group, putting out some white papers and providing some perspective and then also trying to generate some code if we possibly can. And that's one of the harder things because we are starting from a conceptual basis as opposed to again, a technical product. So diversity of the group is pretty good. We've got people that are coming to the group regularly, new people, introducing themselves. And I think once we get a little more there formed in the group, we'll have more people joining us. But we've had a pretty good turnout and pretty good effort by the participants thus far over the past three or four months since we last spoke. And that is kind of all I have in terms of update. So happy to answer any questions. Thanks, this is Dan again. On the planned work products, they'd be good to get just a little bit more specific there in the update. Yeah, it'd be probably a little bit easier to track, right? There's a specific work paper, there's a specific set of requirements and that might help crystallize more participation too. Yeah, absolutely. Now, totally agreed and that's just it. We're sort of starting from zero with the group. From earlier this year. So in terms of the progress we've made compared to previous years, it's pretty good but we definitely have a long way to go. Yeah, that's great. I do sense that there is a lot more focus now. Yeah. Any other question for Nate? Sounds to me like it's actually going fairly well. Which is good to hear. Yeah, I'm pretty happy. I mean, it'd be great if we could do more but I think given the time that everyone has and their interests and all that, I think that when we formed the subgroups and had people really itching to get going and we've had two or three people step up and choose to lead those subgroups but we've got a few more subgroups that are unled so that will be a part of the effort as well over the next quarters to get those more active. Again, it is just a matter of getting people active in these groups and figuring out a problem to work on because like I said, it's not like there's a sawtooth or in a roja or there's like some kind of platform for them to rally around. They're just rallying around ideas and trying to turn that into more products, right? Great. Any other questions for Nathan? All right, thank you. Yep. Next up is Awar. Yeah, I'm here. Well, let me post the link to the rocket chat and the doom chat. Okay, so the Awar Working Group Healthy is good including the activities and diversity and also the meeting. Now we have bi-weekly meeting and for each meeting, there are almost over 20% originally and also the work for some four areas including the development and innovation and the internalization and education and collaboration and adopted scenarios and also we hold meet-ups usually like monthly or bimonthly in those large cities in China. So you may find more details about the working group through the link I post and I would like to pay more time for the issues and for the question announcement. So in the past quarter, we have found there are three major issues. The first one is that one of our governing board person that Charlie Tsai who was from Wanda he just returned due to some personal issues. So we want to add some new person into the governing board. However, after checking with the group charter that we found that there is no definition on how to process to generate a new governing person. So we would seek in for more suggestions on how to resolve this. And the second issue is related to how to enhance the collaboration with local universities. Through our meet-up and other technical events we found that all the teachers and the students from the university are quite interested with open source technology and especially with the hyperledger. But currently there are only very few university that are some member of the community. So for those students and teachers from the university that are not a member of the hyperledger community they want to know how to contribute more to the project. So we are consider how to enhance that. And we have online meeting discussion with experts from the links foundation. And we guess it might be a good idea that we design some incentive plans like design some badge or something similar for the students contributors. And the third issue is an old problem is related to the internalization work that we have some volunteers that they feel interested with the fabric documentation. So they have made some translation of the fabric documentation. And currently all the documentation results are hosted with third party report. So it might be encouraging if we can consider to have some official like GitHub report or gallery report to host the documentation and the formalize the entire process. Okay, so that's the three major issues we want to seeking for the suggestion on the TSC. So thanks, Bawa. So item number one, sort of replacing a co-chair. I would, so we have a process. And so now the TSC essentially approves a recommendation from a working groups to for a new chair. So I think for a co-chair it would be essentially the same. So my recommendation would be that you just take a pole amongst your members as to, ask for nominations and take a pole and select somebody new and then bring it to the TSC and we can approve it. We just, we had a, pardon me, we had one, I think it was last week where we approved a chair, a new chair for the public sector working group. So I think that process is in place if you need, I think Rai or Tracy should be able to point to it where it says that in the wiki. In terms of the... Chris, thanks first for your suggestion. However, the problem here is that there's no, like a formal membership of the working group. So the working group currently it's organized in a very loose format. So we call the people like volunteers. So we cannot quite define who is the formal member to vote. But Bawa, I mean, what is the, do you actually have an issue you're trying to address? Like you have too many possible candidates and you're trying to figure out how you get to choose one? No, it's not related to the candidate. Actually, the problem is related to who it's qualified to a gave a vote. Yeah, so that problem is one that all of the working groups share, there's no participation or membership in a working group. And so it's whoever shows up. It's quite dynamic. You know, share it on WeChat and share it on RocketChat and the mailing list and say we're gonna choose between A and B if that's whoever nominates is what I would suggest. I don't think you need to have a, and then the TSC does the final approval. And I mean, it's not forever. If there is a problem, you can always talk about taking the person out. I mean, it's not different from the TSC when we started, nobody really knew each other and we just say, okay, see how that works. Usually the problem is the other way. Don't have enough people who are willing to be the chair. Exactly. That's why I was asking what the real issue is because. Right. So do you have candidates? Actually, I guess if we published the voting, there should be several candidates. Okay. Yeah. Okay. So Chris, your suggestion is that we organize some voting and that's okay. Right. Okay. Okay. So as for, I lost my place. Where's issue one? Issue, that was one. So in terms of two, that's actually an interesting one. Maybe we should take that offline and have a broader discussion about it. Maybe with Tracy and Ryan and Brian and team. It's an interesting thought to add something like that. I don't know if we can cover it today. On the third part, that's sort of on me, but again, I've been back and my concern is, how does this go forward formally for the future? And we just need to have that conversation to help me help the other maintainers of the project get comfortable with the fact of maintaining a Chinese translation when we don't have a whole lot of Chinese maintainers. And that's really my problem. So we should take this offline and have a conversation about this. I appreciate that the work's been done. And I'm sure it's probably fine, but my concern is that when it comes to technical aspects of the documentation, we wanna make sure that it's correct in whatever language. So anyway, I'm happy to take that up with you offline. Sure, Chris, I totally understand your concern and about the issue too. It's not just mine by the way, that's my point, I need help in getting the others comfortable with this. So maybe it needs to be a formal proposal or something. But I mean, Chris, I just want to point out, I mean, this might be a case where we just have to, and trust the people to do the best they can. Yeah, I understand that, but then you have a thing and then it has to be maintained and. Yeah, so Chris, do you think it's a good idea if we put the repo as a hyperlator lab repo? I would have no problem with that at all. I'd like to get it into fabric if it's not just Chinese, if it's, and we have a strong support system to sustain it and somebody to really own it. I think that's the important piece of it. The only issue is that the process of documentation translation is quite different with code contribution. So yeah, it is, yeah. Exactly, using the same repo. Yeah, problem. Yeah. No, that part I understand, but just the translation itself, I know that the various tools for that, you still have to go through and review and make sure it's correct, especially for something like Chinese because it's so subtle. Okay, anyway. Okay. I'm happy to take that offline with you. Yes, sir, thanks. Any other questions for Boa? Okay, if not, then we're at the end of job. Thanks everybody and we'll talk to you all in two weeks. Cheers. Thanks, bye. Cheers everyone, have a good day.