 Alright, welcome everybody to the July 14 type of ledger technical steering committee meeting. I guess we've all gone through this before but the antitrust policy notice is displayed on the screen. We must abide by that and the code of conduct that is in our agenda. So for the announcements, we have our standard announcement which is the dev weekly developer newsletter goes out each Friday. If you have something that you want to be included in that newsletter, please leave a comment on the wiki page that is linked in the agenda. The second announcement, the charter changes have been drafted with LF legal. There's been some additions around just when the election is going to be held into some other clarifications. So I've linked the changes that have been drafted there in the agenda. If there is anything in there that you see that is of concern, please take a look in that heart and the hyper ledger folks know to ensure that that gets included. I believe that has been added to the agenda for the governing board, we need Monday, so I will at least have some sort of updates hopefully next week on what comes out of that and whether or not the charter is actually going to change. Are there any other announcements that anybody has Bobby. Thanks Tracy I just wanted to give some of the maintainers on the call a heads up the task documentation task force might be sending through the discord. A quick survey it's only a few multiple choice questions, but just to keep an eye out for that for each one of the projects and tools. Thanks Bobby. Any other announcements that anybody would like to make. So if there's no other announcements we did get to quarterly reports that came in. I saw one question. And I think then it was a question that you asked on cactus around whether or not it was a place where we thought the main here is we're ready to take that to get graduated or not. I don't know if you have seen that question yet or not but maybe put you on the spot and see if you might provide us with an answer. Thank you. I'm not seeing the question yet. I would say they're getting ready to apply for the graduated status. I just want to finalize some details on the new maintainers from viewer viewer team. So they are officially cactus maintainers now but we're still having got the details on that we collaborate on that weekly. Hopefully, closer to the end of summer beginning of the fall they will have some updates on that. Okay. Thanks Peter. Any other questions that exist for cactus or fabric at this point that didn't make it yet into the weekend. Okay. There are no additional questions. I didn't have any specific TSE topics for today. Does anybody have any topics that we should discuss as a TSE before we talk about the task force. So if there are no items that I will hand it off to you Dano to talk about the project gaps task force. Cool. Let me find which window is going to share. I worked on finalizing some of this last night and I did share it on Discord. But it's what a color red herring. Very much up for discussion on some of these details. So if we go back to, I try to work on some of the deliverables. I didn't get to the unfilled needs to solicit projects for. But I focused on the philosophy unless the specific themes areas for the philosophy that aren't currently included by current projects. Didn't get a full list of these projects in each area. And then I listed a couple of labs that didn't look too deeply to the too many of the labs there's there's there's quite a deep well look into so I'll need some help from people are familiar with those lab projects. But the big take on the philosophy is, you know, an elevator pitch and propose a policy change. The first elevator pitch is to enable enterprise enabling software for distributed ledger technology and multi party systems and the frameworks tools and libraries that support and enable those systems. So I think the big thing is acknowledged in the second part the frameworks tools and libraries FTL that were starting to move up the stack from just the core blockchains themselves and even what a blockchain is is taking a change or we're now calling them ledger technology and multi party systems. And I think that's the elevator pitch for you know what projects we'll be looking for. So, comments, statements on that anyone wants to make any, anything. Get it. Go ahead. As I read that. I think that that excludes applications in the multi party system space is that intentional is that an incorrect read. I thought some kind of the application space. Um, so I did list some applications for libraries and the themes. So my thought is that it would probably fall under the frameworks and libraries. I don't know if we necessarily have a white label application, but maybe we should have a white label application where you can just go in change the branding and boom you're up. I guess you could think that hyperledger explorer in that case was a white label application that you could just relabel it and have your own explorer that's branded to yourself. So I'm open to adding that directly. Okay, any other comments. Okay. So from this, oh, go ahead, Arun. Can we so since since you're talking about this topic right multi purchase them so I would envision at some point in future. So we know that we are not going to work on the standardization things but however, it would be good if hyperledger collaborates with other standardization entities, and in some of some way or fashion it already happens to operate. There's two IP and then there's few others that we closely work with are like some of the projects in hyperledger has inspired them or whatever it could be. So that could also go when I consider it in the scope of multi party systems it could go to entities such as GS one, which in kind of relates to supply chain domain which goes back and defines the standard entity models for how different parties exchange their data, right. So are we considering like library tools implementation for those as well under here. I would consider those in scope and when I went to further down the thing about projects and themes and I did hlf is not interested in. I put some commentary on running an operating standards process standards work may run in parallel to a project, but hlf is interested in the software implementation and community around the software. Not the standards making process. Does that encapsulate the concern or should we tweak that a bit. So it encapsulates however it leaves a gap around multi party system definition for application so we are planning at one side we are thinking of leaving out the application domain specific implementations. But when we go for standardization entities like this it again, even though it's a multi party system it deals with scope specific entity models right so it's very application oriented things. Okay. Let's do it Nathan and heart have to say before I look back on it Nathan. This is actually what I liked about the elevator pitch part of this statement is one of the hopes for this for me is that it helps those relationships go both ways. Because just like we have some organizations we like to use as our standards side of what we're doing at hyper ledger. My hope is that we can also become the preferred place for them to build their ledger and multi party computation components. We can have a closer relationship as a result so I agree that we should do something to try to clarify or keep flexible our definition of domain specific, because for one of these standards bodies typically domain specific doesn't mean that it's a specific application for a specific customer. We don't have the scope to address everything about the problem in the first phase. So we're going to pick a handful of use cases to start with, and that seems to still fit within the spirit of what we're trying to do. Okay, heart. Yeah, thanks Dan, I guess. What are the concerns is that if a project, particularly if it becomes dominant in a space may have to do some de facto standards work, even if that is reflected in code rather than, you know, sort of just standards documentation. So, I think, you know, the essence of this point is correct that we don't want to be a standards org. But we don't, as Nathan points out we sort of, you know, want to reinforce collaboration. And we don't want to prohibit our projects from sort of working on de facto standards, particularly if they're reflecting them in code right. So what do we do if say, you know, the cactus ledger connector, you know, becomes popular, right. Does that format, you know, do we ban them from writing up a document on that. See, when I was this hearing standards process, I'm thinking of stuff like ISO and Oasis. Oh, absolutely. And we don't want that. We, you know, we want things to be code focused. But but there's sort of a fine line, you know, between, like, there's clearly a big difference between a standards organization and sort of what I'm talking about here, right. But but we want to make sure that, you know, sort of projects understand that, you know, that if they've sort of created de facto standards they can run with them. So something like that. That's perfect. I like that a lot. Okay. Kamalish, did this address some of your concerns to also see our nose off me. And rereading the whole thing. I was trying to make sure I understand. And I'm comfortable with what's captured here. I mean, the gist of my, my thought on this is, we don't want to prevent specification work will happen per se, we have to be careful, not to claim that we are developing a standard but you know, I wanted to react to what hard just said, but we want to focus on code. Well, yes and no, I don't think this should be done exclusively, you know, in the sense, I don't think we necessarily want to exclude any specification work per se. And as a result or as a parallel activity to writing code, we may very well say, oh, there's an API or there's a protocol there's a format somewhere that would be that could be codified into a specification. And I don't see any reason why hyperledger couldn't get this done within hyperledger. What, but we are, but I agree with what you were saying that or that, you know, at the same time, we don't want hyperledger to be, you know, to be claiming that we are doing standard work per se, because the word standards, you know, I get back on my sub box of that one is, you know, it carries a lot of weight and it has a very specific meaning and I agree with you they are formal standards organization that do that and we don't want to get into that but there's plenty of work that happens before the formal standards processes kick in, and that can be done within hyperledger so I wouldn't want to exclude that. Okay. It's very common that formal processes if you go to like that but we see is a good example right did the deep spec. It's like well, you know you you often stop this somewhere else. And then you come and say hey we want to build a standard around this and you contribute whatever you have come up with. So to get things started. So that one thing that you contribute to get things started could be done within hyperledger. And by the way the next foundation as a process to do this is a framework for the community specification framework, which ensures that the right legal is being done and being secured and all that. So that I think it's important to be aware and to make sure people do it the right way, because the tendency in open source is people think, oh we have an Apache software license we're all good Well, it works well for code it doesn't work so well for specifications but beyond that that's an implementation detail it's an important one but So, what I have highlighted in the second line. I wonder if there's a way we could make this stronger to say brother may have to say please bring a reference implementations. Is there some way that we could say to invite reference implementations or should we just leave it at may host. So, I'm going to have to push back on the word reference. And that again as a very specific meaning. Yeah, I prefer that. Can I add in reference and otherwise, or just implementations. It can be references or samples implementations. It can be or yeah. I think that's a good question. Maybe it will help if I explain a little bit if I don't mean to abuse the microphone here but so the term reference implementation although it's abused by many people so you know don't get surprised if you see it to use a different way that I'll explain but it really is kind of the cut off law in a way it's like in parallel to the to the actual standard, you have a reference implementation, which means that if the specification is not completely clear on certain things, you can go to the implementation and say, that's the way it's supposed to work. Okay, you know, while a sample implementation doesn't carry that kind of, you know, authority, the specification is the last word. And if there are holes in it, well there are holes in it but you can just go to the sample implementation and say well that's how it is. Somebody might do it differently and so claim they are compliant and they have the right way of doing it. Okay. Jim. Just, just from my perspective, I feel like standardization is the space is not ready for a standardization is my opinion. There's so many innovations and so many new approaches emerging all the time. I'm curious, when people say standardization, what are some of the threads that are happening. Did so be a good example. And that's a big one on identity. I'm not sure if there's any. Nothing in Ethereum has been submitted to ISO or Oasis, although there was talk of trying to get Oasis in the Jason RPC steps. And that kind of fell by the wayside. When people realized that they couldn't just argue all day and had to actually bring on stuff. So I want to share that there is a whole set of activities around standardization of blockchain and DLTs and whatnot within ISO and GTC one. You know, I for one, I mean, I'll be honest, IBM has been trying to slow it down as much as possible because very much like you were just talking about we feel like it's way too early to try to standardize things. And I mean, especially given that they started this work several years ago already. But that, you know, so the work has been mostly at a very high level, which is often the way it starts is like before focusing on terminology and, you know, very high level new kind of things. Okay. Yeah, I think the idea is a good example. But to me that's likely the only example where standardization is progressing far long enough. All the other attempts to standardize things from what I've seen is just way ahead of what's what's necessary at this point. Do we have any projects that might be an example of this that are implementing a standard. It is progressed, probably an identity space would be the most likely candidate. So I think in areas are in the or any of the others. Nope. Okay, so I'll leave the example they're blank. Any comments on standardization or people happy with this more or less. I decided to cross out the top line and just have these two bullet points I think he's he actually what's been said better than what I initially put. Okay. Let's go back to the top of the elevator pitch. Any questions on the elevator pitch before I move on with it I think we took a tangent on on standards but I think it was a good tangent. Okay, so so from this, this is probably the most controversial part of my recommendations that are coming up today. And that's the that I'm recommending a policy change. It used to be in the past that when projects came up. They either needed to be a layer one DLT or MPS, or they had to support multiple layer ones or MPS is. And I think the time has come where we need to consider policy change where we allow projects that explicitly target only one platform as a part of their feature. Without requiring them to be folded into that one platform because there's a couple of things American targeting a platform that is not a hyper ledger layer one but it's still in a space that hyper ledger wants to operate it. But at the same time, not every layer one is willing to accept these alternate implementations. So, I see heart has his hand up. So I'll go ahead and let him answer. Hi data, you know, I'm not sure this is actually a policy change right. We've asked projects to have the goal to support multiple platforms in the past, but we've had a number of projects come on, and then, you know, only support one single platform right. So I'm not actually sure this is a policy change. But I think, you know, we've sort of already been doing this. There certainly aren't any rules that explicitly say we have to, you know that that projects have had to be multi platform right. This is something, you know, that the TSE has encouraged but we've never really had this rule right. Every project pitch that I've seen has been targeting multiple platforms explorer said they were going to target multiple cactus that's the point of cactus. And it's initial pitch said it was going to target more than fabric and then has pulled back into fabric but their charter and the project charters still right claims more than that. They've said this but you know, they really haven't delivered right. Right, but their projects when they were admitted came in with the intent that they would go multiple. And I guess the policy change I'm proposing is let projects come in and let them say oh no we're going to stick with fabric. Okay, from day one and we don't plan to expand from that. And also I don't think we have any policy that explicitly says this right. Right, it's in practice. Great okay yeah it's been the attitude of the TSE that you're more likely to have your project accepted. If you say you'll support multi platform. Okay, and I guess you just want to sort of, you know, formally state this philosophy, rather than change any rule is that correct. Right, make the shift in philosophy formal. Great. Okay, thank you. Okay, Kamalash I think you're next. Yeah, hi, so as a recommendation perspective like projects and themes like as a community and the user of the technology people are mostly are referring to some simplification of the users of the project like for example like wallets. For example, for example, while they are building some kind of tokenization application on top of hyper ledger, they always challenges to having a wallet, whether they, they may need to customize or build something. So having a wallet in a, in a project in the future is good to have. Similarly, and there are similarly there are still complexity of implementing a hyper ledger technologies is very complex if you talk about the like ethereum or maybe like for example polygon or other like quorum. This is so much simplification of doing the network setup to tell building application. So similarly kind of about projects and themes that I think already we have mentioned like wallets and security storage and walls. All this kind of priority and I think other thing like all the audience teams, what are the priority we are setting here on its generic. What was the question on that again. There are a couple of things like the operational support of a specific reality and user focused projects for wallet so why we are like suppose this identify this task forces gaps in the, in the, in the project so what we are accepting in the future projects on some priority basis like we will consider some having a wallet project in the future with the more weightage to be limited earlier or so any priority perspective I mean to ask. I mean I mean like suppose we listed couple of things here in the task force like where the hyper ledger projects actually having gap right so suppose this couple of six seven categories so so we are going to accept the projects or maybe we are decreasing the community or the open source developer to build the projects in in this particular areas and maybe improvise the existing projects so any specific. Priority in terms of the those themes or I meant to ask that one. So does that have to do with the single project policy that we were discussing I'm missing the connection. I think this is a different question right I think it's a do we do we have a priority over which projects come in. First versus others right like would we would we say that wallets are more important than token applications. I think that's the question is it not come much. Yeah, yeah. Like like wallet wallet is kind of currently not an instant available in the in high. Okay. Okay. Can we discuss that we get to projects and themes and finish the subject on the Paul on the single syrup on the single ledger policy minute does kind of get into we prefer ones that are hyper ledger not hyper ledger but you know honestly I would love to be in a position where we have to pick and choose which one can come in first that's not where we're at right now. I think that is a good question for the projects as themes. Once we accept or not accept the explicit policy. So let's go to Tracy and then we'll come back to this if there's no other discussion on it. Yeah, so related to the projects that are focused on a single platform. I have a couple of things here that trigger for me. One is the discussion that we've previously had in the TSE around project families. One that we've had a long time ago on sub projects within a project. So I think when the hyper ledger initially started. We had the fabric SDKs as separate projects from fabric. And we got to a point where we actually ended up I don't know probably a couple years ago having a decision where we decided that those were no longer top level projects. They were projects that fell under fabric. And so I think there's this, you know, question about what. When we talk about projects focused on a single platform. What is the level of scope that we have there and I think the second sort of trigger that this had for me was a discussion that occurred on the chat right before. When the floor went end of life, which was somebody put on the fabric channel. A question about Explorer and I said well you should ask that in the Explorer channel because that's where the people are that are going to be able to answer that question. And I got back this response that was such that like, well Explorer only supports fabric so why wouldn't the people here in fabric be able to answer that question. And it's like, well, you know, I can't. You know I don't have an answer for that but go talk to the Explorer folks right. So I think there's a challenge that we have I think those are two challenges. The third trigger I had was. How big does the landscape become. So for example, let's say, let's just use the Explorer example again right. We actually do have, we had the fabric Explorer we had a saw to the Explorer we had an Eroha Explorer saw to the de Rojas explorers fell underneath those projects. And the fabric Explorer was obviously blockchain Explorer because that was the first one, first project that was accepted right, but the saw to the Explorer and the Roja Explorer never really got, you know, advertised to the wider world, because they fell into the source base, you know, under such a theory Roja right it might have been a separate repo but it was, you know, the same people were dealing with that. So, you know, if we get to a place where, again, we have six different or five different ELT platforms and we have an Explorer for each does that mean we now have five different extra projects, all called you know, something or do we say that these are actually sub projects or part of the project family of fabric or sauteed or Eroha or they do or etc right like I just, I think this is a great example. I think that we just have to have some sort of limitations here right like I don't think I can just open up my mind and say yes I'm going to allow that, although I think it's a great idea. But yet, there's some triggers that happen and we have to understand that you know there's some, some perceptions that people have when we when we talk about these different projects. Okay. And yeah, Explorer is kind of interesting because yeah I kind of fragment it and then some code bases accepted it and some did and some didn't. But I think you know basically never was terribly interested in Explorer because there were a lot of other open source Explorer projects that covered Ethereum blocks got I think is the one that typically got installed a lot of it and there's single purpose ones that were outside of hyper ledger. And so the functionality of an of a block explorer versus a project of a block explorer. You know, is I think is one that straddles the line very much between as a core is it not core. But I'm thinking stuff like like cello which is more orchestration that puts a different philosophy on the way you organize your notes versus the way you might not want to do it. It may not be as more on independent rather than the core side because it's more opinionated than how you might want to do it, you know, like, you know, the classic JavaScript UI things is an MVC is an MVMC, you know, all those other approaches to use react to use all the other stuff. So that's why I wouldn't get pulled into the core of the JavaScript language per se but it's a definitely only targets JavaScript. So I think we do need some some parameters on this. And my thought is that we put something along the phrase of the project community should be large enough to become self sustaining independent of the platform. Would that get to the core of the issues. So it might. I don't think it addresses all of them. But it might. I, I think the other piece that you triggered just now when you were talking about language is that we initially accepted you know how because it was a C++ ELT. And I don't know, you know, would we accept project X written in C++ written in Ross written in Python written in JavaScript written in go written in, you know, and have every single language be a separate top level project. At this point in my life, I would probably say I'm not happy with that. And that would be a reason, a good enough reason to say yes we should have a separate project. Okay. Jim raises hand. Yeah, I think my head is kind of similar place as Tracy. It's not very clear to me. For project that's only targeting a single platform. First of all, I do think that's, that's a viable policy change. But what's not clear to me is, do we continue to just have top level projects versus not because the implication to the level of hyperledger resources that will be put behind them will be different, right. Or do we need to create a new sort of project here that accommodates very good very useful top level projects but not, you know, not a large scope one that would enjoy the, the, you know, the marketing resource and everything that a typical top level project will have. Okay, hope that makes sense. Yeah. So, so what I'm hearing is there's there's not consensus that we should do this. And there's probably deep issues that need to be thought out online, possibly, or at least over a week or so. So I'm going to mark this as no consensus and table it and let's move on to the projects and themes. So we can get some more coverage on that. I think Kamalash's main question was what's the relative priority in order. And this list is different from my first synthesis list. And I thought I did. And to his point, I was putting this kind of in priority order of things that I think are more important on top of the things would be more aggressive and soliciting, but everything on the list is still gain. Low level DLT MPs libraries. I mean, they don't, they're not like, you know, they're not crawling out of the woodwork, you really have to hunt them down. But the right one that comes in, there's totally a home for it. And, you know, you don't know you need these until they show up for the most part. But everything else above this, I think this is relative order of where I heard where the needs were coming from, from the various party holders. The first one is, you know, there's a bit more need for operational support for these platforms, things to monitor and some of these are arguably just features that the platform should implement. But some of them could be separate. So it would be an example of like an orchestration support for these systems it's very opinionated about the way it's set up. It kind of fits into this, but not really it's more of a framework or it's its own thing for the most part, but it might provide, you know, that's something that can be built into it into an application framework like Firefly. Outside the DLT world. The application support libraries be more like the Ruby on Rails type stuff I don't really have no Ruby on Rails would fit into any of these specifically. But you know, projects like Ruby on Rails might have their own integration things like rails and spring might have some of their own integrations for some of these. A second one that I heard very high that I almost put on top of these, these two are two really close our end user focused projects, things like wallets and vaults for individuals and for enterprises to contain their keys and to communicate with the DLTs in an automated or on request basis in credential storage. I think that the growth of identity keys is an undercurrent that is growing and could become, you know, one of the top features from a project it could become one of the stealth features that's going to show some real value. Crosschain interoperability is always big. Cactus is doing great. But there are more ways that people might want to do interoperability. They might want to do token based atomic swaps for frameworks for that. They might want to do all sorts of level of interoperability. They might want to interoperate with enterprise systems. There are some last projects that are doing things like HLF connector where they take the stuff off the blockchain and they put it in Kafka cues. Those are some of the sorts of interoperability that I think are rich that are necessarily part of the core. And then as we get lower down, these are these reported valuable spaces in the future that we need to move into. But I didn't hear, you know, like clamoring from any of the any of the operational networks, but they they they seem valuable. So it would be a little term space to have stuff ready for enterprise applications as the field matures on one of those applications supports and libraries. This would be the sorts of libraries that you would use to build your DAPs. You know, like a Ruby on Rails for DAPs or some other thing and these are the features that probably would be when I had the policy change in mind to support explicitly single platform projects. The part on the stack where I was thinking that they would be most valuable is the ones further away from the the DLT itself that are separated by some access libraries that do things that on the application level. So perhaps an NFT app that only targets a Roja might be one that might be a top level project that doesn't require any core changes to a Roja. Similarly, UX libraries that support fabric in a particular style of the front end that only explicitly intends to support fabric I think could provide value as a project. So this and the next one are where I think that the single project libraries single single platform libraries have the most value. And the last next last one is domain specific tool kits we really have one in grid. But I think there's areas and things like Providence in intellectual property management and in operating exchanges. But not, you know, when Hyperledger wouldn't operate an exchange but they might provide white label software that if you wanted to you could if people were willing to bring that as an open source software for their for their types of things. And finally, there's always room for the low level DLT MPS libraries that are reusable across DLTs, or that explore new novel space. One example that's always brought up that we have never quite been able to pull off is the common consensus library and a common consensus interface. So that you could have, if you implement this interface and you have a new fancy consensus library, that is, you know, some sort of an asynchronous. Some asynchronous library to be really cool to put other things you can just implement the interfaces in your blockchain and in the consensus and things will magically start working. So I think there's opportunity there, but it's going to take some work for sure. This is the general ordering I think of, you know, what if we had a pick and choose an order and prioritize I think this would be the order, but I honestly think we just take them as they come. And finally, the non interested and I think it's as important to say what we're not interested in as much and these have been, except for the standards have been fairly non controversial. These first two are pretty, pretty well accepted hyper ledgers not going to operate a specific network. And I put a theory made it in here as an example base who is a client that runs on a theory main net, but it is not running a theory main net. And I think that's the sort of space that the projects would want to operate in in hyper ledger projects that work within service to network. But hyper ledger is is is is an associated with the project with the network governance is a can be. And then hosting a specific application, for example, we wouldn't set up a block explorer for theory main net that's run by hyper ledger that's something that would be out of scope. Hyper ledger might host a block explorer software, and some company could stand it up and run it their own. But hyper ledger itself would not expose that service to the public. And finally, operating the formal standards process we have a little bit of a sidebar on that already. And I think I'll drop this first line and use these two. It can be the facto standards but if you're formal, it's not HLF is around based on the formal process. And if you have an implementation of a formal standard. HLF is a great place for it. So Kamala's did this address some of your concerns when we were talking about single project. Yeah. Okay. Jim. Hey just want the list looks great. Proposed maybe a slight tweak. I feel like the world doesn't need new token projects but the world definitely needs viable confidential token projects. There are many efforts around this while a few efforts around this. None of them are widely adopted, but I do see a lot of requirement for that, you know, the many CBD C projects around the world that are coming online in the past few years. I would bet all of them would end up needing something like that. Yeah. Yeah, and about NFTs can we qualify specifically what we're looking for NFTs, because tokens cover NFTs I assume NFTs we're talking about maybe a marketplace sort of thing. One of the things that NFTs is people say oh there's utility for this. And I think that could be true like say if you have a NFT that represents the ability to moderate a discord room. And you can pass that around from person to person. You know how do we do that I think is one interesting use for NFTs. So have your hand up Jim. I'm done. Thanks. Okay. Yeah, we don't need a hyper ledger profile picture collection. Don't know if any enterprises that would need a PFP for other employees. There's no other questions on that. The last step is labs projects and this is where it was pretty late for me so I only was able to identify two good top ones I'm sure there's other ones because getting into these labs projects is kind of deep. So laying I think is one that would be interesting we might want to ask them to come up again. They pitched a couple of years ago. And I think the problem was they only have one active maintainer. They now in their project list three and their commit logs support that claim. And what I think it's interesting about it is the supporting in this goes into my elephant the room point at the bottom of this. And support still laying substrate me was for doing solidity for for those things for those platforms Tracy. Yeah, I just wanted to mention, Sean had reached out to me to ask me about what it would take to bring this back to the TSE for incubation he asked me that a few weeks back. So, I would expect that to show up here soon so I think you're on the right track and thinking about so long as possible in a top level project. Because he also mentioned right there, the expansion of maintainers to that project and contributors to that project and I definitely see a lot of discussions ongoing in the sewing channel and discord. Cool. Another project was per run which is confidential channels across multiple block chain that's got plugins to support that. Does anyone else have a favorite lab project that they think should be discussed with to bring up to incubation status. Tracy. I don't know about incubation status but I have been doing in preparing some slides, looking at kind of top 10 most active labs that we have. And the other one that exists between selling and prune that is top 10 is business partner agent which is an SSI waller and controller. So, then I also think there's a Ryan, which is a centralized ledger that has quite a few pull requests that are happening in there as well. And some fabric specific stuff that's going on. So, yeah, I don't know if they're at the state yet of wanting to come to incubation but at least as far as pull request. They filter to the top. Okay. Do you have the specific fabric ones that might, or should I just go to labs. There's a, there's a private data objects that is, I believe fabric based confidential preserving option is option smart contracts but I think it is based on some of the fabric stuff. There's the fabric operations console. And I think there's maybe some ongoing discussions around whether or not that filters to a top level project at some point or not. And then the fabric smart client is also another one. But yeah, those are kind of falling to the top 10. There's actually one which is fabric operator and there's like a whole bunch of different operators or hop can talk to this. I mean he actually, you know made the effort of listing them all and we've been trying to start an effort towards some convergence. And this would become that any of those would become a top level project because they are very fabric specific and have no, you know, no claim of ever being more than that. Okay. Yeah, so I, as Arno points out, I did go through this. I think we have something like 12 active and 23 total labs that focus on fabric operations. It's a huge number. We are working to try to streamline them. But it looks like from a sort of fabric maintainer perspective. The fabric maintainers seem to think that they would prefer, you know, sort of whatever comes out of this, you know, fabric operations collaboration, that it be sort of as part of fabric in a separate repo rather than be its own project. So it seems like the maintainers here might be happy to incorporate this into fabric in some form, rather than become a top level project, which is why I didn't initially bring this up. Okay. And any fabric maintainers on the call. Although I think Arno is the only person I see. Okay. I can clarify more, but yeah, we've been working on this. We've had discussions. This is kind of an embarrassing amount of fragmentation in our space. So, yes, no, but I agree you what you said is accurate and, you know, IBM. IBM, as you all know, I mean, you know, we've only contributed the fabric operator and just so that everybody knows this is by Kubernetes operators, which is a key element of actually doing, you know, deployment of fabric network in Kubernetes. Because there wasn't one as part of fabric, everybody created their own. And I developed one as part of for a proprietary offering. And we have not contributed that to hyperledger. I believe it is the most advanced it's a production ready it's been in use for many years. So, but we didn't want to just submit that as part of like fabric. We could have contributed to fabric directly. We try to play the card of being open and inviting others to participate in this effort so we first contributed as a lab. And now we're working with others. And, you know, I have to thank hot to nudge everybody to try to work together on this, so that we would work towards having one really awesome operator that everybody could use. Okay. I think Nathan's had a Santa for a bit. This is just a bookmark for an issue we might need to come back to which is that seems like an interesting and very useful graduation option of instead of something going from a lab to its own project, going from a lab to joining an existing project. I worry we might have some back doors or some check normally do when a project leaves labs that we might miss. I don't know if the lab moves in that other direction, but it seems like for community and collaboration standpoint, it'd be good for us to communicate to projects that that's part to contributors that that's an option and that works well. Just to add to that, Nathan, I think that's, if I'm not mistaken, that's what's happening right now with cactus and weaver right and bringing in pieces of weaver the weaver lab that IBM contributed to hyper ledger cactus. I definitely agree that I think, you know, just because something is built in labs doesn't mean that at some point it doesn't go into an existing project, or alternatively become its own top level project like or so did or cactus or right. So I think there's multiple ways of, you know, kind of using the word graduated that graduating from labs right. Exing labs is probably the better way of saying that. I mean if I may add I mean this was very much the intent of having the labs in the first place right to create some kind of ground for people to, you know, start to effort with that necessarily much pretension but with that possibility of being ready to move to a project, whether on as Tracy says, whether on its own or as part of an existing project. Okay. Any other comments for labs projects. So one thing I want to finish with this is a little bit out of the scope of project gaps but I think it's an opportunity and a potential threat we need to think about. And that is what is hyper ledgers public network story I don't know that we have one. I don't know that we need one, or do we need one, but it's something that I think we need to put our minds and what brought me up to this question was a few about a month ago I was watching one of the, one of the various Ethereum podcasts conferences are going on, and Ernest and young demoed a supply chain operation built entirely on Ethereum mainnet. And that brought to my mind that some enterprises may want to operate entirely on the public network. And I think that is something that hyper ledger needs to decide how they want to operate with with public non operating networks just kind of a foothold with basic as far as Ethereum mainnet. But the question there is do we want to fully commit, or, you know, how do we want to interact with this what's our approach and I have no solid answers for this. It's just something that I think I need to put in our minds as a technical steering committee is what we should do with it. Jim. Yeah, you know, I've always advocated for more integration with layer one, but in the approach where a permissioned walk garden is is running as a side chain, where the majority of the transactions is happening and either through token bridges or through some sort of roll up, which by the way I think the UI demo is is using a roll up technique so there's layer two that's running with their knowledge proof. So I think from what we've seen. It's, it's becoming a very useful pattern to use permission chains as a side chain but there is a way for value to flow inside and out of with with a little layer one. So, I would definitely encourage the forest to evaluate more in this in the space. Maybe a gap we missed, and I'll let heart have the last word because we're almost at time. Yeah, I totally agree that this is something worth investigating and I have promised people on this call that, you know, I will do some work on this. I know I owe grace, among others an email about this so grace expect an email from me hopefully soon. But yes, this is definitely, you know something that I think at least we need to, we need to figure out, you know, more about and what we should be doing. You know when we started hyper ledger in 2016. There's this general attitude among our member companies that that they were going to completely stay off the public chain. And that has has changed a lot. So, I would actually be curious to hear what, you know, a lot of people think about this. And, you know, what sort of involvement in the public chains is the community's appetite. I would suspect it's a lot more than people think. Right. Thanks. So I think we're at time so those are the findings of the task force. Thanks. Thanks.