 There is an antitrust policy. Oh, we're recording again. Okay. So as a reminder, for all our meetings, we start with an antitrust policy note. Read it and understand it. And if you have questions, I'm asking the lawyer at your company, they can give you all sorts of wonderful answers. We also have a code of conduct. The short answer is the excellent to each other. There is a lot longer. More details on that. If you're curious, go ahead and read that. But if you're excellent to each other, you'll be fine. In the announcements, as always, we have a dev weekly newsletter going out Friday. If you have any developer stuff to try and get a hold of developer and promote stuff about your project, that's an excellent place to share data. And we got two quarterly reports that are in a robot was due last week, but it came in just before the meeting so people didn't have time to review it so we're going to review it against me and bevel again, right on time that they came in late So we will both do review it today and review it again next week. Everyone is Sarah here she likes to come sometimes I think she was here last week, but she was late for the meeting by an hour because of time zone issues. Anyone have any questions on a Roja that are already covered in the comments there's one open question about burrow, a few other questions. I think one of them got an answer. But does anyone have any questions comments about the Roja several questions, seeing none. If you have any questions go ahead and put them in the comments section. Sarah has been tagged that she comes in during this meeting will probably come back to this topic. So she can answer some of the questions live if she does that. The next one is a hyperledger bevel that came in last night, and I just added it to add everyone's check marks so they can say that they reviewed it or not. No questions yet we'll come back again next week to look at that. Coming up rotation next week are both hyperledger grid and hyperledger transact. So those should be coming in, hopefully, by the 26th, we'll see how that goes. There are no presentations there are no presentations and no decisions that were supposed to be made today. So from that we'll move on to the discussion. Rune wanted to have some time to talk about the security force, the security task force update. Thanks, Daniel. Can I share my screen. All right. I have a brief talk on this in our last security task force update which I guess I already know about but I wanted to quickly cover in this TSE call as well and then call out some of the recommendations that came out of these meetings and open items that are to be done as part of the security force or probably move them as a separate task within or bring them up to TSE and have for open comments on these items. Right. And some of these recommendations are straightforward, non controversial. However, there could be some which may require us to think through a bit more. For instance, one of the obvious ones are we needed to identify key contact points from each project. And the person or the contact point should be responsible for. I mean, we should make it a mandatory for any graduating project to have a representation in the security. Let's say we are forming a group of security mavens across all projects. So we want a representation from each project available on that. And they're responsible for either fixing or delegating the tasks that are related to security. And it's all on them how they handle it. And I believe this is probably the straightforward approach that the task force recommends that we have this as a mandatory criteria for any project that goes into graduation. And then one of the concern that members brought up in the task force is related to depend about alerts. They're right now, where some of them are fixed but slow and some of them are to be evaluated. So again, the action item can be assigned to the point of contact from each project and we should define time frameworks around that. That's one of the recommendation that came up as part of the task force. So one of the recommendation that I had initially put up in the opportunity section is also about refactoring how we currently have our worst security markdown files listed in each of the repository. Can we define or change the reporting template to match the one that OpenSSF team has recommended. And it eventually has the similar content where they have either reported via email or reported via a platform such as GitHub where you can report security vulnerability or the other means. So this is something we can adopt to be consistent across or probably we can look into compare these two and then say, hey, here is a new note that every project should adopt as a standard practice. So that's the other recommendation. And I know as part of mailing list, there was few questions on is the current mailing list good enough or should we have an alternative to using the mailing list. So there is an open item on that in terms of exploring alternatives to use mailing list, but the current. What do I say the sentiment is to continue using it because that's the main means of communication for anybody to report or come to us in terms of get the issues reported. And probably as part of the previous action item that is changing the template, instead of having 24 hours response that may change to let's say the response would be given within three working days. Right, so those would be certain changes for now, but there is definitely an option which task force recommended that we can have an alternate to the mailing list, if if there is any possibility. So the other major item that came up about and the task for multiple discussions is related to differentiating bugs from a critical vulnerability. And there were many ideas proposed as to how we should make it possible. Of course, there is no. It's not possible for us to always have that distinction there always needs to be a human involved in identifying or probably evaluating that has it could also go into specific project how they see that particular issue to be report, and that is reported, and how they issue to be. So that was another open item and an opportunity that could improve. So over here, one of the approach or one of the, one of the way we could improve this process was to introduce specific questions related to blockchain technology and evaluating the application of the CV score at the end. So, the task force recommends that we have this however there is a mixed feeling that the scoring alone may not be good enough, because we don't have a generic tech model for each of the project, each project have their own way of this something that is applicable to one project may not be applicable to all the projects that we have a typo ledger. However, this was always an option to all the blockchain the core protocol projects that we have a typo ledger, there is a possibility to him, I introduced this, just so that we can have a distinction at what at some level. Now. So, so I believe these were mostly non controversial ones are the straightforward ones, which I believe all the projects would agree upon. And there were few decisions that are so few recommendations that task force had, which might involve additional participants and not just the project team or the TSE and those include. So currently hyper ledger does have a cross problem and cross project but bounty incentive program where people could go to hacker one platform and then report their issues. However, the concern over there was task force identified that some of them. So we need to establish a mechanism to identify what how to filter those are how to consider those issues that are reported to be that are well to be considered as vulnerable or an regular issue. For instance, is it just the documentation that needs to correction or is it that it does not really affect my function of the protocol it's probably to do with the configuration somewhere I modify that it's all good. So those things are, are to be distinguished. And there were recommendations in terms of, and there were talks not recommendations, my correction to probably consider not having this program at all and there were also considerations where we have reviews done by each project team, and then staff having to come and say, this is the final go for incentivizing such bounty programs. So I based on the meeting previous meeting records I captured this one statement but again is this is, this is something which we can always revisit and see what each project thing called with respect to this practice. And also we need to get from the staff itself. The other open item that was identified is that hyper lecture currently does not have a vulnerability disclosure process defined anywhere. And these things would help us in an audit as well where we can say hey this project took all the right measures when and against this, let's say the potential race cars. And these are the like mitigation steps that the project team took at that point in time. So this is one of the bigger open items to be addressed. And the other recommendation was to have scorecards for each security guarantee that of the project right so it may not go per project like we should probably define set of generics scoring guidelines for each project. So we need to come up with the list of list of those criterias against which we need to score each project. For instance, the CIA badging was one such criteria. Maybe we need to introduce those additional criteria and then recommendation is to look into what open SSF has been defining. Now the next topic that is also kind of controversial is in terms of auditing the security audits. Since there is cost involved with security audits and that's a considerable amount to be spent. Who which project should be considered for for this process. Should it be graduated projects only or should it be all projects. And then those projects which have just incubated they come to TSE and ask for special approval to get their software audited. Even if TSE audits it, would it be the final decision or would it have to go through governing board because of the budgeting concerns. So that's an open item or that I mean that was the recommendation or the discussion tended towards in the task force that they these projects come to TSE unless they are a graduated project. But still there is a clause that it needs to be approved by the governing board. And the last item but not the list that's related to binary distribution. So within hyper ledger there have been there are projects which are releasing packages the job packages rust crates and NPM packages. And each the process involved over there are pretty much tied to a certain member in the community with somebody in the staff. But there is no generic definition or generic mechanism through which somebody can go and some new project can come and start using that process. So this process is not defined. It's rather known to certain people in the community and the staff right. So that's an open item to be addressed. And in terms of apart for these gaps and opportunities the tasks to be pending tasks to be done are we need to come up with those CV scoring. Pression there that need that are to be introduced. And define this code card items that we said each project will list against them. For me to come up with the policies for responsible vulnerability disclosure. We need to define the signing process. And the final item is that throughout this task force discussion which happened over multiple months. There were topics that were off from these four said items like topics used to go here and there because security as you know is a white console. We cannot really put boundary for security and say hey this is the scope of security. It can go across any layer it can go to any aspect of your system from design to implementation to release and distribution everywhere. The security really cannot be boxed in something. So even though these are recommendations, there is a proposal to create a new working group for the security process updates. So with that, I will take a pause and open up for comments. So one of the thing one of the ask over here is I'll share the link in the meeting notes are probably put it over there. Please go here and then add in your comments and do join our next meeting. If you have any comments on any of these items and let's track exactly these tasks that are open and let's try target to close these tasks with recommendations is the next meeting tomorrow or next week. It's tomorrow if I'm not wrong. Okay. And it's the same time of the day tomorrow. Yes, it's one hour. I mean it's right now it's 730 p.m. in India to be 30. Okay, so an hour after when this meeting would happen. Cool. Right. Any other people on the call have comments on anything that was said or questions. How many people know in their project, who gets security issues and who should get them. I know for fabric I get them. Okay, but before I got it. It was really unclear who got him. Yeah. Yeah, so I was just going to say that we have a lot of projects with only with none or a few people. It would be nice if we had some sort of like, we had enough people for redundancy. If I think something got sent when you were on vacation. Like last summer. And it would just be nice if we had enough people on, you know, right now it's the mailing list but you know whatever people decide, you know how we want to communicate the security issues. It would be nice if we had enough people on all the projects for some redundancy. It's hard. It's hard enough to get one person per project more than one. Yeah, I do want more than one. I mean, I just don't know if it's possible. That's all. I think at least we should have one person. Let's make sure that is the case. I think the biggest value of having someone on a project is you can get them a security issue that's inbound. And they can decide whether you should panic, whether you should mildly be concerned, and whether you should just not concern yourself because it's a known issue for the category of applications. And that's, you know, that's probably the first step of triage anyway. And that's where prompt response is really, really valuable. Especially if it's like some really hot issue like the lot for Jay stuff that was going on invasive to have someone realize it's like, oh my goodness, yes, we do use it. And I don't know if they could change it, but we can get a release rule that really quick before the whole new cycle kind of hold a bit. That's probably one of the more recent examples of the security update where having a security person that can gauge the criticality and be able to raise the alarm if it needs to be raised is kind of important. I think that would be one ask as a vice chair of all the projects is to at least get one name and let it be known to the security group. I don't know we have a security group but you know put it on your documentation and send it to the security email and maybe come into the security task force. Yeah, that was one of the other sort of things is that it might make sense to have a longer term security group. I don't know what what form that would take. But that might also make it easier to marshal people for the mailing list and other stuff. Yeah, and that opens up another can of worms. We used to have working groups and we got rid of working groups. In favor of task forces task force need to have work product the results from them. But at the same time, having a standing group that has like the blessing of hyper ledger to meet together is like say a security group that meets or regional chapter. There is value there but you know how would we go about that I guess is the next question. Well, and this is an area where, you know, the security goes beyond just the CV ease and kind of just active code issues there's a lot of best practices for blockchains that I think is a as hyper ledger we ought to be saying things about like how do we do key management correctly and how do we make sure that the types of continuity that our blockchains rely on are part of the security office the system. I agree that it would be good to have some mechanism for that and whether that means we need a task force for particular paper. That we just kind of roll the group from paper to paper or whether that looks more like a great group I think the work we see here from from what Arun has been able to coordinate shows there's a lot of value we can add to the maintainers with with what with what these guys are doing. Yeah, as a side note I mean you said we got rid of working groups. I've heard that before this is not accurate right. I mean we still have working groups, but we did is we removed the, the constraint for working groups to have some types and say okay if you have a deliverable and it's fairly, you know time bounded, you should create a task force dedicated to that deliverable within that time frame, but working groups were left alone and turning to more like long term discussion groups. And the fact is, they are more or less all in limbo, and it may give us the impression that, well they just don't exist and we got rid of them, but technically we have not gotten rid of them. Okay, I'll have to look up the history and see what the exact voting was but yeah that, I can't remember exact vote on it was. Dano I fell for that trap myself. If you go back in the email list and like November 2019 you can see exactly what happened. We came very close. Okay, so you can still have them. Cool Bobby had her hand up. Bobby, we can't hear you. I wonder she's in her car and they've got the radio instead of her. That's what I would guess it sounded like a guy talking on a radio. Come off view. Hello. She's got the wrong input on her phone looks like. Sorry Bobby still can't hear you. Okay, I'll try. Now you got it. That's right. Actually not in my car I'm on my computer I don't know why that happened. But for me I'm just the learning materials working group was one of the active tech working groups when that ruling came down in 2019. Everybody is correct in saying that the removal was just the fact that we had a work product to. So I know my group is here to onboard newcomers and collect, obviously learning materials. So it's kind of permeates through all of the different projects and groups and that's why we keep going. And I think the task force for security issues might be the same kind of thing where it's beneficial to all the different projects that are going on. So yeah, we still meet every week we still have. We have four entrants into the global forum we're working on the document task force so we still keep moving. We just don't report to anybody anymore. Okay. That's good to hear. You've had for a while. Right, I was searching for these reactions on while sharing the screen. So I think I feel I see a value in have. I don't know if we want to call it a working group or if working group structure does not exist anymore. But I definitely see a value in having a group of members from each project, whether they are designated as security movements from each project or not, having them meet regularly. And we want to establish an ecosystem where everybody shares what they have found from their project and share their learnings with others or probably just learn from others and see what other communities outside are trying to do and probably come up with better measures. Some of that could also include involving I mean running a community meeting like that would also help in a way to take feedback from the people who are using those projects so they can come in. They can add their comments that can go in as a feedback. Even if it is, let's say a meeting run once per month, which means just 12 hours in a year, that's still a value add to the community. So if there is no framework to create a task, I'm sorry, working group, I would still recommend that we come up with a mechanism to have this group functional. I've got some of the details on it now too. So yeah, we can form them. It's just the work product that is the key differentiator that working groups don't have work product and they don't need to do quarterly reports. Because back in the olden days of TSC before my time, I think the working groups had to do quarterly report too, which got cumbersome. Cool. Any other questions or comments? I'll make a point to call into this task force tomorrow and see if we want to go down the formal working groups. Step and work to some of these tasks. So, right. I think the next item on the agenda is mine. My task force projects gaps task force. So we had a couple of meetings off off schedule, not a schedule off week off meeting off TSC. And from that, and the TSC, we did a bunch of discoveries. So I put together a synthesis of all the things that I heard it was mostly listening session to see what it is. And I tried to develop some of the themes and personally going to read through the top bullet points of this document and then come back and have a discussion on each one of them. But the first question is, there's a few structural questions I think we need to answer before we can come up with firm recommendations. The first actual question is what's the viability or appetite of a top level project that services quote a single chain or only one type of a DLT. There is there's a deep well to answer that question of what if and what if not. The next question is what about gaps that are actually features of a project rather than a standalone project how we want to address that. And I think the third question is more of an existential question is how close to the core of DLT code. Does a project have to be is you know hyperledger enterprise blockchain. What does that really mean. We've had a lot of focus these past few years on building DLT is from the ground up. But part of that could have been because enterprise deal to use really didn't exist five years ago, when, when this whole project started up so there was a lot of bootstrapping going on and now that the bootstrapping is done. Do we look forward. And what do we look forward to. So, I identified about five major themes from the discovery. I pulled down a bit to try and get as many of those in there. And I've ordered these basically kind of like a stack from quote unquote further away from the DLT cord down to the DLT code itself. There are multiple mentions of end user focused features like wallets. We've heard this before in this meeting, secret storage. And that credential storage, the various in the very scope of the user, how they're using it you know enterprises have different needs for their signing supports, then say a single end user try to present identity card to prove that they're 21 it can get into versus the department, you know, showing that they have purchasing authority. So there's scopes on some of those wallets and end user usability issues where they could be using you know identity and DLT sort of stuff but how do we, you know, solve that last model problem with the US. The second category below end user and user experience issues are what I would call applications. Like something you build on top of a DLT. And the two scopes are like the general app feature libraries, like you might want to have a library that help you do tokens and the various and, you know, work with tokens in the front end of your UI, your UI code, or in your back end code. And so you have various US libraries to build these applications build these processes for what in a theorem is called dApps and I don't quite know if there's an exact equivalent in fabric, or in sawtooth, or in any of the other blockchains. In the scope of the DApp is different because it could literally be your purchasing system is what which interacting with. And the next category of application are basically domain specific tool kits I put supply chain up there is the first one because Grids kind of covering that already. It's not really a gap, but there's other commonly talked about areas such as Providence and proving that you know this was registered this time or this was recorded here. And finally exchanges to get the token team which is really, really hot right now. You know, help people do DEX or CEX centralized exchange. This is, you know, something, you know, I don't know if we want to get into it or not, but it's a potential gap and that's questions we need to answer. So one of the staff is cross chain interoperability. We really have cactus and some other projects in the lab such as weaver and UE that address this cross chain interoperability problem. And, you know, I think we got some good work going into projects and just need some more crystallization as to what is being provided and if there's any more gaps coming in there. And I think the three big themes that are coming in there are interoperating between private ledgers interoperating between a public ledger and a private ledger and interoperating between two public ledgers. The public ledgers you know traditionally be the stuff that's in the, you know, won't be considered the non enterprise blockchain stuff but there's more pressure to get enterprises to use those chains even though there's huge issues with space and expense. There's still a lot of driving gravity towards and there are some solutions there such as layer twos and other interesting things. So that's been a question of how enterprises could access those and still access their private data and keep it in sync. Below that is a category of tools. I would call related to operating running a chain. Originally had this in two groups. And we have people who are standing up a chain for the first time and delivering the application and then they move it on to the operating team. But really those are the same category of tasks the same layer of tasks. You don't operate, you don't write the DLT code but you work directly with the DLT codes either set it up, or make sure things are going. And this is where it kind of gets a little fuzzy into the, what's a project and what's the feature of the DLT. So this is, you know, for projects that come in here. We show value outside of plain old working with the DLT and we got a couple of those as incubating projects and as as labs projects already. Yeah, there are some other non non hyperlinker projects that exhibit some of these things. So there's there's some questions there, but probably there's a base layer. Another question has come in regularly when we have these gaps just trying to create a common consensus interface. So that if you have raft, or various new version of BFT, or if you want to use a proof of stake algorithm and somehow integrate it with your generic back end. And in the, in the, the Ethereum world and outside of your world there's a big push towards what they call modular blockchains, where you would have, you would basically have another blockchain handle your security, and you would just handle the transaction process. And a model like that is where a common consensus interface from from hyperlinker could be useful, because they can plug it into something that the enterprises can use to be comfortable with, and using existing tooling so provides opportunities for people to sell stuff. And finally of course there is the new DLTs has been said that we're kind of full with DLTs, but if there's something really interesting coming along that we'd be interested. You know just just reiterating what's been said before on that. So it's just listing the complete thing of where the projects that I expect hyperlinker to be able to present from the synthesis that people might want. I haven't gone through and identified which labs correspond which one of these categories is probably the next task in the next off chain meeting here in a couple weeks. So final topic to what is out of scope. And these have been standing I think these three big things have been standard since the dawn of hyperlinker, and I don't see them changing. And there might be things to grow to it but I'm not sure much needs to grow out of that. The first thing inside of scope is operating a public network, hyperlinkers not going to run a hyperlinker network. The next is hosting a specific application. Hyperlinker is not going to host a specific, specific depth to do identity problems. That's not what hyperlinker writes the software. They don't run the application. And finally, something that was discussed. It hasn't had any reason to change it is that hyperlinker is not a standards body. It's a standard version development, software development collaborative and standards is a very, very different beast, and the sort of things that I've seen going on in hyperlinker so those I think will be the three things that will be out of scope. So, any comments at the top level before we go back and discuss the open questions. All right, seeing that let's just start with the first structural question. Sorry, sorry, Daniel just the point though. I mean, the areas group is developing a specification. But is it like ISO standard. No, of course not and nobody, you know, could do that here but you could develop a specification, which is then submitted to some other standards organizations for standardization. So that probably is something worth, let me bring up my phone so I can edit it. That is worth mentioning is a sub point on there. I'm not logged in. So, I will point out and this is just to expand on. Sorry. I'm sorry, Daniel and our nose point. Hyperledger would need a completely different legal structure to have standards and be a standards body, and the rules will be completely different from what we have now. So, yes, producing something that becomes a standard is, you know, one thing and being a standards body and issuing standards is another. Thank you. Cool. And Arun had his hand up and I went back down. I guess I answered that question. So I was about to ask the same question. Okay. Cool. So, going back to the top the first question is, and this is an open question for the TSC and anyone else on the call is what is the appetite for quote unquote single chain top level projects. And one of the standards being applied to stuff that are DLTs is that they need to have applicability to multiple types of DLTs. I guess is one way to phrase it is a type of a DLT, rather than just being a project that provides services to just say the Ethereum network or say to saw to, or to just in the, because that's that was in the charter for Explorer and for composer was that they were supposed to be multi chain. That's something we still want to continue with. Do we think it's going to work. Has it been working. Um, my contention is if those projects were sub projects of fabric, they probably would have been more successful. I don't know that that's true because I'm not close enough to what's going on in fabric to know, but we have had projects that we treat a lot like this on the Aries. On the Aries side, Indy doesn't have this so much as Aries does because Aries works on the peer to peer protocol part of digital identity. And so we have, you know, repositories that handle just like the mobile edge wallets. We have repositories that handle particular programming languages libraries and integrations and Aries works together fairly well because of standards efforts that exist outside of hyper ledger at diff because of some of the standards things we pointed out. But the code gets implemented at hyper ledger first and the standards tend to follow what's already in the code, because it's hard to standardize something you haven't tried before. So, I think that this is viable, but it does introduce kind of a level of abstraction into our governance model that we need to be prepared for in order to make it work well because I think even now in Aries. There's some governance issues that have come up because not all the frameworks are always in sync are always working on the same stuff the same feature set. Okay, so let me post a hypothetical question to illustrate one of the questions I have, we need to get an answer. Let's say I want to write an identity wallet and integrates with the Luna blockchain and I want to be part of Aries. And y'all are like, No, how do we handle that. And that's a really good question so far with Aries. The answer has been the goal of the project is to keep everyone as interoperable as we can. So, you're unlikely to get a no so we haven't hit that problem in particular because we've been bending over backwards to be as inclusive as we can be. But that raises this kind of second level governance question of how do we deal with, you know, irreconcilable differences perhaps like if the go framework folks decided that the cryptography that the rust folks are using isn't suitable and go and they want to do something completely you know, how do we reconcile issues where they don't want to be compatible anymore. Right, or, you know, Aries is making a point to be compatible with everyone that comes along but what if you know, there's some theory and project and we the basic team say it's like that is nowhere near what we do. There could be a sub project of us, like an NFT storefront, and we're like, that has nothing to do with an Ethereum client. Why does it need to be under some subject. How should we handle that. I don't know that I have a good answer to that I think you're right. And I don't think anyone can force it on them, right, because the, all the projects for all the sub projects for instance under Aries do coordinate across each other. And they're part of areas because they're working on something where they want to be interoperable and stay interoperable over time and if, if you don't have that quality it's really difficult to make something sustainable. Okay, so we'll leave that question is depends. Each situation is going to be different we'll see to that single chain projects should try and work with who their single chain is. But we're not going to force it on people. So what about features that are more like gaps project gaps are more like features for standalone projects such as. And the one I'm specifically thinking about is observability, because you could take, you know, your existing project and you could integrate. Prometheus or open telemetry observability features in there does is that requires separate sub projects, maybe it does or maybe it doesn't. But what, what, you know, what ability do we have to tell a particular sub project you need to have this feature. Do we. Can we recommend it and help you do it. Arun. It's a good question and when you currently look when we currently look at all the projects that are in the hyperlature I don't see we have that many projects that can say, hey, we do have scope defined for observability. Clearly, right so some of them in this topic specifically has to be an independent project that can stand alone. And it's fine even if they start supporting initial set of projects, but that option depends on how the tool itself is probably defined. Let's say let's say a project starts supporting fabric to start with. And then eventually people who start using it they like it and then they see, oh there's a value for me to extend or add a plugin that can start supporting this additional project that I like. But observability itself is a big question and it's a big concern as well that has been brought up multiple times. So I think a third question to ask here is how close to DLT core code does a project need to be. There's a, you know, some of these tire level features like crush a compatibility can work without having to touch DLT code if it's using the right interfaces, the applications will, if it has to mess with the DLT code that it's not really an application. It's a customization of the chain, and he's in user wallets I mean there's no way on earth they can hope to change the DLT code. Are these viable projects for hyper ledger that we want them. And how far up the chain do we want to go, do we want to go all the way, eventually today, or no. Yeah, so we touch a little bit that you know on the topic when was it greed came about. It wasn't clear does that even belong here, and we actually raised the question all the way to the governing boards. And then it was like, yeah they're like, that's fine. You can do that. I think initially honestly there was a, you know, the members that created the hyper ledger where a bit. You know, unsure about how far we should go as an open source community because there was this notion that we all wanted to be able to, you know, have developed the, you know, additional layers on top on which we could actually, make money off. And so there was this idea that hyper ledger should focus on the lower level. I don't think that's so true anymore. Things have changed. I mean blockchain is become more of a community. And I don't think that the, it matters as much. And I don't think there will be as much reluctance to going up the stack of it, as they used to be Jim. I definitely feel the same way here that if we look at club native as sort of a model community, they've got hundreds of projects, many top level ones, spending very deep in the stack, and pretty wide. And for the blockchain space I think we're still in the early days right we're just barely passing the adoption of the DLT layer and common patterns are just starting to merge further up the stack. I think we should sort of have an open arm posture to you know all kinds of proposals anywhere in the stack. So, I feel like that that's how we built a vibrant community to have people with good ideas and high quality code to feel hyper ledger is the place to be if they want to contribute to somewhere. Yeah, also in terms of, I think it's kind of natural evolution for hyper ledger to expand the scope because, you know, as things become more mature at the low level. There isn't that much new development that's going to happen at that lower level, unless we expand the scope to embrace other layers. We're going to be, you know, we're not a shrinking community because there's not going to be that much stuff to do anymore. I mean, when I look at hyper ledger fabric. I mean we are, you know, we still have some features we're adding but the pace of those right as drastically decreased. And I think the same is very true in other frameworks, and it will be anyway at some point. So I think it is to our benefit to expand the scope for literally like the survival which it sounds a bit too dramatic but maybe more like you know, the, the, the evolution of the organization. Nathan. I think we ought to look at where are the exciting or interesting things happening. I know that for the identities part of the system, a lot of work has gone elsewhere because the application layer has been out of scope and there's a lot of interesting things happening for healthcare credentials, and for other use case specific items that, you know, these parts of what they're doing probably should live at hyper ledger but other parts might be better off where they, where they found a home, because they've been able to find more use case experts or domain specific experts where they ended up. So, I guess, some of the question that I'm hoping we answer from this list is, what gets the most interesting folks to participate at hyper ledger and choose to house their cool new ideas here as opposed to anywhere else. I don't know if you're aware that you're muted but if you're saying anything, we're not hearing you. You're right, I am muted. So I'll repeat everything I just said. I have a question that I just thought of during this that I think is going to enlighten some of the project gaps. What is the appetite for inviting projects in that have existing code. I know that's how basic came. We were a project and a consensus, and there was identified gap that there was a great need for an Ethereum type DLT in hyper ledger. We came over, we were patheon we came over is hyper ledger basing and now we're housed in hyper ledger and have a strong firm identity is hyper ledger basing. Is this a process that is that works do we want to continue doing it, or do we want to, you know, how, how, how committed are we to Greenfield versus Brownfield projects I guess we'll be one way to look at it. I'll speak historically. Today we're about 8020 Brown versus green. I assume by a lot of this code has come in fairly well developed. I'm trying to think of the completely brand new projects that jumped out of hyper ledger and were first developed there and I can't think of anything off the top of my head. I don't know. Someone else may remember something. Right, I think you're right. I think it might even be higher. Everything was either brought in or forked off from something that was brought in. Yeah, I was, I was trying to think of like any of, if there are any lab projects that came in as nothing and developed into something that became a project I just maybe you're right maybe it's 100% it's probably pretty close I'm sure there are there are a lot of labs and I'm sure there are some that started with very little but it's it's going to be high. That doesn't mean we always have to be that way but that's just what's happened historically. Yeah, if you look at, I have another org, or I park inbound code bases, and, you know, there's a lot of them. So, we're coming up on time. I think we got some good questions on some of these structural questions that I think are probably more important than drilling down on each particular project gap. The next off cycle meeting is going to be the third Tuesday. My calendar. It's going to be in June, and I think I'll be in town for that. It's going to be my first. No, it's going to be the fourth. So, the people are interested. I encourage you to come on this specific page. If you can think of projects that are not in hyper ledger that might fill in these that might be willing to come in. Leave them in the comments so we can get a list of gaps we can either solicit Greenfield, or see if there's other projects that we might want to solicit to come in and grow the team and grow the family. Yeah, any closing comments from anyone. Okay, if there are none. Go ahead and close the meeting a few minutes early. Thanks everyone for coming. We'll see you again next week.