 Right. Welcome everybody to the January 19 type of ledger technical oversight committee call. As you are all aware, two things that we must abide by on this call. The first is the antitrust policy that is currently displayed on the screen. And the second is our code of conduct. So for announcements today, we have the standard announcement of the deaf weekly developer newsletter that goes out each Friday if there's something that you would like to go into that newsletter. Please leave a comment on the link that is in the agenda. Any other announcements that anybody has. We'll take that as no. How we did get to quarterly reports in this past week. I think the majority of us have had a chance to review both the fabric and the cacti reports. I didn't see any specific things coming in the comments that we needed to talk to, or about on this call, but is there anything that anybody would like to bring up. David in your head left a comment in the original version of the fabric report that his links to LFX had broken. And I apologize. That's a fluid system. I think the most durable way to do that would probably be to export it as a PDF and attach it to your page. But I don't know. Okay. I think it's okay I got it working. I found a way to do a date range. That I think is persistent I'm going to go check the other records but we I put a date range and then I just just adjust the dates for each report. And it gets to a static report like a repeatable report. We still are waiting on the Ursa report to come in. So we'll again give some time for that to settle down and for the community to come back together on that. Ramai did see you come up is there something you want to add. I just wondered why I'm not able to chat. When I click on the chat option gives me chat disabled. So, is there something special I have to do. No chat and zoom is disabled. So the chat for this occurs in discord. Okay, sure. Thanks. Yeah, so we have a thread for each of the meetings that I create that I put the agenda and feel free to add any chat comments there as well. Alrighty. So the next report that we have do is the sawtooth one. That's in two weeks that comes to a room question. But rather question or like coming to the fabric maintainers. I see the report there are a lot many things that is going on and thanks for capturing all those details. And one aspect that particularly interested is on the admin SDK. Now, continuing on the same lines, I know some of the fabric co-maintenors are also involved in a lab project called fabric operator. There's a separate discussion going on with it's a lot of operator proposal marching with other projects and then getting that getting those maintainers working on different operator projects and then one umbrella. So, I know there was one call previously which was which did not have fabric maintainers on that. But David had replied that he was available or email charts. So we should probably like will include you David in that right again and look for your comments in that. That'd be good. Yeah, we do have some folks that are dedicated to fabric operator. Unfortunately, they've been pretty heads down on some internal deliverables and so they haven't been able to engage munch on these things but I hope that's changing. I think they're freeing up in a couple weeks here. I myself don't have too much Kubernetes experience so I don't know if I'll add too much value but I'm trying to get those folks. It's actually another team I'm trying to get them freed up so they can help out with the operator discussions. Thanks. Any other comments on the quarterly reports. Okay, so, or no, are you willing to give us today and opens our security foundation overview. Okay. So, I love to share. Yes, it looks like it working. Can you guys see my screen. That's good. I'd work from the first go. Right. So, you know, I think I understand the goal of the exercise so I, you know, I quickly pulled together a bunch of slides. I mean, essentially, I'm going to try to give you a quick overview of what this organization is about and try to quickly, you know, give you pointers as to some of the products of the organization are that are relevant to hyperledger specifically. So, and give you a bit more details on that. So with that further ado, what is this organization about to start with. So, I mean, generally speaking, right open as a surface trying to tackle the initial relate to the security of the software supply chain. It's really open source software supply chain but given that open source is used everywhere. I actually think it's really the software supply chain general. I think the organization went through two significant phases. It was initially started in 2020. At the time we were still in COVID members were not so keen on committing a lot of money to get another organization. The organization was launched with very little resources put into it, and it kind of grew organically for a year with that much supervision or, you know, resources. And it was relaunched in 2021 with the proper funding, you know, similar to what we have all LF initiatives. It is a sister project to hyperledger if you will so it's under the Linux Foundation umbrella. And so, since October 2021. This is a project that is now fully funded it has attracted many members. There's a similar system of multi tier levels for the members. My open SSF right. I mean, as I was saying open source is used everywhere more and more. And at the same time, it seems like bad actors have realized that why the industry has got much better at, you know, securing systems that are in production. We did the soft spot is as become open source software. And actually we're seeing an explosion in attacks of the open source software itself, and there are many different points of attacks I will get a touch on that next, but so it is to the point that, you know, this is attracting governments attentions, you know, under typically the more broader term, cybersecurity, you see governments looking into this and saying common industry, you need to get your act together. This is costing millions of dollars and whatever currency, you know you open to be in the, we, I mean, you know, it's pretty famous. You live in Iraq, you probably heard of log for J that happened during the holidays last year, and that took, you know, the whole industry by surprise and created a big man. And this kind of active, you know, this kind of occurrences just keep increasing over and over. So governments, especially, you know, in the US last year there was, well, two years ago now. I need to adjust to 2023. You know, there was the issue and executive order that basically told the industry, you need to start working on this problem for real. And they actually were pretty specific about, you know, trying to address one of the very, your problem we have related to this, which is the fact that in practice, nobody even knows what's running in the, in the products. And, you know, we all, as developers know what it's like to use, you know, any modern programming languages, whether it's no Java or whatever, go, we have this system of packages where you do imports and you can add a lot of functionality very easily. Unfortunately, you have typically no clue where it's coming from, how many layers of dependencies you're pulling in. And I mean npm install is very good at showing you as scary this can be. And so the executive order specifically required the industry to start producing what's called as bomb software build of material that will basically list all the different components that can be found in a, in a software product. And this would at least address one of the problems that the whole industry has faced during the lock for Jeff, for instance, which is, gee, do we even use this software, do we, where do we use it, right. So, of course, you know, governments are telling us and by the way I should have pointed out, it's in our, you know, activities are going on in the EU, they are going even further. We have a new development and act called cyber resilience act, which goes even further in, you know, putting liability on the developers, and even going as far as planning for penalties for not providing, you know, the right to verification and, you know, a solution about the software we're producing. So it's still very much in debate, but these are the kind of things that are happening. So of course, it is better for the industry to stop getting its side together. And essentially, this is what open SSF is trying to do is help the industry move forward addressing this big problem. And SSF alone is not going to solve the problem. This is a major major problem that's, you know, much broader than any single organization can tackle. And there are efforts in other organizations as well going on. But so this slide actually shows some of the attack points that we can identify in the production of software right. The developer to the left all the way to consumer. I'm not going to get in the details of all these different points of attacks. But I think it's interesting to realize it's not, it's not even like there's one, your spot where you can just say, oh, if we bought this. And in fact, if you look at the, you know, security breaches that have happened over the last few years, they actually touch every single point. All of these points of attacks have actually been used. So this is not just theoretical. And for the sake of keeping it short, I will just screen quickly skip to the next slide, which is gives you a general overview of this, the open SSF structure. So it's not and from, you know, if very different from what you find in the, in other meetings foundation organization with the governing board at the top. There's a bunch of committees related to this. There's a tactics will be the kind of the talk here at hyperledger, and then it governs a bunch of different groups and projects. There is with the working groups, unlike hyperledger, which is very focused on producing software open SSF actually is does not produce that much software compared to all the activities they have. And I'll go a little bit into the details of what these different groups function focus on, but some of them just produce documentation specifications do, you know, they have like a reach out activities trying to educate people on the problem and so on. So there are different projects within the working groups, we've tried to define the structure we're going to structure now, we are working groups basically are this kind of umbrella projects, and then underneath this is actual project that focus on on code, why and all six, you know, that produce non code specific. I mean, that do not focus on generating code. Anyway, this can give you some of the examples of the different activities that are being, you know, held by these working groups. And so you can see that for instance the best practices working group. It works on different things, some of which are, you know, documentation developing courses material actually. They are, they are not actually this lead developing tools, although scorecard is one of the tools that I think we should leverage. And I will get back to this, and some of the structure is somewhat arbitrary in some cases you wonder why scorecard is actually not in security tooling, and you know it's really historical and that's part of the work that is underway right now. It's the result of that first year that I refer to before the fully funded project where things grew more organically than not. And it was not very well organized. And there are probably some of these things will be rearranged as we move forward. But so, I'm not going to get into any of the further details is just to give you a quick overview I suppose as I'm babbling, you can read for yourself. Some of these things. There are tools right there are things like first introspectors interesting tool just to name one that I'm looking at right now. And it's a tool that is developed that will help you figure out whether your first tool, first in tool, actually that has proper coverage, and it will actually trace the different, you know, path of code that it's actually covering and the path of code that it doesn't hit and suggest different, you know, configuration or examples things you can do to get more out of your first. And there are project that are related to identifying which are the most critical project because as open SSF started saying hey maybe we should invest in securing some of the most critical project the next question was like well which are those. And so there are tools that are being developed actually tries to just do that. There's a bunch of criteria they use this quote I'm talking about criticality score in case you wonder. That's basically for ages through the internet for all the repos that you can find and try to score them and identify which are the most critical ones. So that when their projects and open SSF that say hey we want to, you know, so for instance, I participated in an initiative where we're distributing multi factor application tokens, and we wanted to distribute them to the top. You know what the project is like well which one are those and so we went to this kind of projects that we're trying to list them and so on. So, I just to give you, you know, again, an idea, and I'm not even going to get into the details of this but you can see there's an exercise going on which is to identify all these different activities map to the threats, you know that I that I talked about earlier in this build pipeline, and to see if we have gaps, and you know, make sure that we actually trying to, you know, we're trying to cover as many bases as possible. So this is a slide that just points out that, as I was saying earlier, it's not like this is an exclusive activity at open SSF from an industry point of view. Other organizations are working on this problem in one way or another. For instance, I refer to as bones earlier that different standardization processes in underway as PDX is one of them. And, you know, it's not happening in open SSF, even though, you know, one of the activities in open as said to make sure that everybody can generate this box. So, there is an open SSF actually has connections and the results with many other organizations that are working on similar issues. And there are things like CNCF, for instance, you know, they have been working on securing containers for a long time and so they have activities that are totally related to this problem. And there are things that are being done like those were familiar with tecton, you know, which is a very popular system for CI CD pipelines, and there are activities to enable tecton to support the kind of organization that we're talking about. So now I wanted to, you know, try to make it more practical for hyper ledger for you guys. And so these are some of the items that I think are worth specifically considering in the in this, you know, in the case of hyper ledger. So the guide. I actually this, this is how I started bringing open SSF into for leisure last year. There was a guide produced on how to coordinate renewable disclosure. And this is really like a recipient if you will, and it defines what you should do. Of course it goes into saying, you know, you should have a security and define which we have because we have that in our common repository structure, but it also defines how you should interact with the reporters of your abilities. And it gives you very practical ways on how to handle it and try to do a good job at it and setting the right expectations and so on. And this is something we should really consider adopting broadly and implementing. There are a couple of guides that actually more about trying to educate people on the problems of, and I mean one of them is very general course material on developing more secure software. And, you know, one question we could ask is, we could at least advertise this kind of material. I have actually took it, you know, I took all of the courses that were available. And even though I've been a software engineer for a long time, there are still things that are learned by going through this right. And so, I think at least we should advertise this to our community of developers contributors, but we could even consider maybe saying hey all the maintainers should have at least taken that. And, you know, we could try to decide how we do this, and at least for information, there's one guide specific to npm that tells you how to, you know, kind of gauge whether to trust, you know, you can trust the npm packages you're using, and so on. And it's very practical information on what to do and what not to do to try to reduce the risk of pulling in some of those dependencies. Of course, there's the CIA CIA practice badge. It's actually not a new thing. And it has been used. I don't think we have insisted too much on it. I remember I personally worked on trying to get it for fabric that different levels. It's actually a project that it wasn't part of open SSF, but that has now been adopted open SSF. And this is something we probably should have another look at and see if we could get better at that. And, and then there are some tools that I think we really have to consider using scorecard and all star these are systems that can be used to, to actually, there are some details I'm getting to this next scorecard all star six to and salsa the next one I'll get a bit more detail in those. So scorecard. It runs a bunch of tool checks against the, the repository, and it will actually give you some scores. It actually is not a one dimension team has been accepted that we're trying to give me one score is not really the most interesting things. I don't know how you weigh things and so on, but it still does a bunch of tests that can be quite informative as to, you know, whether the, the, how you doing from a security point of view in the repository. And all start kind of works along with this and allows you to run the tool on a regular basis and make sure that you're complying with some policy that you actually define for your, for your repository. I just think that we could that are available today that hyperlinked could decide, yes, we should all use this. It's a matter of putting the right GitHub actions, so that when somebody pushes a commit or merge, you know, we run those things. Six store is a key part of trying to securing software artifacts. So, you know, it's fairly, it's fairly customary that people will sign packages that they, they publish. I remember 25 years ago when I was working at that she we already did this systematically when we released the software, we make a tough live and we, we would sign it. The problem is it requires dealing with keys. And this is typically a problem. People don't know where to find, you know, well, developers have trouble keeping track of their keys. They lost the private keys leak and so on. So, essentially, six store is a set of tools that makes this much easier. The motivation was to try to do a bit like what happened for SSH for the web with let's encrypt, where they said, you know what, we all should have. We should all use HTTPS. And so the problem is having certificates is not so easy. It costs money and they decide to create let's encrypt it gives, you know, everybody the way to do it very easily for free. So, this is similar here, six store is set of tools that will actually allow you to sign your artifacts when you publish them, and people can it actually creates temporary keys. So, you don't have to store them. There is, it's associated with the log that basically, you know, will store the fact that you have signed the package at that point. And then you can get rid of the private key, if you will, because you don't need it. People can just go to the log and verify that, yes, it was signed at that point. Therefore, I can trust it. And quickly, I will finish with this, you know, from a more broader, from a broader perspective, there's, you know, a specification that is being developed called salsa. It defines for supply chain levels for software artifacts and essentially defines a set of labels that defines different criteria and requirements to be met for build system to, you know, produce and verify the right amount of information. And essentially is that, as you build, you know, your software artifacts, you should be gathering all the information that pertains to the build so and produce what it's called salsa provenance. So, you know, it's a manifestation of what, you know, what, what is the makeup of the software you're actually distributing. And again, this is something that is not necessarily hard to do. There is actually a tool, which can be used along with GitHub, which is what we use in Hyperledger. And with the right GitHub actions. You know, those systems put in place so that systematically when we make a release, we produce the kind of material that, you know, makes you compliant with salsa level three, which is already pretty high level. So, this is basically the kind of things that I think we should really try to consider doing. And I just put on the last slide, there's a bunch of pointers, if you want to want to dig any further. I'll be happy to post the slide somewhere, maybe as an attachment to the weekly page or something like this, after the fact so that everybody can have those things and actually click on that. That's what I work with. But I hope this kind of gives you an idea, you know, what OpenSSF is about and why I think I have been saying, we really ought to do better than we do today. Let's have a serious look and as an organization, define some policy that, you know, we want to be seen applied across the different Hyperledger projects. Thank you, Arno. I think this was a really useful overview that you've given us. I think it gives a lot of interesting ideas, thoughts around kind of where we should be focused and some of the sorts of things that might be interesting for the security task force to bring to the TOC as kind of proposals and guidelines for how we best develop secure software within the Hyperledger Foundation. So I appreciate the overview. I think it was extremely useful. Does anyone have any questions for Arno or any thoughts or comments about what was presented here? I will add that, you know, obviously, all of this is very much work in progress. Things are changing very quickly. You know, the Salsa spec that I just talked about is still very much work in progress. So that means the tools, they're not mostly completely in line with the spec and, you know, you have to, but, you know, those things keep changing and we'll have to just adjust as we move on. But I don't think it's an excuse to do nothing. I agree. Peter. Thank you for the presentation, Arno. Quick and maybe a specific question. Are there any specific recommended as far generation tools that open access recommends? Or not yet. I mean, this is the kind of, there is actually a discussion right now as to whether open access should get into the, you know, recommending specific tools. There is a lot of activity in the industry on, you know, producing tools that people expect to make money out of, you know, around all these topics. And so this is an area where, well, you know, should open access that's recommending any specific tool and maybe some people would. Okay, so it's like both sides. Because if you start recommending things then that's always going to be a contentious issue or see the officially recommended one and why. But all that said, just from my maintainer perspective, to me it would add value if there was a recommended tool that just actually works out of the box. Of course, I don't know how the tool and it can be recommended because every project is different. But if it is still helping great, it's just my Christmas wish list or whatever. Thank you. Yes. I will say, I mean, they, you know, to again point out how things are still in flux. You know, I talked about salsa and the the GitHub generator. It produces salsa providence, which when you look at it, especially in version one zero is kind of like an SBOM, but it doesn't use any SBOM format. And they have reasons for this because the SBOMs the way they are today, they cannot carry the old information that salsa wants to carry. And so they define their own format. And it's like, well, okay, so I'm going to use salsa to produce providence document at the stations. And then I'm going to still have to use yet another tool to produce an SBOM. And that's in this. And everybody recognize this is sub optimal, but it's the kind of stuff's like, well, yeah, we'll get there eventually in this all out. But for now, it's, you know, it's going to be a bit chaotic. It sounds all fears crossed that yes, you very hard. Yes. Yeah, thanks for this nice overview. I mean, this is pretty cool. And I really think that hyper lecture could basically benefit from those artifacts which are developed there and open SSF. I mean, just to, to introduce new best practices here for us. But when you showed them the six door slide, I was also really wondering, I mean, is there also something we could basically help our community to also place one of our projects or tools in their projects. I mean, for instance, the the recall component you were mentioning which basically builds a transparent lock. This sounds like a blockchain right. So, yes. And if you go to the six store I agree with you and you know, it's funny. So Brian Bellendorf is the general manager of open SSF right. And, and, and, you know, when we first met there, you know, we were laughing about the fact that it's, you know, there is so much stuff that you feel like we should really use blockchain for this. At the same time, there was a bit of hesitation to bring it out because not everybody, you know, the term blockchain for better for it. It's not always welcome. And so, in fact, there's one if you go to the six store the dev website, you'll find that it's like I think an ACQ but you know, is six store using a blockchain. And they specifically say no, it doesn't. And so it's centralized, but it does use, you know, a ledger that is that as some of the features of blockchain is just not decentralized. You know, you, I have actually said, you know, within open SSF I said, I think, you know, if there was a problem, this is one area you could say well, you know, should we decentralize six store. Well, if you did, well, you would just replace Raker by a blockchain. But for now, I can see there is not much appetite because there is so much else to tackle. And this is not really people are not concerned by the fact that we'll see, you know, six store is centralized. In fact, me. Yeah, so, so I should point out that Jeff frog is a company that is a member of high prodigy. I don't know if they still are, but they were at least, and they have been trying to promote the, you know, blockchain based solution to some of the problems being tackled in that space. I would say with, you know, with some difficulty, because, like I said, there are people were quite reluctant to using anything to do with blockchain. I don't think for good reasons but But so maybe it's our chance to To talk to the different people and I mean try to overcome those obstacles. I don't know. It's definitely, you know, something that that could be done and maybe should be done to some level, at least, you know, reaching out and see okay guys. I mean, it's all about the messaging and framing and the end of the day I guess I mean if we go there and say hey please replace recall with a blockchain maybe that's not the message you would like to do but I mean saying hey look, you could basically provide an alternative implementation of recall blockchain based one for everyone who would like to deploy something like that. And I don't know if we can basically try to mediate and overcome those obstacles but also pushing Our community to basically look into that and maybe point hey look there is a use case for blockchain. Isn't that interesting for us is someone interested in working on that something like that. That's a very, very important. I think this is the kind of project that could be worth looking into. And I have to say I mean from that point of view open SSF is just like a hyper major and I think every initiative. It's completely open. Anybody is welcome to participate. It's very easy to come up and start participating in working groups and you just look at the calendar is show up and you introduce yourself and then you can start listening in participating and and you can make proposals so it's pretty easy to do that. Dave. Could you share that slide again around the items that the summary of the items that were more relevant to hyper ledger like the guides and the tooling. So my question is, which of those is kind of low hanging fruit that you think we should go after first just kind of like not much investment required but we'll start benefiting right away. Like are these guides things you think we should write or they just maybe some links through existing guides that other people have out there. I was reading the bullets maybe I missed maybe you said that already but like these concise guides are those things that are already out there that or maybe the set of things that these are actually very easy to find they are if you go to the main open SSF the website, you can find them and the resources on the top menu. And there's a bunch of them that have been published and really the minimal one click away from the home page. All right, so maybe we at least should get those links out, whether that's on a wiki or discord to start with and then maybe we put those in GitHub somewhere. Yes, that's the kind of things I was thinking indeed. Okay. So on that low hanging fruit angle. I just took a quick look at scorecard and all star and do you think those trying to deploy those as initially an opt in tool. Do you know much about those tools and are they recommended BC gov we have a similar type thing that sends notifications around when certain policies are not followed. So do you think it is and would it, and are the policies, do you think the policies would be useful. So yeah, I mean, this, this is by the way, the YMMV is your mileage may vary. This is my opinion it slide right. So it's not meant to be exhaustive and, and, you know, then maybe other tools like I was saying earlier, there's a lot of, you know, activity in the industry around those, those different topics. And so, I'm not saying these are the only ones and the only possibilities but I, you know, I have actually worked on scorecard a little bit myself, contributed some bug fixes and things but, you know, so I do think it's a useful tool. I don't have to admit I don't know I compares to others like the ones you might be using already. But I think, you know, in keeping with what we've been doing in some other cases. It could be a policy could be, you must use something like that. And, you know, if nothing else, at least use those, or if you have others you prefer it might be fine, you may not need to change. You know, you may not be gaining anything by changing to those from what tools you already use. And so, but I think the main point would be to say, you have to have this kind of tools. Yeah, I would think I'm migrating to some tool like this, and then with projects that have the capacity to use it initially, you know, central support to deploy it an opt in policy initially, migrating to a required policy. But I just, what I can't tell from reading it is, you know, what are the specific benefits we're going to get from it. Versus, you know, we all get dependable, I assume we all have dependable turned on for all of our, our, our repo so this, I would see this as the same sort of thing what I don't know is, you know, how much, you know, how are there actual policies in there that would help us in this path. So, the core card is not just about doing the kind of like scanning of your code and trying to figure out generic design, so on. It's more about the overall project. So for instance, you will look at, you know, so it helps identify also for dependencies right So that, for instance, you will look at the policies for merging a pull request where they're, you know, the requires review by the, you know, somebody else than the author wrote the commit of the pull request. And, you know, there are tests like this that are completely different, and that are still, that still have an impact that are meaningful in terms of the security of the software. But so I think we need to, we, it's kind of two ways using those tools. It helps you to know evaluate dependencies you have. Equally, you know, by producing, implementing those, it also helps, you know, inform others that are depending on our tools. And so it's more like about, you know, also helping out, you know, one of the issues in going back to salsa. And that has been discussed in salsa, for instance, is there's this notion of level is that recursive does that involve dependencies and the answer might surprise you but for now, the answer is no it's not recursive it's just that this station of what you actually, you know, directly have an edge. And the reason is, you know, it would be impossible to reach any higher level than zero, you know, if you had to secure all the dependencies you have. So to for practical reason to be able to start somewhere, you know, we had to decide, well, we have to. We have to be recursive and you can only make an attestation about the level you are in the supply chain. And so this is all being part of, you have to stop somewhere. And the more people as we progress, the more projects, you know, start adopting those tools. The better we will be eventually. Again, I know for the presentation. So we have about 10 minutes left in our call today. I do want to see if we can touch on the first item in our discussion topics around moving the project reports to get hub. I did see that right had a chance to put in specifics about the why and the process and that sort of thing. So, if we could take a look at that, we will hold off on kind of the task force discussions until next week. So, having to share my screen if we don't have something else sharing. I'm back. Okay, I just would like to bring up the proposal for the new project reports to get hope. Um, so, yeah, right. You added the why and the proposed process. Did anybody have an opportunity to review this any comments that anybody has any thoughts on kind of what we would do in order to move the project reports over to get hub. I think the first question I have is do we leave the existing project reports where they're at, or do we try to migrate those over at some point. The plan was to migrate them basically do some sort of an HTML to mark down transcription so that the comments were still there. And then going forward. Okay. Anybody have any objections to this proposal. Any concerns that anybody has with doing this. I was Dave I was a little bit concerned it would be more difficult to collaborate with somebody else when creating a report like sometimes there's two people that work together on a report and it's very easy on the week he would be a little bit more difficult. And I think these the rationale here overrides those concerns so I'm good with it. Also, I have a small comment. So it's going to be marked down right. Yeah. So if somebody wants to collaborate as I could use something like he can be and essentially do it in collaborative pool, but then commit everything. It's not split by commits, but it's something as well, if the collaboration is important for some time. And another thing that you, you could do would be to, you know, create a draft PR. And I think it's pretty easy when you create a draft PR to add collaborators. My overall plan was that basically, there would be a bug, an issue, sorry, created every quarter. And it would be assigned to the maintainers group, like, you know, whatever at hyper ledger slash fabric dash maintainers. And then a PR could be created from the template, and it would have, you know, the people who are in that group can feel free to edit that PR. I understand that editing a PR is chunkier than editing in the wiki. But I'm, I'm open to feedback. I think it's been a thumbs up. I think it's good idea. Thanks, Peter. Sorry about that. Can you hear me now. Yep, we can. Okay. I'm just my only concern with this is for people who aren't developers who are interested in looking at what's going on the wiki page is so easy for them to just read. And that might leave some information that doesn't get transmitted to the people where it needs to get, because it's going to get have a repository and not on a readable wiki page. So, I agree. For, for instance, the these proposals for labs, once they're accepted, they get rendered on this web page. And it would be something similar. Where if you go to, we see, if you go to the TOC website. You'll see that, you know, edits, edits here coming through a PR for like the TOC members. You know, this comes from a PR that's submitted over here. I agree. One thing that could be done is much like this page. You can include Markdown by reference. So you could have a page here that consumes another page and shows the updates. So I don't remember if it's still the case, but it used to be that, like, for instance, this trending community activity that's consumed from a webpage. I'm sorry that's consumed from a GitHub Markdown, blah, blah, blah. This list used to be consumed of projects. It isn't any longer because it was too hard to get the formatting to work. There are ways to programmatically consume this stuff. And I would, I'll commit to setting something up like that where not only would we have a, you know, a website like this that would be rendered. But there would, there would essentially be a feed from here. Got it. Thanks. Yeah, but if we do have that website, the other one that you were on, right. There's something like this. I think this is sufficient. I don't think we need it in two places. I think one of the reasons why we wanted to move away from the week is to get stuff off the week. Right. So we don't have to maintain it there. And so having a single source like this one as long as it's in an easily consumable format, I think that's fine. Okay. Any other thoughts on this. Do we think we're ready to vote on this. One more question. Sorry. Oh, go ahead. I'm wondering the wiki people can comment, right? Is that that's not going to be possible on a GitHub page or a PR. You'll have to have a GitHub account, but yes. Okay. Is that going to be intuitive to people. Well, that I don't know. Okay. Historically, the only people that I've ever commented are people that are good hub users. You know, either TSC member or maintainer. Typically, I know that's not 100% of the time, but historically that's been true at least. Okay. I don't have a major objection. Even was your question. I guess I was just going to ask, do we have any doubt that whoever is doing all these reports would have any problem with us? That's the only thing I can think of is. Are the people that are producing the reports today going to have a problem with this once they hear about it, or should we let people know that are producing these reports that pay the next one's going to be at GitHub any problems with that. Or is that just not a problem. It's a good question. I do know in the past there have been non maintainers right sort of like project managers that have done these reports for different projects but I believe each of those people still had GitHub accounts. It might be, it might be worthwhile to maybe send to the maintainers chat channel, just a message, asking them if anybody has any objections or just bringing this to their attention that this is something that we're looking to vote on. And we can do that vote next week. That sounds reasonable to me. Okay. Right. Sorry, one more on more question. I don't know if it makes sense at this point in time, but though, when we start accumulating all these reports, I know some of the times, since I worked on something similar, having multiple marked on files in one single repository tends to blow up and then the it becomes unmanageable sometimes to even raise a PR or work on adding a new report. And I know that, I mean, maybe we'll not see it immediately. We may see it in future. So something to be very helpful. I agree. And that is actually a pain point that I have in the wiki as well. My plan is that each year or quarter or something, there would be a folder where you know it would be like 2023 slash q1 slash whatever. And then it would be the at the top level would be rendered as you know you'd have the folders on the left that would collapse. I don't have a good example of that right now none of these collapse. But that that was my idea. So actually this one collapsed so for labs like this. You know you would see this, and then you would see 2023 and then, you know, q1 or whatever, however we want to die set up. That was my plan. That makes sense. All right. So we are at time. I will post something on them and he knows channel about this, we will revisit it next week we will also visit the task forces task forces that we want to create for this year that we can work through. So thanks all for attending. Again, thank you for the wonderful presentation. I think it was very useful and was happy to spend the extra time on it. So we will see you again next week.