 So we are at quorum Okay, sorry recording. Did you want to go down? Oh, yeah Well, I'm sure that it got going. All right. Well, I the end of the Nino's everyone Welcome to the hyper ledger technical steering committee call Everyone is welcome to attend this call and participate So long as you abide by the antitrust policy and our community code of conduct We've got a fairly action-packed agenda for today Kick right into things with the project life cycle task force at the end of or during last week's call what we discussed doing was getting ready to vote on the four least contentious or the four most completed resolutions and One of those we ended up having a little bit more dialogue on and one of them was Referred to the marketing committee Which leaves us with a couple of issues? So I'll turn things over to our know here to describe things further and then we can All right, thank you done So the first one is actually fairly straightforward. I believe Issue four was about this notion of you know, can you move a project back onto the into the life cycle onto the life cycle? path and There wasn't actually much controversy over that I actually suggested we move back in certain condition but the vast majority of people who express themselves in the task force said no and so the proposed resolution is That a project never goes back And it can stay as long as it wants in Incubation or active status because that was one of the key question, right? It's like well, you have a project that's in incubation It seems to never manage to qualify and graduate to graduate to active status Should it go back to something like a lab or something and or if it's an active status, but you know Getting go back under certain circumstances So the proposed resolution again is that we stay clearly that no they can stay there as long as they want That means the only way if things really derail though, they're kind of abandoned There's another path which is to move forward Towards deprecation and eventually end of life, but it's a one-way street. I Guess my only question with this is if you have an active Project that becomes I guess like uncompliant Like so for instance like Dan had mentioned lower. I think on like the CII and that sort of thing Well, what would that entail like it's still act it's still active in terms of contributors, but it's maybe uncompliant for some reason. I Think we would have to take that up in the TSC and try to work with the maintainers to make it compliant Maybe there's another resolution that that somebody could put forward with what we do with a bad acting project, but I'm willing to cross that bridge when we come to it And I mean, yeah, so and you know, hopefully in the in such a case we would find some kind of you know Amicable resolution otherwise You essentially kick them out by saying, okay, we're going to move you to end of life and get we shut down the project There's not much You know on the way to deal with that if that really can't do this If you cannot talk with them and find some reasonable compromise that isn't we find acceptable then that's the only outcome possible Okay, so I move that we take a vote on this Seconded All right, let's do this Viva vote chase. So we'll just do All in favor and then you say Everybody says that in unison more or less that kind of thing. So all in favor That was anything but in sync Actually helps when they're slightly offset and kind of get a rock. Yeah, that's true Opposed all right not hearing any opposition any abstentions All right issue number four or resolution four passes with unanimous voice vote on to issue five and resolution five Yeah So there was also this discussion about the beginning of a project I mean so far, yeah, obviously we started with the hip process to start the project So you submit a proposal to the TSE and then if it's approved you start in incubation but we also introduced the labs and This makes it easier to start projects with that much TSE oversight and so the question came up at some point whether you know, we should kind of push everything to labs as a first step and Again, I think in the end the discussion was pretty short in the task force people said no We shouldn't do that. There are plenty of cases where it wouldn't make sense It'd be odd and so we should keep things as is So the proposal is that no not all projects should be required to start as a lab and On the other end it does provide for the case where the TSE might still in its deliberation, you know About a proposal might say, you know what we don't think this is ready for a project But feel free to go create a lab So that's what the proposal basically says Okay. All right. Well, I move for a vote on resolution five. I second it All right again by voice all in favor All opposed Abstentions all right passes by unanimous of voice So issue seven is off to marketing for their feedback, but it is otherwise Complete from the committee's perspective. Is that right or no? Yes, that's correct And I mean basically it's kind of trying to endorse what has happened today to believe is you know Regarding the the how names gets our project gets name, right? So We can talk about that hopefully next week. Oh, well the week the week after All right, and this is the one that we wanted some discussion on during this meeting and we'll I Think we have enough time for for a reason of dialogue here before we go into Yes, so That's right. So this is issue eight. So the issue eight is about how we deal with new project that are coming that would be you know basically with that as a pretty Strong history where you might have the case where there's actually a company that has even shipping products and Now they are coming to hyperledger and say hey, let's start a project We're happy to contribute all our code and there was the question. Well, how do we deal with this, right? so The you know based on there was quite a bit of discussion about that one in the end I thought you know what captured the the seem to capture What people were thinking of a way to do it would be because so you don't want to give them a pass and get You know blow up all the the normal safeguards we have built into you know the incubation process with the exit criteria and And you know at the same time you Knowledge that well, they may be able to To be far along what you would expect from a normal project which starts from scratch So the proposal that's actually drafted basically says hey People are free to you know if you happen to believe that your project already meet the Execute area for incubation You're free to submit a proposal to graduate or request to graduate to active status at the same time essentially as you make a heap and I thought that that the advantage of making sure you know basically they go through the process faster But they still have to meet all the criteria that I required of any project and then But then pointed out, I don't think it's possible because you wouldn't be able to meet the criteria on day one because Part of the exit criteria is actually to be you know part of the hyperledger community and You wouldn't be able to have done all of that on day one and I think it's a it's a valid point so I'm kind of like you know Changing my mind of the proposal But when I looked so it led me to look very carefully at the exit criteria for incubation And the problem is the way it's written You could argue no, I can't meet those criteria Because we say well you should have created a repo for instance, but we don't say well it should be a hyperledger repo so Depending on which filter you use when you read the exit criteria, you know, you might argue well I don't it doesn't have to be within hyperledger and I can already meet this criteria And so, you know, I think it's a bit of a stretch My my my position is well, you know, the exit criteria need to be read within the context of hyperledger So when we say for instance, you must have a repo you must have a CI Setup with test all this stuff It is implied that all of this has to be within hyperledger Which makes it impossible indeed to have to meet those criteria at the same time as you just start the project Even though you may have a long history outside of hyperledger where you have a CI and where you have a repo and all of that But I thought it was an interesting kind of fact and I wanted to Bounce it with everybody here You know Do people agree on this basic principle that the executor you have to be read within the context of hyperledger And when we say you must have a repo it is a hyperledger repo So I very much agree that the conditions need to be met as a hyperledger project When a project moves from being hosted in one place to another the community doesn't always move with it And so it makes sense that you know, you may have met these criteria before but moving to hyperledger might have been For a reason that we don't know about like maybe the community has been struggling or maybe the company that was sponsoring it has gone away and so That I mean some of the contributors and maintainers may have also gone away. And so Seeing it in that light makes a lot of sense All right. Thank you anybody else I Think Nathan put it really well Okay, so that that seems where if conversions start there and so I will realize these proposal Accordingly and then next time we pray we should we should be able to close it great I for one am liking this process of having some Well-worded issues and resolutions put forth that we can go through this format on on the wiki with and get some good offline conversation Thanks. I agree. All right Navigate back from that to the Agenda here so the next thing is we've had the the CICD task force in flight for some time and I think we got a No doubt late last night or really this morning. I guess in time zone Yeah, and so I haven't had a chance to review it in detail. I did get to skim it a little bit I'm not sure where others are but Dave if you'd like to walk us through some Motion of that. Sure. Yeah, I can just hit the key point so that Going through the whole report. This was just a quick wrap-up based on all my notes that I had in front of me at the time Apologize for the you know not giving you guys more time to read it, but the upside of that is you know, we're not actually ready to make a full proposal to the TSE and have votes on it because There's still some outstanding investigation being done by the fabric team. However, the key points here are that like I said last week This is This is basically a sycophane task the problems are that no two projects are alike in their needs for CI and because we haven't required all projects to Get over on to the existing Jenkins and Garrett CI system a lot of teams have gone off and built their own so Trying to find one CI system that solves everybody's problems is basically impossible so to eat this elephant we decided to Look at short-term solutions versus long-term solutions We listen to a lot of the team's pain points and there are some short-term solutions that we're considering doing right now But We're not exactly in the right place to pull the trigger on it We're still trying to figure out what to do in the short term the fabric team is investigating circle CI and We've talked to sawtooth and Rohan talk to Indy about their needs and basically the short-term solution ideas are Well, let me put it this way so the goals that we were trying to achieve that's probably the best way to start here was to get all of the teams together on to some kind of CI system that the Hyperledger CA staff has Visibility into one to collect metrics. I have a number of security Checks automated checks and stuff that I'd like to put in there in place And we also wanted to try to use Hyperledger resources to try to reduce the burden on the existing corporate run CI pipelines So initially we wanted to look at trying to get everybody on to a single CI pipeline and that's where we got to the point where Everything like that that seems to be somewhat impossible Without some degree of pain, I should say So the short-term solutions were things like maybe we can Start reimbursing money-wise for The existing CI systems kind of release reduce the resource for the money burden Another idea was take the existing system of Jenkins and start running minions over on AWS to speed all that stuff up and another solution was maybe see a circle CI we or like GitLab or something we bless that as the The one CI system that all Hyperledger uses and we slowly start migrating everybody over Like I said, there's a lot of trade-offs here the long-term solutions That we were looking at we're doing Kubernetes clusters so everybody could just lift and shift their existing CI pipelines over on to a Kubernetes cluster There are some technical reasons for why we can't do that Again, some of the needs for some of the projects require having like bare metal VMs rather than containers, so that is You know again, not a perfect solution, but definitely one we can consider there were some concerns about being able to scale this up in the future right took a lot of initiative on working out the exact IT requirements and Money that we would have to put at this to have a unified CI system for all projects Turns out the budget would have to significantly increase if Hyperledger was going to pay for all the resources for all the teams to jump on to a CI system and by Significantly increase what we're thinking not 20% but like 200% We don't know the exact number, but that's just the rough scale of how it would have to increase So I would like to have the the 200% figure. You don't have to do it live here, but I Don't think it hurts to put all options on the table for the board Right. I'm going so this is just a draft and I was going to go Get rise numbers and and put more stuff into this the board report is a lot more detail This is just for the TSC and it was just a summary but the the full reports going to contain all the numbers and and March more detail on each of the teams. So Are you saying that the there is no sort of open source freemium capability to Engage or you know, have we have we had any negotiations at all with these companies? Yeah, we have been talking to Circle CI and There was no open source freemium kind of thing like they We were already talking about budgeting some money to Support moving over to CI CD or sorry to Circle CI to see what that would cost and it's it's significant It's not a normal Savings. We're still trying to work out what exactly they're per user Licensing term means in the term in the context of an open source project. So like I said, there's some ongoing investigation about some lingering details I think it's also kind of too early to even said guidance like like, you know, that the budget has to double I mean We're still trying to figure out if the quote we got from Circle CI is for a number of users That would that would have to grow linearly as we add projects or for unlimited Just in the way they define users is is just a little hard to Understand that we're working on that but also, you know get lab CI and and and Azure pipelines and some other things Are still viable candidates and we don't even have yet. So, so I don't it don't set any expectations right now I think about you know budget being being different. There's still a lot more research to do on that Figure out if it's more if it's less Yeah, well, okay. Yeah, thanks, Brian We just know that if we were to try to pay for them all we're we're trying to figure out how to do it cheaper and There is no obvious like ha ha we can save a whole bunch of money, right? The circle CI one is really interesting because that one makes it very easy for community Contributed hardware to join into clusters. So if teams had people with spare hardware under their desk or whatever They could put those all together Mike Water and I ran an experiment for the Ursa team I have a spare server under my under my desk and within a few minutes. I think like less than five minutes I was able to spin it up and Run a virtual machine on it and join the Ursa build cluster and it immediately started doing Ursa builds So that aspect of it was really exciting. However, you know, relying heavily on Community source resources like that is also has its problems, right reliability and being able to bring to bear enough resources to actually make a real impact. Sorry. I Guess the the the important thing for the the TSC at this moment is that we looked at all options and there are no good and this report is going to be fleshed out here over the next day or two once I Get all of my notes dumped into here and Yeah, I just wanted to update the TSC that you know The reason this has been slow coming is because there's no obvious answers And we're trying to eat an elephant The one thing I might want to get some feedback from you from the TSC members was is that we are Thinking that if we wanted to meet our requirements for doing metrics and security and transparency that in the long term We should probably look towards getting everybody on to one CI system Not only does that create like a tacit community knowledge about our CI systems So any new projects coming in would be able to talk to just about anybody in hyper ledger and and you know Get help on getting over to our CI system But it would also unify all of our tools and we'd be able to do better integration and and All of that right however moving everybody to a single CI system would be exceedingly painful from an engineering in time standpoint, so But that's where I'm gonna leave it off if you guys got any more questions I'll be you know paying the TSC mailing list as I put more detail in here. I Just have one question. I apologize, you know, maybe I should know that but I mean this Got not to be a very specific question to hyper ledger. How do all the projects within the links foundation do with that? So it depends on where you're where you're at in the Linux Foundation Obviously the if you're talking about the kernel project in the git project, they actually have External resources that Run against that project, but the project itself doesn't manage them so which is really interesting I talked to Constantine who Coordinates a lot of the infrastructure for the kernel project And there's actually external companies that run the the kernel tree against the CI test battery and things like that And the kernel project doesn't even run one Which is interesting I thought that was very very interesting. They were just like you know what we're not gonna do it All their developers are constantly building so I don't know they didn't see the need for it I guess As I understand it CNCF has the CI pipelines that were set up for Kubernetes before it came over So I think they just adopted that as their standard and and I don't think they Force all of their projects to do it, but they make it available. So there's that's sort of a middle road It's like yes, we have one if you want to use it. This is what you use, but you don't have to and talking to Chris Anna check there they Have had a negative experience with circle CI and a positive experience with Azure pipelines. Yeah, so so no Yeah, we've reached out. It's it's there's not a consistent Kind of repeating kind of clear answer on this either everyone kind of you know figures their own way out through this But we are trying to to learn from other projects All right, thank you You're welcome any other questions like I said that the Long-term recommendation I think for hyper ledger because we do have such strong security and metrics Initiatives would be to head towards one CI system for everybody Now whether we force all teams to use it or not that would be a TSC decision Whether we do a single blessed CI system would be also a TSC decision If that's what we think we're gonna head then right and I will have to do a lot of Financial resources analysis, you know, what would it take to get all the teams over on to this one that we're thinking about? And what are our options for scaling and and saving money in the long term? So I would appreciate any of the TSC members to you know reach out to me if you've got questions or any suggestions Yeah, so and we're gonna I'm probably gonna take this discussion of the TSC list and get it out of the meeting here When as all the details go in and we've discussed this So keep an eye there Yeah, and I hope you're getting good participation in the the committee itself I Think that the way that that some meetings go is when when nobody speaks up then whatever River whoever has spoken up ends up being maybe Disproportionately influential But that is only It's nothing wrong with with with that Voice, but if you don't speak up and you don't offer your suggestion, then you can't hope That the conclusion is gonna be what you what you have in your head. So I really yeah, we are getting good participation there Thanks for pointing that out then I did want to thank the community for their engagement on this we did Get feedback from all of the teams that have existing CI pipelines We've had consistent attendance from the fabric team and the sawtooth team I've been able to get Good interaction with the Roja team over email because what they were kind of time zoned out And the Ursa team always made themselves available. So they're Ursa, you know Indy areas teams were always made themselves available. So This was one of the the cases where getting participation was not hard Everybody has their own opinions about CI which also makes it difficult so Yeah, thank you guys for for engaging and participating and And think if there is a model not unlike what our know has done with With the The project life cycle task force that as you have some options on the project life cycle Right as you as you have a proposal coming together or maybe some some alternative proposals If you could put those up as individual pages and then that gives people something concrete to support or Suggest changes to yeah, that's actually a really good idea. I like how Arno did that We have these options. We have questions we want to bring to the TSC, but I want to loop back with Rai first before we do it and you know The member summits coming up too. So it would be really nice to talk to people Face-to-face. So I was just trying to get this report together for the board of like, here's everything we know about this So that the board can discuss it, but I don't know that we're gonna be able to make any decisions At the TSC here before the board And so but I do think that we should be weighing in from the projects certainly I mean You know it Certainly budget and everything is one aspect and that needs board approval understood completely But we shouldn't be choosing a solution that the projects don't want or are uncomfortable with and so I think there needs to be a staged Approval process where the projects are saying a verily this works for us and then that gets ratified by the board Yes, as opposed to the other way around where the board makes a decision and then the projects are like what the hell Yeah, I think the intent was that the proposal would come up to the TSC and It would have had the input of the projects and then we would bless it and recommend that board for new funding Right right and and you know, there's many projects represented on the TSC But I do think we also want to make sure that in fact all of the projects have Had an opportunity to weigh in if we're gonna go with the one C. I to rule the law Yes, that's nice. It's like rather than it being like, you know Like like this cliff where there's like this decision-made and impose on everyone else that what we'll do is Like you know with the short term Fix which is you know fix this for the current Jenkins kind of pipeline, you know We'll get that and we'll make a decision there and get it adopted Keep an eye out for making sure this is priced and configured so that other projects can pick it up as well And and and that we can start to get closer and closer to an ideal solution And it may be the case that there's still one of the R14 projects that decides that it's it's not what they want And they want they're happy to do their own CI and that we might decide that's fine You know, I Will continue to do the kind of long-term research on on other candidates Even as we solve the short-term problems and those two solutions may converge at the same point. They may differ. I think that's fine And to your point Chris the teams some teams including well specifically the fabric team is already investigating Potential alternatives to what they have now. I think they're they're playing We had a right and in Brian's note he linked to the presentation we had yesterday and there seemed to be You know again broad agreement that we could move off of Garrett and so But Conversely, you know, the other part of this is We can't let this drag on forever and ever For a variety of reasons that you know, but You know ideally we get a resolution fairly quickly Because I think the fabric team would like to do this before 2.0, which is the end of September October ish time frame So that we can then have a you know a consistent approach going forward Yeah, in fact a question I had asked in my email was To approve fixing what's currently broken, you know The Jenkins plus Garrett Kind of combo, you know or once once the group of people involved in effected kind of decide I think here's here's the answer to the short-term thing. Can we pull the trigger on? Signing a contract and and moving over that sort of thing, you know Or even even such smaller details as you know before making a decision That's the ICD can the fabric team move from Garrett to get hub You know those kinds of things probably could be Delegated out or or handled without without waiting for you know a master proposal Yeah, moving off of well. Yeah, but I Don't think it's it's necessarily that simple because then moving from Garrett to get hub would mean re-implementing a bunch of web hooks and stuff like that to trigger off the existing Jenkins pipeline I'd rather think we would want to do that one swell food as opposed to having to do it twice If you understand me, so so that decision combined with you know a move say to circle CI or Azure Pipeline That decision could be separated out from the You know solve the 90 percentile, you know CI CD problem for the whole of the problem Just trying to be iterative about it remove blockers try to get progress made It's helpful like with all the the working groups and committees to have the minutes there to walk through So to keep those things valuable This applies to all the committees and working groups. We try to make sure that the those minutes are actually Capturing the the useful bits of the message and are accurately reflecting attendance Kind of thumb in through those it looks like maybe that attendee list is probably cut and pasted from from one of the original meetings Yeah, I had heard that actually there's some of the other projects sort of drifted away And I understand if that's because they don't like where the direction was or they don't care I honestly don't know Well, I Mean to be honest some of the teams were like we like what we have if you're gonna make us move We're not gonna that was some of the initial feedback at the beginning and I'm not gonna name names but it was not just one project it was multiple projects and So we tried to lure them back into the conversation with the carrot of well, I feel like you does have resources for this and This could help depraise some of the costs that you're already incurring and That got them to the table at least but you know it largely The uniform response from all the teams was we're good. Thanks Right like nobody wanted to change That was pretty much the only universal agreement here and I had to convince them and ride did a you know a lot of work here Behind the scenes trying to get people convinced that you know on one hand We start we start talking about all these metrics we want to collect about Contributions and having automated systems around who gets to participate in the TSE elections and what our community looks like and all this stuff We have these directors from the TSE Then we need to collect all this stuff One of the best ways to do that is through the CI system, you know and the automated like merging of Patches and then building them and all that kind of stuff We can collect Statistics through that system and then I have a bunch of directives about doing ongoing continuous security checks for the the continuous delivery aspect of this and It would be nice to someday be able to issue a verifiable credential or verify will prove that says no known You know security vulnerabilities in the software or its dependencies are known at this time, right? And make that an active signal that users of our software can test or verify And it would be an automatic signal to them if we ever found something I mean, there's some really cool capabilities we could do through the dog-fooding process if we were all onto a single CI system But that's our long-term down the road. They're not something you face tomorrow and a lot of the teams were very skeptical so it was a very difficult task force to move forward and The participation was piecemeal It wasn't like everybody showed up in the same room at the same time We were constantly chasing down teams and asking questions and trying to get Participation however, they did make themselves themselves available even when they didn't want to and that's what my think. Thank you To the community was earlier. I did appreciate not just completely ignoring us So it's a difficult task that we were given. There's no easy solutions. It's an ongoing discussion like Brian said and I I guess the the thing we should do here is figure out what we can Approve from the TSC on the mailing list this week ahead of the board meeting So that if there's any budget changes we can we can take those to the board Next week. So that's it for the discussion here, though I don't really have anything else to discuss unless there's more questions And there's not going to be a change in the budget between in this next week That's correct. It would be more of an advisory of this is what we're thinking about We're still we're still way early for that. Okay. Okay. Sorry misspoke Okay, well, thanks for the updates and I hope Everybody can take a look through The stuff that was emailed and is now linked on the committee page in greater detail offline And we can get some proposals up onto that committee page That people can react to in their own time zones We can move things forward All right, the the last thing that we have on the agenda for today is to start to talk about the project pipeline and I'll get that underway and Then we can get a little bit of discussion going there. So our sort of unofficial policy all along has been That the the bar sort of goes up continuously as the ecosystem matures as the hyper ledger projects themselves mature so that we're always trying to get New capabilities into hyper ledger and not necessarily get redundant redundant projects. We've in the past had redundant projects at some level of abstraction, but that's that's usually been because We have unique capabilities at the lower levels of those projects We wanted a degree of experimentation that can take place in the marketplace By by letting these different projects grow and thrive on their own merits So as we will continue to get new projects, it's beneficial if we can give a little bit more direction to the broader community about what kind of things We're looking for at hyper ledger and what shape those things should take on What we've been talking about a lot this year is componentization or convergence and our good accomplishments since fall of last year are bringing on Ursa and transact to start to Look at things that are common across the projects and make Things that are more like libraries that the frameworks can consume with with maybe a more distant vision that There's sort of a cohesive hyper ledger that people will build applications against as opposed to More proliferation of silos where there's fairly independent offerings from from hyper ledger under the original umbrella notion Want to get some more dialogue going on that? probably On the email list of course But also getting some of that back and forth here. Well, we've got people's time So like to hand things over to Chris To kind of continue this discussion at this point Yeah, I mean I think so You know my perspective has has been that You know just adding top-level DLT projects in particular is Sort of counter productive to Driving towards the consolidation that Dan talked about You know we set up, you know the architecture working group and various other working groups to try and drive You know aligned thinking around some of these topics to get a better understanding of you know You know what these things should look like and And yet, you know after you know three years now we still have sort of you have like five top-level DLT's if you incorporate, you know if you include indie Plenum as a fully-fledged DLT and and And Not a lot of alignment, you know a little bit with you know burrow EDM getting baked into Seth and fabric I think that was a good start and it gave me a lot of Hope you know that you know we could start driving towards alignment I think transact is you know and and Ursa are also Sort of moving in that direction where we're thinking about as a community How do we drive alignment around? You know, what's what's a smart contract engine interface look like? Can we incorporate the same thing into? The DLT's and then start thinking about okay, so maybe we specialize on you know whether a DLT is You know order execute or execute order validate or you know Or whether there's you know different forms of consensus plugins Or whether they're oriented a little bit more towards, you know, IOT or to you know this Flavor of use case and that flavor, you know But again starting to drive towards a model where you know, we have a bunch of pluggable components that you can build your millennial Falcon or you can build your Millennium Falcon rather or you can build I was gonna call you on that Yeah, you're you're you're you're at it, right? Depending on what you need, right? as opposed to should I use this one or that one or that one and And then you know sort of having the projects pitted against one another as In some sort of a you know bake-off, which I think is counterproductive and you know, we had the conversations at the At the hackfest in Where were we? I think we were in I think No, I remember where with the where the hell we were it doesn't matter Amsterdam I think maybe and you know, we were talking about you know, should we you know have You know sort of differentiating things about each product project and you know, basically the well, certainly the sawtooth and the fabric teams were sort of completely against the idea of trying to sort of Say, you know, which one is better for that or the other thing because they're very similar, right? And you know, you know, I think it's it's unhelpful if we're competing against each other It doesn't lend itself to You know trying to drive towards much more of a cohesive and collaborative community that's You know exploring innovation together as opposed to trying to compete with one another for You know for eyeballs so Adding, you know more projects to the to the top level doesn't excite me adding more trans acts and urses and You know raft plugins and stuff like that. That's you know built on a common framework That that excites me that gets me a lot more It gives me a lot more hope for hyper ledger generally if we're kind of aligned in our thinking about some of these things it doesn't mean that we can't have an identity flavored thing and you know supply chain flavored thing and a You know finance or token flavored thing, but You know hopefully built from a lot of the same component tree Thanks for that crypt. I wanted to put Been on the spot next been I think you'd communicated in the past that you know, we need New functionality or at least the entirety of the hyper ledger feature offerings Isn't yet So what if you've got some thoughts about that to share? Okay, so I don't I guess I Didn't expect it this to have the floor So I'm gonna say whatever on my mind And in the past couple of years I've been trying to to build a very sophisticated, you know enterprise grade application on top of blockchain and You know as part of the company we certainly Not tie into any type of implementation, so we certainly evaluated Different different frameworks if you will or different implementations of blockchain And and certainly we pick one to go and we pick fabric for for a number of reasons because you know I was part of it Well, I am still part of it But the Even with that there's still lack of you know key basic key functionalities that are needed for an enterprise application and and not not just fabric All of the frameworks out there so because of that I Have to keep my mind open because this is a very we are still very early in the development Blockchain of BLT I'm looking at the history of the database, you know, it's been like 40 50 years now But new databases still come out You know back in the 90s. We never heard of the databases that people are using today So, you know, why would we say that we are at the plateau now that the frameworks existing today Are going to be the framework then we need to focus on last number of frameworks, but more on collaboration That that's that's one side of it the other side of the coin is that you know, I feel like I Competition is really good thing for the community You know, certainly it can bring up they can competition certainly can can bring about some other things and Un desirable things, but if we manage it carefully internal competition is always good because competition is what drives the next evolution or the next revolution In whatever we do So because of that I want to keep an open mind What what what Chris said and you know what we've been set forward to do I In general agree with that that is more collaboration is better But that doesn't mean that we shut down, you know on accepting new things into the community to enable that next ways of motivation That because of that people might think about something else different than because of think be able to think about something else They find it would take us to the next level That we might call it evolution or revolution depending on the technology that we encounter at that point Or we be able to create at that point So, you know, I wouldn't at this point in my mind I wouldn't sit back and and say, you know, we We have enough here and you know, we need to think about collaborations that competition at this point Because it's just too early You know, whatever we have out there And I'm very sure it's not going to exist in in the short future because new things are going to replace Whatever we have today You know the same as any other technology that we have seen over and over again in the last, you know four or five decades New things are going to come and replace whatever we have and because of that We have to have the community to be able to to to be vital to be to be active We have to bring new stuff in Okay, great. And I think thanks for that, Ben. I think those are two Two good forays into the the beginning of the conversation here that we pick up on Mail and so forth as we move forward. We have a few minutes left that we can Call for any questions on the identity working group update. I Suspect will have to hit the fabric report next time But first off, are there any questions on the identity? quarterly report Okay, not hearing anything. Maybe we can actually quickly hit the fabric Order the report as well. I was able to review the identity one, but I don't think I've gotten to this one yet myself Any Questions from the the TSC on this. Sorry. I was on mute. There's not a lot Sort of new from from the past although again, you know, we we did do 1.4.2 release that last week That includes the migration from Kafka to raft As the sort of the major new functionality The diversity has increased A little bit more than the last time we have I think we're plus 3% Minus 3% if you depending on how you want to look at it, but IBM is at like 36% now and We still we want to grow You know, we're looking at various things with Salona and team on how we can improve You know diversity how we can grow our committers and contributors rather and how we grow our maintainers had open Invitations to a few people, you know to step up and do some reviews, but that hasn't happened. So Yeah, it's basically We're chugging along and things are improving just not maybe as fast as I'm gonna like them Kind of thing into the year kind of thing Sorry the the 2.0 is that a this quarter next quarter and a year kind of thing We had been planning to do so we have released a 2.0 alpha and Now that we finished the 1.4.2 work to get the migration to cough from Kafka to raft Focus now shifts back to 2.0 the major new functionality there is the the revised sort of chain code lifecycle But we also want to get in sort of the the validation pipeline refactor Because that enables things like tokens and you know post-order execution things like that that I know people are interested in the question becomes What what do we call 2.0? There's gonna be some things that are be ready in the fall and maybe we can do 2.0 there Or maybe we wait until the end of the year and try and get a couple more things in to make it a little bit more distinct from 1.4.2, but that conversation is going to be happening over the next couple of weeks is Based on what we talked about yesterday Okay, great. I think that brings us to the end of the time So if anybody has additional questions, I think you all know how to find Chris and the other Fabric maintainers on chat and email And thanks again everybody for your time and we will talk again Not next week, but all right Joe. Oh Thanks everyone