 Okay recording is started. Hello and welcome to the hyper ledger technical steering committee meeting everybody's welcome to participate in this meeting and all of our technical meetings at hyper ledger. Please abide by our community code of conduct and be respectful of the other participants here and also abide by the antitrust policy. We've got a couple announcements I guess one that that fell off the radar from last time is the the Brazil boot camp in Sao Paulo. And if you are looking to help get that boot camp underway. Please reach out to the community architects there I guess is probably the the simplest way to put that we can get a link up with with right contacts there. After the fact. Next thing is the governing board has a meeting coming up at the end of July and we would like to have ahead of that time. Any thoughts from the technical community on things that we need support with in the coming year. So I've put up a table for you to add comments to you can add things that might be budgetary in nature like the the CI discussion that we have underway or they could be policy in nature or priority. So please put some thought into whatever it is that that you might add to that list so that we understand the rationale for it and include a follow up contact for us and all that should be on the table. I will send a note to the mailing list later today. And looks like Dave just add something for the fabric security audit. So, as part of the security program we have here when we do major releases. We will redo audits and with hyper legit fabric going to 1.4.1 and 2.0 that met the threshold of doing another security audit and that has begun as of Monday. So if you're curious, contact me I can kind of loopy into some of the details, but we'll have the report probably in about a month or so. I think we're scheduled to get it at the end of July. Yeah, so just over a month and a half two months. So anyway, just wanted to announce that let you know that things are moving. All right, thanks Dave. All right, convector task force rise that your item. It is, I just calling again for people to join I have Sean joined thank you. I want to do an evaluation of the code base and see that where this comes in. And the presentation walking through is there's a link and there's a GitHub repo. Please, please sign up if you're interested composer is a great on ramp to our community. And, you know, if convector can serve that role, then I think it would be a worthy addition and a good thing to spend time on. Thank you. I did take a brief look at it. I haven't had a chance to fully evaluate it. I would be most comfortable with this project being proposed through the normal proposal guidelines. I don't think we have any precedence for one code base supplanting the code base of an existing project. And that feels awkward to me. So I'm not sure that's exactly the right positioning, though. I mean, there is some overlap in the intent. But so I was actually sponsored the lab. And so I looked at that earlier on. And, but, you know, I don't claim to be an expert in it at all just so that everybody understands. But from from the positioning at the time when composer was still actually up and going and, you know, in a bigger way, I would say, than it is today. They explained to me that the motivation was they felt that composer was creating and, you know, an additional layer above fabric that was in a way too isolated and too disconnected. And so they had taken a different approach, which was to really extend fabric, but in a much more like native way, I would say. And it's not that different from the new approach that that fabric has been taking now. And, and, but so there is maybe more of an overlap in that way. And, but the fact that they perceive that composer was losing speed, you know, motivated them to bring it to hyperledger. So I don't know that they necessarily claim to be a replacement of composer per se for that matter. Are both of these only fabric related. I know composer is I haven't really looked at convector yet, but maybe we should really decide on the project versus sub project decisions first and then only fabric related go that way. Yeah, the question that keeps popping up. I believe it is fabric specific. I don't know if there is, you know, they don't expect some pieces of presentation. But you know, Alice has a comment or question. Yeah, hi, I would just like to add to this point and remind everyone that at some point. Last year you're having a discussion with Brian and some other people that tools that are not architecturally supporting all the platforms should probably be moved to the to the project itself. And those that are advertised as cross platform tools, architecturally support all the platforms, meaning that conceptually, they shouldn't be tied to any specific platform, in this case fabric. And then I understand that, over time, they might be plugins, let's call them plugins for one platform, but not for another but at least architecturally they should be open to all the platforms that are under the hyper wager branding. And Dan, I think Chris was trying to get in there to I got to get the door. I'll be back. Something else that maybe we could direct that community to see if there's synergies there. You dropped out there Dan. I was suggesting that that community could also take a look at transact and see if there's synergies with that project, and that might help round out their thinking of how they propose this project or fold underneath fabric. Okay, architectural approach technically. Okay. Let me make just a case in favor of the idea that if you have a project that starts out it's it's given a given name like composer, and it goes down a certain path. And, you know, the teams decide, hey, there's actually a different code base we might want to start with. Let's call it a to auto. I, you know, very different, you know, different code, but still the same in kind of large scale intent, right, that it probably is not not a bad thing for that to happen, right. Whether that whether the convector team wants to be thought of as composer 2.0 is another question. I, you know, if they would rather that the product was called or even changed from composer to convector, that's great. That's, in fact, another option for us to consider. I think we've just built a lot of public awareness of this idea that there's a product called Composer, which is a intended to be the first tool that you might use when getting involved with, you know, hyperlature technologies. And it'd be shame to throw that kind of brand equity away, although I hate those kinds of terms. I, you know, just because it's a different code base, if the intent is the same, and if the old, if the, you know, people around the first code base are happy to kind of transfer that public awareness to the second product. Yeah, that's an interesting idea, I have to say. I don't know if they are open to that. I mean, it would require both sides to be open to it, right, the existing composer community and the convector community or group. Yes, absolutely. So let me just outline what I think you were saying there. We would, you know, move the current composer code bases there. I think they have like eight repos over to the hyperlature archives organization, and then bring in the convector code base and rename it as composer, and then move forward is something something mechanically like that. I mean, you could do that. You could keep them the same repo and have it be. I mean, the history is there. So you don't need to have that kind of cliff, right. So the composer team did sort of commit to supporting composer for fabric one dot X. And I believe they've, you know, sort of kept that commitment. Again, no new development, but make sure that it works. I thought it was through one dot three, rather than through one dot four. Could be I, I thought it was one. I think it's one dot two, actually. Is it one. Well, I don't remember the note that's, I don't remember what. But I think maybe the intent that you're getting to there is it's the, if the composer project still has active maintainers, it should be up to them whether or not their code base. Yeah. So, you know, we could ask, I don't, I don't know that there's any, you know, I mean, we don't have any plans to take it forward. Right. And, you know, if there's others in the community, like Dan or others who were involved, I think, again, Dan has sort of moved on and his focus is on, you know, the clause tooling and so forth. You know, and if there's people that want to come in and, and take essentially the mantle of what composer was about. And, and drive that. I'm all for it. I'm, you know, that, that, that, I think that's fine. You know, but again, I do think that the decision should be one, not that we make, but that the project team, you know, so, so the composer team would, would have to sort of buy into, we can, we can sort of ratify it, I suspect, but I don't think that the TSC should be imposing projects on other projects. So to speak. Right. Right. I agree. So another avenue for this work to come forward is as a, as its own project proposal. Well, I think Alice's point should be considered and, and what Mick was saying or not make a mark was saying earlier that maybe we should figure out what a sub project versus a project means because we have ruled multiple times when we, the TSC has ruled multiple times that if it's a single platform, maybe it shouldn't be its own standalone project. Yeah. So on that front, I have to say, you know, I think it should be on their, on their page that they claim to be, or they aim to be agnostic. But as far as I know, they are not at all today. So I don't know if it's another case of, well, they could be, they just aren't right now. And on that basis, they claim they could be at the top. I think. I don't think we should. I think we should be on that progress on composer and convector with this issue because we do nature is all this issue meanwhile grid right now only supports so we've said yes to projects that are single are based on one framework. And that's, that's fine. Let's, let's consider this separately. I think, I think the point is valid. Like the next step should probably be to ask the convector team and the composer teams to potentially talk with each other if there's something interesting there that they want to do. And if not for the convector team and for our known view as the sponsor to consider if and when the time is right, if the time is now for it to be proposed as a, as its own project. And then, and then the TSE can take that and consider this question of some project or not. Which I think should still be a consideration. There's things with grid, for example, grid is intended to work at this point with transact and that would facilitate other platforms being able to make use of that same Web assembly code. So there's, there's different shades of gray in this multi platform question. Okay, sounds like we've run to a natural conclusion of, of that discussion at this point. Next on the agenda, we have some naming guidelines that went out recently on the mailing list. Brian, would you like to introduce those? Yeah. And this is a not intended to draw a lot of conversation here yet because we'd like to get in the practice of posting things to the TSE mailing list, giving folks enough time ideally to read it before, before coming here and then, you know, plenty more time before being asked to approve anything. But I just, you know, there's some conversation about with new projects coming in. You know, how much do we want to try to standardize or when it comes to coming up with names for those projects. And I think, I think everyone's still pretty in agreement that really the, the names are something that the developers themselves, the people proposing the projects really kind of own and have to be passionate about can't be imposed upon them. But we thought it'd be worth at least articulating some of the informal stuff that goes on when people do look at names and think about names or other things that they should be considering. And so it was put those in some documents and maybe get convergence on that and agreement by the technical steering committee and the marketing committee. Actually, a lot of that work, that's not my work. A lot of it was Mayor Defendant and Dana Prey and Alyssa Warley from the marketing committee. So the idea was to get some input. They're not that complex, but and so hopefully they could be iterated and improved on in the next week or week after that and improved on and approved in the next few weeks. And likewise over the marketing committee, they're kind of, you know, drawing other feedback and that sort of thing. You know, I think there was a resistance as well to saying there was a particular theme, be it around signs of the Zodiac or which was kind of been a trend or, you know, the greenhouse metaphor, you know, or anything like that. It was there's still some some niceness to something to appreciate about the quirkiness of our current diversity of different names. But at the same time, we just want to make sure that as projects come in, they've done the, you know, the Google searches, maybe even the trademark searches, that sort of thing. So those documents are there, happy to take a few minutes to talk about them here, at least the rationale behind them and then take feedback over the list or directly. I have a couple of things. I mean, in general, I think it's a good idea. Practically speaking, I'm not sure we should name a specific search engines over any other people should search. And, and the other is in the best practices document, there's one point which seems so it says the name should give people some understanding of what the technology does or and how people can use it. I would claim that pretty much none of the names we have today, meet that criteria. And I think it's pretty much impossible to accommodate that. And the other one which is don't go for something that's too geeky or something along those lines. Those recommendations are definitely attention with each other. I think transact and composer are actually good examples along those two lines. But your point is well taken up. No, these are going to conflict and that's good art. Good art comes out of conflict, I think. But yeah, it's a, it's, it's not an algorithm so much. Yeah, I'm concerned that it's not specific enough to avoid some of the some of the unclear discussions that have happened on earlier names. For example, if if a project was proposed called blockchain, that might be very descriptive of what it's trying to do, but I don't think any of us would think that's a good name. And then sort of underscoring the last point, Ursa doesn't fit in very well to a descriptive name, but it's otherwise highlighted here as a good general name. So I almost feel like this needs to get kicked back to the marketing committee to get more specific. The other thing that I would find really helpful when we tried to set up Aries is pointing out who to go talk to and who to schedule to get support or help. The other thing that I think would be good in the branding guidelines is what to do if someone sends a complaint about a name, like a trademark complaint or a copyright complaint. And that will help people when they establish the original project to know what process is for that sort of thing. That's great feedback. Meredith is on the call. So she'll be kind of incorporating other people kind of feedback from both communities, I think. And Meredith, do you want to say anything? Yeah, thank you guys for the feedback. All the points are duly noted. They make sense. And yeah, just if anything else comes up, please feel free to comment back. I'll be keeping a close watch on both of these articles here. And if you would rather reach out to me to discuss live, I'm very happy to do that. And so, yeah, we have a marketing committee call on Tuesday. So I'll be sharing this with the team there. We'll be combining the feedback that they have along with the feedback here today. And we'll get a next iteration out before the next, the next TSE call. I have another comment about naming is that my number one concern about naming something, especially in English, is that it's hard to imagine the sound, the similar sound in other language or culture that it might be bad. It might not be the right sound for the people or the language in that area. So I'm not sure how to address that. Is there a sort of tool or body or form that one would pose a potential name and ask? Yeah, Google, but Google is hit and miss. So it's not really... No, right. I mean, cultural sensitivity. It's like when Chevy had the Nova, the Chevy Nova. I mean, that's a cool name in the US, but in Mexico, it meant doesn't go. So not the best name, right? And I think Bawa actually was a... Somebody was considering some name. And I think Bawa said, oh, that means something very different in Chinese. And we probably don't want to do that. So I think... Or maybe it was in relation to a color. But that said, I totally agree, Ben, that we want to be adding into the best practices sort of the cultural sensitivity because we are trying to appeal sort of globally. But that I think is something for the marketing committee to concern themselves with. The one thing I did want to sort of push back on is because the guidance itself doesn't really mesh with either any of the names we have or even going forward with the other guidance. And that is that the name should be... What is the actual quote here? The name should give people some understanding of what the technology does and how people can use it. Just give... I think having sort of the generic sort of descriptive name is exactly the opposite of what we want. We want something that's catchy and memorable and not blockchain or composer or whatever because those are boring. Yeah, I think I agree with both of your points, Chris. Hey, Sean, your dog's pretty loud there. Yeah. I think the role that the marketing committee can play here, which would be really strong, is that the projects are going to come up with a name that they like and there's a lot of debate in that process and stuff like that. But the marketing committee can really go through and have an internal process of doing the checks with kind of in an international way, like making sure that it's appropriate overall and if not getting that information back to the project team because if the project team knows those things, they'll probably be like, oh, we didn't know. But also legal checks, looking for other open source projects, all of that stuff, I think the marketing committee should basically serve as a central place that can consistently apply a procedure to identify things that the project team might not have identified. Makes sense. Okay, well, I think Meredith and I will take these things back and certainly invite folks to leave comments on these two documents as well and we'll version them here so you can see updates to them and we'll bring it back when we think it's ready for either further comment or for approval. Thank you all. Okay. I just added the Sao Paulo comment to the top of the agenda. Karen had previously been listed as the contact for that and probably is a good idea to loop in the community architects, but if any of you feel like you want to redirect who gets those notices, feel free to update that agenda item there. Okay, the only other agenda item that we had was working group updates. It came in pretty late. I have not had a chance to review it. It looks like about half the group hasn't. So I'd rather we defer to next week if there's any questions about that. We have a... Hi, Dan. I'm here for the smart contracts working group. If there are any questions, I can answer them now or no problem to move it to the next meeting. Okay. Do any TSC members have any immediate questions that have had a chance to review that? I just got off a plane last night. So I'm not caught up. Okay. I am not either. Yeah. And not hearing anybody else step forward with questions. I just like to ask that that contributor return next week for Q and A. And who was that by the way? It's Mr. Fiat. That is he. All right. Well, thank you for coming today. And if you can make it next week, that would be helpful. Yeah, sure. No problem. Thank you. Okay. Since we have a substantial amount of time left, I would like to offer this up to the subcommittees that, that we have formed to split out separately during this remaining time that we have. I don't know if you want to try to wrangle your group together or any of the others for who have subcommittees here. And splinter off into your own. Your own mechanisms of communication to make use of time that people already have allocated here. And if that's too sudden of notice for people, then I will just give you that 30 minutes back to do with as you need. Hey, Dan. Yeah. Can we mention the two factor thing? Oh yeah, we were, I think, and I have some sort of formalized statement about that in a vote, but I don't think we, we have that statement yet. Sure. No, I actually, I think, um, somebody had actually done a little bit of research. I had said we could probably figure it out, but I guess it's not even visible. I thought it was for some reason, but I, I have an audit. I did an audit of everyone in the hyperledger. I did an audit. And it is just very slightly less than 50% of the approximately 400 people have two factor off turned on. What I cannot do, or I haven't figured out. So I turned to the wisdom of the crowd. I cannot seem to turn a GitHub ID into an email address in a commit log. Right. So I can't figure out who, who, who, who, who, who, who who who, who who who who does that. You know, I don't know who is doing that. So I can't figure out who, without going through and looking at every contributors web page to see if they have contributed to the project. I don't know that there's a way to figure out if these are active or not. Right. And there's no way to check on a committee either if there. I mean, I think you can, you can prevent it. Hey, right. This is my seat. Uh, you might want to look at the Community management lab And they specifically they get contributors shell script because it does use the commit logs and Allows you to get an email address out of the commit log using Get logs, right? So That might be a mechanism that you could use to match up the user IDs to the email addresses Okay, I'll take a look I'm not sure. I'm not sure which direction you're looking to go. So it might not be but I think there might be a way So what I have is a what I have is a list of github IDs and I don't want to publish it because then it would tell everybody who the The users are who don't have two-factor auth enabled, right? Sure, but there's about 200 of them and I tried to figure out a way by Taking email addresses for accounts that I know like my other account and I disabled 2FA on it and I Posted in the you know the email address for that account and it doesn't show up with the github ID When you post in an email address what I got was invite this email address. It didn't say invite this github ID So that was the piece. I'm trying to figure out But I will take a look and I'm open to any input on how to turn the email addresses into github IDs I mean, you know one one thing that I think wouldn't hurt at all. In fact, it would be a good idea would be to you know sort of spam the various project lists and You know sort of hyper ledger announce it says look it's really important that everybody get two-factor off so we aren't getting hacked and so forth and Say that at some point Tommy may actually boot you from the org if you're not just give people fair warning You know, so what what does happen if you turn? two-factor Authentication enforcement on people all the people that don't have it which is slightly over half of our org will be removed from the organization Okay, that doesn't have that wouldn't actually prevent somebody from issuing a pull request No, okay In other projects, I've been and it just makes it hard to assign issues or pull requests to people Because only people who are in the organization usually show up on those lists to assign pull requests it is there any Yeah, but it would be awkward to do it and I do think we should Avoid, you know Something like that, but you can you know sending a note and saying hey, please do this and you know take another Audit, you know in a in a month or so and see how well That you know that response has been I I have the same problem with the IBM work, right? And I get all the emails and you know, I match up things and go through the process of asking people to do it And they're still doing it Well, okay, so there's a there's a meta question here, right that I think I did ask And that is when we started the the hyperledric GitHub org We accepted anybody right anyone that said I want to have a hyperledric badge on my profile. We accept it and If we click the button You know is the marketing piece for us no longer that important because that's another Benefit that we get out of this Yeah, I agree with that right like If it isn't that important for marketing, I think we should do what's right for security I was also wondering if we could throw up a like a little Script I wonder if there's a way to do it on on GitHub not necessarily in the git commits But in GitHub where we can check to see if someone has to a enabled and like annoy them through the GitHub system Well, turn it on I thought about that What I did was I formed a secret group called no to FA and I was going to try to Invite Everyone to it that didn't have their 2FA enabled so then I could send messages to the group But I decided against it because I don't want to I mean that's exactly the behavior GitHub tells you not to do Yeah You know, it's like I don't know Well, I agree with Chris. I think we're overdoing and thinking this thing We should give people enough warning and then pull the trigger I mean and in between we could do an assessment as Chris was suggesting Before we pull the trigger we can say ok now. We've given a fair warning clear indication to everybody this is what we intend to do and Based on what the assessment reveals we can decide ok Do we want to leave with the consequences or is it ok to just to go ahead and do it? You know, you can also at the org Did you know that? So you know open an issue and just at them. I had no idea Yeah, so they all get the message that way. Well, the trouble is is that if you don't actually Link your email and accept email notifications. It just goes to the GitHub You know notification Page and many people don't even go there Yeah, but I mean at some point, you know people don't want to communicate well Okay, I think we're pretty deep into the weeds on this So right if you wouldn't mind for next meeting just having something to say we're gonna we're gonna give notice For a certain period of time and then we're gonna turn it on after a certain period of time and whatever audits You want to do and just have that framed up in a couple of sentences then we can just explicitly vote on that if that satisfies people Sounds good to me excellent All right, any other late breaking agenda items for anyone going once Going twice All right, this meeting is at a close. Thank you everyone Thanks