 a few people have joined us already, that's good. Okay, recording has started. All right, thank you. Welcome everyone. This is the weekly TSE call. It's open to everyone. Welcome to participate and contribute. There are two conditions to fulfill though. First one is to live by the antitrust policy. The notice of which is currently displayed on your screen if you're logging in through Zoom app. The other piece is the cutoff conduct which basically requires you to behave like a decent human being. I was kind of left saying this because to me that's what it comes down to. Of course it's kind of a shortcut but an experience shows these things are necessary. So with this being done, we have a couple of announcements to get started. And we do have pretty full agenda as a matter of fact. So let's keep cranking. Okay, I'll make the first announcement really short. That's okay, just take your time doing it. Click the my profile link and make sure that you can log in and see your stuff in your LFID. And this is the future of where you'll manage your LFID. So more features are coming there soon. And just please give it a whirl. And if you run into anything, let me know. Thank you. And so I have a question, Ryan. In terms of functionality, what does that really do? Is that just a UI and makes it easier to update your profile or does that have any impact on any of the systems we use? Some day it will. So for instance, you can see that I have GitHub, LinkedIn and Gmail accounts connected. You can set your forwarding address if you have a Linux.com email, stuff like that. So you can also see your previous attendance and events. That may or may not matter, but yes, in the future, this will be a more fully flushed out UI where you'll be able to do stuff like edit your information. Okay, so that's important to kind of motivate people to update their profile because that might help with some of the issues we have been having with maybe the DCO eventually, but also the election process, right? That's why I put it first, exactly. Anyway. Yeah, but you need to explain it to people. Don't assume it's obvious. Thank you, Ryan. Any questions or comments on this? Okay, here we are. Is this similar to the members thing that Mara sent out or is that just for member summit? That's distinct. Thank you. All right, and then there is a TSC election announcement. Who's going to talk to this? That is mine. Okay. So if you go to the TSC election page, that's linked, well actually here, yeah. So we'll do the TSC election announcement. So the collection of who is eligible to vote will begin this coming Sunday. And I'm going to be running the script that gathers eligible voters on a daily basis so that if people go to the page to test to see if they're eligible or not, and it shows up they're not eligible. If you have any questions, email the election at list on hyperlegio.org email. Otherwise, if it's because you haven't made any contributions and you want to, then you have until August 30th to get something in. There's plenty of bugs, plenty of documentation that needs to be written, that kind of stuff. And then the last item here is that the election at list.hyperlegio.org is meant for dealing with issues with eligibility or any questions or access or anything like that. And I'm looking for anybody who cares about our election process and wants to help out. I'm looking for volunteers. So go ahead and email the elections mailing list saying you'd like to volunteer and I can add you. That mailing list is going to be kept private amongst the volunteers because we want to be able to deal with people's personal information. Here's my email address, whatever, can you add me, that kind of stuff. So I'm just telling everybody up front that it's not going to be open to everybody. To see the messages sent, but anybody can volunteer for the list to help out. So that's the end of the announcement. And then we have an item for discussion on the election plan. All right, thanks, Dave. Okay, so. Question on the actual list. So you're not doing sort of email matching and could you maybe explain a little bit about what you're doing for that? Like I have one's eligible and one isn't. Yeah, so we're running through, so we have the scripts that we've used in the past which goes through all of our repos to gather all the email addresses. There are a few cases where we find multiple email addresses and I plan to be emailing out, there's only like 50 or so of those where there's multiple email addresses we get for somebody. My plan is to email out like today or tomorrow to each of those three and ask people or each of those, you know, multiple email addresses to ask them which one they want to use. And I will then mail merge them. Like basically I'll update our database so that the one you choose is the one that you will use. And that will be what you get all of the elections communications on. That's what will be in the check tool and that's what you'll use when you, well I don't remember exactly the condorcent login but I think you use an email. So yeah, that'll become your identity for voting. And Chris, for you specifically and most likely in the past I combined your multiple email addresses into one, specifically your Gmail one. And so that's why your other one or other ones are not showing up. Okay. Yeah, I haven't fixed the check tool yet. So like if you punch any of those in it's not gonna come up because the string value in the check tool has like pipes in it. Lots of email addresses for you, Chris. So I'm gonna be fixing that today. That's a time. Well, no, one of them came up fine. The other one didn't. Chris is fine. Okay. Folks who have multiple. Yeah, okay. Yeah. I just have to pay attention to the bunch which is what it was spam. Well, we're gonna talk about the plan later. I will, I plan to be sending out email communication to everybody who is eligible to all their eligible emails. So whichever one you receive an email about the election on that's the one to use. Chris, if you prefer a different one let me know I can make the update. Oh, okay. Thank you. Or you can email electionsatlist.hyperlogia.org. That's what we did in our queue. All right, with that being said, as Dave said, I mean, there's an agenda item specific to discussing the plan, reviewing it and agreeing to it. So let's move on to the quarterly reports for now. We got three of them actually, yeah. So Indy, Transact and the working group, technical working group, China also send a report and they actually had some interesting item to bring up. So I thought we could also discuss that later in the agenda. Is there anything other than that that anybody wants to bring up that I didn't put on the agenda? Because so I don't remember there's, as far as I remember there's nothing about Indy that was sticking out. I noticed that not everybody has reviewed the reports yet but I assume this will be done shortly. Regarding Transact, Gary brought up the point that maybe they should be folded within SoTooth if there's no other project using it. And so I actually, you know, at Daniel had a reaction to this and I thought, okay, instead of discussing it now, I'd rather bring that up as an agenda item. So it's part of discussion items for later. And the China group had specifically an issue with regard to dealing with the cryptography standards which I believe has been recurrent but also thought, okay, maybe you can discuss this on the agenda. So I don't know if there's anybody who wants to ask anything specific to this or wants to discuss any of these reports. This is the time to speak up. Do you want to create an issue that talk about this one or because, I mean, we've talked about this actually at length, right? Back when we were looking at, you know, like sub-projects and that, you know, sort of concept to sort through the, what if there's a project, you know, under hyper, not labs, but under hyper ledger that is applicable to a single other project. Now, Deno raises the case, well, what about this thing that's, you know, sort of Ethereum specific, but that's not basis specific, that's Ethereum specific. So I don't think that's a sub-project per se. But I mean, we did sort of rule, right? That, you know, where there's really only one consumer that they should work with the maintainers of the, if you will, the parent project. Yeah, the problem is they, I mean, their intent was broader than that, right? So on that basis, we created- For transact, no, I- And the question is, how do we manage this? So let's not get too deep into this now. I want to just go over the quarterly reports for now, and we can go back to this- Well, that's why I asked, are you making a discussion topic about this? If that's the case- Yes, in the discussion section of the agenda, there is a point on that. But back to the technical working group, China report, is David on? Yes, I'm here. Okay. I thought you wanted to highlight a few things you said. So this is your chance. Yes, actually, beside of the kind of quarterly reports, I dropped a little bit of several spies in our comments. Oh, could you let me have a chance to share my screen or go through the report first? Maybe I could better go through the report first. Okay. Yes. Okay, there we go. Can you not share? I don't see any of it. Yeah, I can. It's coming, it's coming. Yeah, no, I see it. Because I'm walking in Hong Kong, maybe some distance from your- Yeah, yeah, it's okay. It's on now. Okay, now it's good. Carry on. Telecoms. This here. Okay, this is why I have to try not to grab the information of what is China's crypto standards or a hundred standard or hybrid fabrics. First, maybe I full screen inspector. Yeah, full screen inspector. The background is that it has been a long time ago issues that you can see the number is under 10,000. If maybe five, four, nine, six, at this moment of time, I'm not the committee board, one of the WGCD, he's Bao Hua raised it up. But 2020, this year it is marked out, this issue is marked as stale. But why I raise it up again and reopen it as a two-dose status, because as you can see here, the financial situation led to technology security specification. This is the code of this kind of specification. It is newly raised by China's People Bank, which is why it is American federatics. Maybe it's Jay Gorky, he's from Mali and Chuzhism, that in English, I'm sure. So no matter how it's the central bank, something like a similar to it. It is not a business bank, it is governance banks. This kind of security specification is purely on the Chinese, it is still released and applied on these states. And this is quite kind of shocking because before these times that we just simply discuss whether it's good to have one. But after that purely standards comes out, we have to have a reference, we have to follow. Although it is T for the recommends. So it is still a recommend standard, but it will be applied to JR means in Chinese words means finance. So this is a recommend standard for all the adoption of DRT technology in finance. The voice coming from the central bank. So there's will be a rumors and gossip once after that. So some of the competitors of hyper edges, something like this OS super chains and all the other consumerity will blame whether okay, whether it's not native support in that specification. We have already done a reveal. Well, maybe I can see it later. Yes, we've already done a complex analyze reveal for this kind of towards fabrics or specification. This is still working in progress and this percentage which under under progress. And another, then the last point we have saved in the background is even before the specification comes out, there's already a lot of childs to migrate fabrics to maybe as a compatible to a GM crypto, crypto library. We have gathered a statistic to at least five fork where we are some of them are only maintained and some of them are not, but at least five, I don't know, above sevens are collected in our statistics. And people, and once after the specification is released, people, we are fabric communities in our, and China has been frequently asked where is the China's crypto fork of fabric which is standard one, which is the recommended one, which I have for paper to fast have an iteration of based on. So after that, we are more frequently being asked. So this is our response. The first child is that we have actually quite a large, large table, you can, you can visit the link here. This is, so maybe I can have first, maybe you could have right there. No, we don't have time to get into the detail. So, okay, yeah, sure. It's quite large. This is our analysis towards, and the next, so because we have already found a lot of conflicts in that talk on the analysis. So we reorganize a cooperation path with names of the fabric. The origin of names of the fabric is open governance GMs. So this is a wiki and we already collect the potential collaborator about five, 15, five maintenance. We raise as an initial maintenance. Okay. And what we structure in current status is we will already write three streams as a crypto library. So we may wonder why there will be three streams instead of just one library satisfies all the standards. It seems the same thing, something like you may have open SSL and also borrowing SSL. So that's simply that they are implementation in different way and from an issue from the different parties. So some of the, oh, what happened, what happened? Okay, maybe my mouse has some problems. Sorry. And she's an institution, Peckin University is an institution. This is a company, this is a company. And the black ones, this is the most commonly used because it is also alongside provider of fabric fog. But this kind of fog is quite frequently used. The last company time is still at two years ago, more than. So we also have a fog of fabrics under the TWGC org. Yes, we only will maintain a release port at the latest LTS and master branch and potentially we may have another GM product in maybe. So it is placed to store the information of BCCSP GM, GM style of GRCPC and new X5509 interface for all the three stream. So when it is done, the fabrics also exposed to only had an interactive with this plug-in instead of all the streets on one. So this is the one, maybe we will have a pre-built goal length conditional bills when they are wrangled in inside the goal length. So the following is our currently drafted designs. First on fabric itself parts we are proposing whether we could have the change. The first point is that we're trying to migrate from the hard-coded crypto part at least includes a shark 256 to hash the hash in the base and crypto X500, which is which we are going to the goal native package source code. So we found it is all done by the switch. It could be whether it is easy to SA or ISA or identity because they are all structuring in the switch and cases. So it will be hard to plug into another crypto library beside of his already defined ones. So we will also class someone of the, we also have some steps like to collect all the functions related to X500 and I used in fabrics and making to get all the methods together and functions together to make it as an interface. This here, we will maybe this part of interface maybe put into the fabric or the GM plug in. And another more harder part is the crypto config outside the PCCSP. We have already found at least two parts. Two parts. The first is the crypto config session in each MSP definition and the hash and error goals value in the global or ISA is a global scope of the channel. Okay. And we also definitely we also have the three streams of the crypto libraries. That's the three times here. So we also make some works on pay to apply on here. It would be some of the CI alignment, so fabric spills, a goal version alignment, OS image, Azure pipeline, a behavior test to have a better, yes, the third part is the GM plug in. But before that we go, actually it's not the before we go, we along with that, while we're going on this part, we have some wondering questions still stuck in on, or maybe the blocking on the middle is that some of the design concepts which are not fully implements or documents in fabric itself. For example, for some way for the asset parking, okay. No, but I think this is good. I mean, I think people understand what this is about. And, you know, I feel like some of these questions are two rule levels, fabric specific, you're not going to get much answers on this call, although of course we have people like Gary, probably can answer some of them. But I'm more interested in, you know, stepping back a little bit and I would like to know, I mean, is that a fabric specific problem? How does Ursa deal with this? Is Ursa a solution or what? Any reactions from anybody? Actually what I see, because we also have discussed the, what, how should we consider or place Ursa as a role because in hybrid there's also one efforts making to us as a basic crypto library, is it? So yes, it's true. So we also have some internal discussion. So you may see, actually these three streams are the GM crypto library. They are what I see them as a parallel or equivalent to Ursa. It itself is self-contained and work quite well. So I'm not sure whether these three streams can all put in into the Ursa-Ussar source. But actually it work as the same. They provide the BCCSP, they can provide all the spectrum of the, both the asymmetric or asymmetric encrypts and also the alternative of TRS ways. And also the definitions, sometimes some of them, also it includes the definition of the certificates in the base. But all the, maybe Jay, go ahead. Yeah, just Arnold, this is Jay. I just like to provide a little bit of background. So basically it's all these software, all these software not only blockchain, all these software are sold in China. If they're dealing with some core functionality or relate to national security, like core banking or some financial institution, then it need to conform with China regulations like this one. It need to establish the, for example, security connection using the China cryptographic regulation. So it's not really only about blockchain and it's certainly not only about hyperledger fabric. And, but it's not applied to all these software. For example, if they're dealing with commercial application or just some not like core functionality that's related to national security, then that's fine. We can just use like RSA or whatever crypto algorithm that's internationally popular. But since blockchain sometimes or a lot of times we're dealing with banking, this is why this is probably particularly important for us to support the China cryptographic algorithms, if that makes sense. That's interesting because it depends on the field of application. Exactly, exactly. And as David mentioned before, the newly published regulation we are currently reviewing within China Working Group. This is recommended specification but it's kind of got attention among all the banks and financial institutions here. And we are not very certain whether this will become the de facto standards within the industry, but we just wanna be precautious and to see how much we are, like how much conflict we currently have against this specification and what actions we could take. And for one, this incorporating China cryptographic algorithms could be one of the action. Actually, this is the biggest, I'd say biggest barrier in terms of complying with this spec. And some others like we need to have account system or whatever that could be all solved in my opinion at the application level. All right, thank you. Anyone else, any comments or reactions? Yeah, hey Arno, this is Dave Huseby. Sorry, I dropped off there for the last minute so stop me if I'm being redundant. Originally, URSA was going to be the way we got abstractions for allowing national crypto standards into the hyperledger projects but fabric maintainers decided not to go with URSA some time ago. So that's fine. If we want to support anything like this in fabric, it obviously needs to be modular. My only ask is that compiling fabric with any specific national crypto standard, whether it's Chinese or NIST or Russian crypto standard, that it takes extra work so that you cannot compile fabric by default with those standards enabled. That's my only ask. Just from a security standpoint, other than that, I think it's just gonna require a lot of communication coordination between the fabric maintainers and the developers who want to add these national crypto standards to fabric. I personally have no problem with it. All right, thank you. Anyone else? Yeah, this is Angelo. So I'm the designer of the BCCSP module in fabric. So I have a comment. I guess, especially for the banking system, to the best of my knowledge, most of the time you are using HSMs. So fabric can already interface HSMs and then it doesn't matter which are the algorithms so that the HSMs are actually running. Is this one or do we have also specifications for the HSM or do you use a different API for the HSMs? Yes, they did have because most of the interface for the HSM is mostly we are using is PKCS 11s. Yes, yes, that's definitely. But most of the security hardware in mainland China is not designed this way. They have two standards, namely their SKF and SDF. So rarely after HSM hardware have any idea of what is this kind of interface. So just to make sure that I understood that there's no HSM hardware, there's no Chinese HSM hardware that speaks PKCS 11. Also again, it's the China's regulation. It's fine, another interface named SKF for the PCI card and other side. You are forbidden to use PKCS 11. Okay, got it. Okay. Yes. Gentlemen, maybe you go first. Yeah, I think we have our call now. Sorry, it's falling over. Are you close to finish? I'm sorry. I think there's a mess up. We would still have a problem. Our calls are in there. But anyway, I think the way to pursue, I mean, the cryptographic algorithms or whatever we can deal with. I think the two bigger problems with this are, right, working on the GRPC side because essentially GRPC fundamentally limits you to TLS12 and TLS13 approved algorithms of which there are no versions of those that actually include, you know, SM14, I haven't looked at the latest spec of the China stuff. So I'm not sure what algorithms they're actually talking about in there. But basically, those aren't gonna be approved. Cryptographic Cypher is under TLS12 or 13. So you have to override that, right? And that becomes a pain in the butt because then somebody has to go, basically say they're gonna always maintain this fork of it or we have to decide how we wanna do that. I would probably just not create a custom VCCSP and because I think we're avoiding through my stuff, we can add additional algorithms to the existing software one. The hardware one on PKCS 11, even if they did support PKCS 11, we still actually call specific operations on the HSM that are literally calling out ECDSA. So you'd have to change that. We could also discuss another interface if we want to look at how we call it. Sorry guys, this is the, I think you ran out in the end. Now it's a different call, so we need to start. Okay, so, Rai, do you know what this is about? Just half an hour. This seems to be a messed up on the loop. You guys needs to wait. Yeah, we have been using this backup slot for the last six months and yeah, we have been using it for five years. You've got the wrong link. Yeah, that's really strange. We've been always using this call and there was never a clash. Harsha, when we moved from Tuesday to Thursday, did you clarify that these, because the hyperlager has, I think, only two links and they share them between the different calls. So you need to verify. Okay, I need you guys to sort this out elsewhere. Okay, sorry, Gerym. This is for 30 minutes more. Yeah, this call goes for another 30 minutes. Thanks guys. 25, 26. Yeah, talk to me or Rai. We can help you guys find a slot and a time and a call. Yeah, sure, Rai. Sorry for the problem. Yeah, bye. It's okay. All right, so I would like to actually close on this now because a lot of this seems to be very fabric-specific. I think I saw on the comment that on the page that Brian suggested and RFC, I would agree with this. If it's just to solve fabric's problem, then I think you're better off having the kind of discussion to address the points that Gery was on, which clearly highlights that it's not an easy thing to tackle. There are many different ways you could go at it. And this would be best discussed with the fabric maintainers. So you can have a RFC, you can have put an agenda on the maintainers or contributors call, one of those, so that you can follow up on the discussion with the maintainers. I was interested in the discussion at a bit of higher level. I'm not sure I got that much, but is ERSA solving this problem already? How do other projects deal with it? So I think ERSA solves this problem in theory, but there's a lot of issues calling rust code from Go, which is one of the biggest limiting factors at this point with fabric. Obviously, ERSA is mostly written in rust. Yeah, but again, I think people need to, I mean, I'll just say that I think Arno, you're right, we should do it in here. I mean, the bigger point in here is right, there can be items, people that have had forks, nobody's ever really submitted any code for our review. No one's ever come back and actually like asked. I mean, they've asked questions, right? On the ERSA thing, right, but cryptographic algorithms and then actually how cryptographic algorithms are exploited are two different things. So, you know, like if anyone who wanna tackle things piecemeal, we can, happy to help. It's interesting, I think on this spec, I'd be interested in seeing that things can really change. I've heard the same thing about Russian ghost algorithms for years and I have shipped commercial products in that country for banking that have never actually implemented ghost. I actually went to Russia and said I'd implement ghost if you gave me an HSM that did it and they were like, okay, and they never did. So, you know, I don't have a problem doing it. I think the bigger breakdown is, you know, finding a better way to, you know, collaborate. I think there's also people who want it so it's good that they wanna bring these algorithms there. That's fine by me. We can figure out, you know, how to do it and have a discussion of it. And then, you know, as with everything, anything that goes into the tree really comes down to who's going to maintain stuff going forward. That was kind of the notion of the plug and stuff. Unfortunately that failed because it's not supported well by go. We have other options, but, you know, the main thing where we're critical on stuff is people can't just abandon code, right? You can't have fabric be a dumping ground for like, you know, one experiment or whatever and then have it go because then people like, you know, myself, Angela or whatever, when people try to use it, get stuck trying to fix it and we only have some to stand with. All right, so with this being said, I'm going to move on. Thank you. Thank you, David, for bringing this up. Hopefully you get some sense of what you need to do next. Otherwise, feel free to ping me and I can give you the direction. But I think with, for instance, you can also help out bridge the gap if there is any. So with that being said, let's move on with the agenda. I had a point or no regarding the reports. Both Transac and Indy mentioned that they were down fairly low with contributors compared to where they were. And I'm wondering if this is a seasonal trend or if it's something that the TSC needs to start looking at across all the projects to see if contributor numbers are down. Transac said they were like at three. And so it would seem that they've, you know, sort of fallen below a level at which we would grant them project status if they were looking to form a new project. Indy's down because of Ares and things like that. So. Yeah, it sounded like in this case, there was more specific to their community where people are focusing on other things right now. And with the split in different projects, it's kind of split the resources across the projects. So there are fewer on each project. And tell me if I'm wrong, but that was my point. It's interesting in the insights page, you there is a sort of like a top level summarization of all hyper ledger. Unfortunately, you can't drill down to understand time periods and stuff. You can, but perhaps we can save that for another call. Oh, I was just, yeah, okay. If you can, that'd be nice. All right, but so point taken Mark, we can have another look at that. Let's move on to the election because we have to make a decision today so that we can stay on par with the plan. So as we discussed earlier, the TSC election is to get started, at least the process, right? Which, you know, there are several steps into this process. So I put this as decision. According to a decision we made last year, we have to have a plan presented by the staff and needs to be approved by the TSC at least a month before the actual election. So we need to do that now to stay in sync. And so can you click on that link, Rai? Please TSC election. So that's the plan that David was talking about earlier. So Dave, you want to say more about this? Yeah, I mean, we've gone back and forth since I first presented this a few weeks ago. You can see all the questions and updates at the bottom. The most notable change recently is that I've just added a section called communications about when emails will be sent to eligible voters. The timeline is pretty well set above that. And I plan on sending emails out to all eligible voters when nominations are open, when the nominations are about to close, when voting is open and then when we have results. So that's really all we need to discuss today because I think the rest of it has been sort of tacitly approved through communications unless there are any other questions. So. So that's what I'm hoping for, that this becomes just an administrative step. As I said, we have a decision we made to approve this. So it's been presented. Some of us have commented, have invited everybody to look at this page and comment as necessary. There were some questions raised and answered. So is there anything else or can we move to approve this now? So I guess the last thing is the elections at list.hyperlegio.org, right? That was also set up just recently to handle all of the communications. But I explained that earlier. Tracy, sorry. Yeah, no worries, Dave. So a question is the deadline for submissions of nominations? Is that September 30th, 31st, whatever the end of September is? Or, because it doesn't have like a timeline for when the nominations have to be submitted. That's a very good catch. Yeah, I intended that the formal announcement of the slated candidates would close the nominations but I should probably call that out here on the list. Good catch. I'll add it. Can we just fix that now? Yeah, for sure. Yep, I'm doing it right now. So we're gonna have a month of the, we're gonna have a month of that. I'll end it like a couple of days before. So whatever. Yeah, or like, yeah, 30th of September. Yeah, a month of that. Because this year, if there are third party nominations, we need to confirm with the person who's being nominated. I ask if you wanna nominate somebody else that you first ask them, that's polite. But yeah, we're not going to allow third party nominations without confirmation. So I'm giving us plenty of time to deal with that. You know, to ask if they actually do wanna be nominated. Okay, good catch Tracy. Anything else, anyone else can spot? The period where the voting is open falls within one calendar week. Is there a way to spread that across two calendar weeks? So if someone's on vacation that week, they may not see it in their work email and miss the chance to vote. Of course, if they're on vacation for two weeks, it wouldn't matter if it was spread over, but. Hey everybody, should go by that. Is that okay? Sorry, I was gonna say, is that a real concern? That was something that was raised last year, but then again, a lot of people aren't on vacation in October where they are in August, so. That's right. I mean, we did move to October to deal with this issue. We also are presenting the timeline now. And I'm going to be talking about it in every TSC call from now until we have results and the new TSC, assuming they're all, so I don't know, right? Maybe between 30th of August and the 1st of October, that's a bit long just to call for nominations on the other hand. So maybe we can split a bit of that time, take one week off of that and put it in the voting period. Yep, we can totally do that. That would mean that we could end nominations on the 26th of September, and then voting from 27th of September to 10 October. That would give us two full, let's see here. Yeah, two full weeks, 14 calendar days. Yeah, I mean, to me. Is that what we all want to do? It doesn't have to be a trade-off. All right, I was gonna say, it doesn't have to be a two full weeks. It would just span two calendar, but whatever. Yeah, I'll just do that. My internet's kind of going up and down right now. So I'll make the edits as soon as I get on stable internet. Thank you. All right, noted. Anything else? I just want to go back to Rai's question, given your new timeline of the 26th. I think if I understood Rai correctly, the comment was making sure that there was enough time between closing of getting the emails, processing those emails so that you could actually start the vote. So you may want to consider like the deadline for nominations to be the 19th, and then the vote to be the 26th through the 10th, or whatever those dates were that you gave. Just to make sure that you have enough time to do, what I think Rai was suggesting is the processing of those nominations and making sure you got the right list. Yeah, that seems wise. I like that. So that still gives us three weeks. No, it gives us two full weeks of nominations, one week of getting our stuff together, and then two full calendar weeks of voting. I think that's a wise timeline. Yeah, thanks for that feedback, Rai and Tracy. Anything else? Can somebody edit the page so that we get the, because I would like us to vote on this now, so. Yeah, let me try to do that. My internet. What do you want me to type in where? So on the timeline, yep, on the timeline, third item down, or actually second item down, go from 30th August, to 19th September. And that should be just like, publish the email template for submitting nominations and open for comment, or just add an item below it saying 19th September, nominations closed. And then we'll formally announce the slay the candidates on the 26th, and then change the date for, open the TSC election voting via condorses. That'll be 26th September to 10 October. That's all we need. Yeah, but Rai, you need to move back. The first 19th of September, that was August. Should be the 30th of August. Yeah. This one? Yeah, yeah. Otherwise, there's no time in between. That doesn't work. So 31st? Yeah. It was the 30th, but yeah, that's fine. That's fine. And I think it's important to also be a little bit more specific on when things close. Is it end of business? Who's business? What time zone? Midnight, you know, GMT. I think you need to be specific. I delegate to the TSC. I will update this page as is. And I ask someone to edit this to the way they want it. I think we should do Midnight Pacific. Dude, the world revolves around the East Coast, man. Yeah, dude. Gee. No, this is actually to deal with the fact that there are people who are not done with the day. And I think it makes sense to. Yeah, I think Pacific is probably right, unless you want to do Guam. Well, considering Dave is the one that's going to be doing all the work, and there is no need for him to stay up until midnight, Pacific to do a thing. I wouldn't mind if this was centered around business day Pacific, but that's kind of up to Dave to say. Yeah, I mean, I don't really care. I have meetings with people in Russia at 3 a.m. It's not a big deal. If we were to do GMT in the end of the day. It's not exactly. You don't have to do anything. It's just that when it closes and you don't accept more stuff like this. So it's like, OK. Dave, did you mix Russians and election in the same conversation? What? I was wondering if anybody caught that. All right. If it was around GMT, that's totally fine, too, because midnight GMT is sometime in the middle of my day. So whatever, it doesn't matter. Really, truly doesn't matter to me. Just I'll do whatever you guys want me to do. Midnight Pacific, done. So I attempted to update that September 19th in the day Pacific. Was there another place we needed to add that, Chris, or did I catch what you wanted? I think it would be the 10th of October. So the close of the TSC election. Good point. That is something where you have to actually log in and click a button to end the election. So it is OK. Yeah. Yep. Yeah, so I'm happy with end of day Pacific. Yeah, me too, so I don't care. All right. Are we done? Roy, could you refresh? I think I just updated that. Thank you, Tracy, for helping out. Some interwebs. OK, so formatting. So that's good. Let's get moving already now. I am suggesting we approve this plan. Second. Yeah, thank you. Do we need to have a roll call there? Let's just do a roll call, man. Let's do one. We haven't done one in a while. I approve. Well, Angelo? I approve. Ardo? Yes. Chris? Yo. Gary? Yes. Mark? Yes. Mark? Yes. Nathan? Yes. Swetha? Yes. Tracy? Yes. And I don't think Troy is here either. There you go. All right. The yeses, yoes, and whatever's have it. OK, so thank you for doing this. It's amazing how this election stuff always takes a lot of time. So back to the agenda. In the few minutes left, I don't think we can really do much. But maybe we can still start a little bit this discussion or continue it, because we started a little bit earlier. And so it was brought up again in the context of the Transact Report, where Gary Ponerna was like, well, Transact was supposed to be working with different projects, but it doesn't. So does it make sense to fold it back into sawtooth, where it's the only project that really uses it? So it brings the general question about how do we deal with this? We already, as Chris pointed out, we already decided that when we have new project proposals and when they come in, we look at them and we say, oh, this is like an add-on to this existing project, it should really go into that project rather than exist as a separate project. The problem here is a bit different is that a project comes in with a broader agenda to work with multiple frameworks. And then in the end, some months later, whenever, some period of time, it just doesn't happen. And the question is, well, what should we do in that situation? Should we say, hey, if it had come as a proposal, this is just an extension to sawtooth, in this case, for instance, Transact? We would have said, yeah, go do that as part of Transact, as part of sawtooth. That's great. And so we revise those projects and say, well, after a certain period of time, if things don't pan out the way the original contributor or service proposals had anticipated, maybe it's time to adjust the policy of management of the projects to do a bit of cleaning up and say, maybe we need to fold this into this other project. So that's kind of, you know. And ideally, we would have a policy to deal with this, like we have for many other things. And my point on this is, well, maybe it's not possible to have a general policy, although maybe there is. We could set the deadline and say, after so much time, if it's only related to one project, it doesn't matter whether the intent was broader than that or not, we fold it. If we can have a general policy, how do we deal with this on a case-by-case basis? So that's kind of the premise. And we probably won't have time to get over this today, but we can start it. And I'm happy to discuss this further on next call. Yeah. And I guess, you know, when I wrote this as a quick thing, and again, it wasn't any malfeasance or anything, I'm like, malintent or anything like that. And it just so happened that I happened to be working with a, when I read that thing, I was looking at STD-Raft, just because we use STD-Raft. And I was like, well, you know, STD-Raft, you know, is there's STD, the product, we all know, they built a raft implementation. Turns out STD-Raft is a Go library that people use. Hyperledger Fabric uses it, Docker uses it, Coomnit, like other Cockroach DB uses it. So it turns out that it's a component initially developed for STD, but shared into other projects. So that kind of got me thinking, well, I'm like, well, there's kind of a parent for this one. You know, it's awesome. Even though the fact that it might want to be used somewhere else, it's really kind of just a library or a component with a key tie. Would it make sense to be in that structure rather than to put this under, you know, a top level kind of project, you know, review structure? So that's kind of just where my head was at, just in case I knew something that I'm not nice, but that's kind of just where, what I was looking at when I was thinking that. All right, thanks for that. And Dano, I'd like to point out to you because you responded to Gary's message on the comment. And I have to admit, I'm not sure exactly what you were saying. So if you could further explain, at least for my benefit, I would appreciate it. So there are multiple clients that implement Ethereum, not just Basu, there's Gath, Nethermine, Open Ethereum. And there's some projects out there that work with all four of the clients, including Basu. One in labs, the message mesh that's, what, I forgot the name of it, but it's the one that Yaz is running. If that were to come into as a main project with the preference of the TSEB, that it be a standalone project, even though the only DLT under Hyperledger it works with is Basu, or it should be part of Basu, even though it works with more than just Basu. So stuff like that kind of thing. It might be used by somebody else outside of Hyperledger. Right. That's your point. I thought that's what it is. Okay. Yeah, so in this case, for instance, go back to the transact example. If it turns out that some of the projects can be pointed to and say, hey, but they use transact, they don't use SOTUV. So that just defies keeping transact as a separate project. That's what you're saying, right? I mean, that's totally a reasonable point. I think if there is a case like this, I mean, a policy, whether we have a general policy or on a case-by-case basis, this could be taken into account for sure. So, or at least a recommendation, which direction to start? So a question would be if we move, just for sake of example, we move transact back under SOTUV. And SOTUV decides they don't care about transact anymore. Can they, you know, can they kill it off as it's just under them? Or, you know, how does that happen? You know, if something becomes a sub-project of another project, can it just get killed off? You know, there's a lot of longer-term questions that we have much less in a minute to resolve. One thing I might just propose is that the TSC responds back to transact and suggests, you know, is there a time where, you know, there's a next-dotto release of transact being, you know, the starting place, places of being planned where there could be some outreach to the other frameworks to see, you know, is this a useful time to revisit the original goal of transact, right? It's just like a way of focusing back and asking and engaging the transact maintainers on how might we get back to some of that original vision? All right, so we're out of time, unfortunately, but I'm happy to continue this discussion. I do think there's something important here for us to do, and it really falls into, you know, the scope of the things that TSC needs to worry about is the management of the overall projects, right? And so I think if we can come up with some rules, that would be good. And so not necessarily just, you know, pretending to transact, although that could be an example we can use for sure. All right, with that being said, let's keep it at this. So everybody gets the time they deserve. We are moving on. So thank you all for calling today. We'll join you again next week or the following.