 started. Okay the recording has started. All right hello and welcome to the Hyperledger technical steering committee meeting. Everybody is welcome to participate in our open-source community and this call as long as you abide by our antitrust policy and our community code of conduct. We should check both those out in detail but in short the latter is be polite. All right we have a lot of things to discuss today or at least we've got some discussions that I anticipate might take a while including our ongoing discussion about expansion and convergence. So what I'm going to try to usher us through the first several topics here with the hopes of leaving as much time as possible for that discussion. But we do want to make sure that we've got everything covered so feel free to speak up if we're moving too quickly. First up for the announcements the election is underway. If you have contributed this year which is something like a commit or participating towards a work product in a working group you should have gotten a form in email or you should have subscribed to the contributors list and you can see all that at the link in the agenda if you are missing something. Last week we heard about the new meeting to get the marketing team and the contributors together to make sure that the projects are being conveyed in a way that the contributors to those projects are happy with or vice versa that they can help the marketing committee better promote those projects. So make sure that you're taking advantage of that meeting. Link is there for that as well. And then we've got a boot camp coming up in Russia. I guess I could have put these things in a slightly different order. We've got the maintainer summit first in Minneapolis followed by the boot camp in Moscow the following week and links are up for both of those. Last week we also took ownership from each of the the TSE members took some ownership to go reach out to different maintainer communities to make sure that they're all recruited to participate. Saw some threads for some of those. So thanks for following up on those. We are looking for more input on the agenda for that summit in particular and you can feel free to add that directly to the page for the maintainer summit. And then the last announcement is kind of a pre announcement that the diversity stability and inclusion working group has started designing the community survey. We want to use that to baseline the diversity and stability and inclusion status of the community but also looking at maybe getting the developer survey questions that we've done previous years integrated with that. So looking for some initial feedback on that and we'll bring something for review probably in a week or two. It's sort of just started at this point. All right. Do we have looks like we've got the rest of yeah okay got everybody else here so great just in time for the voting topics. So composer maybe about a year ago started signaling that they wanted to wind up new feature development and they formalize that now in a note that you should have seen on the TSE list looking to move the project formally to deprecated status. In the policy that we ratified recently projects their maintainers can request to move to deprecated status and the intent is that after six months then the project would be end of life and archived. In the note to the TSE Simon noted that they might want to continue to merge fixes beyond the six months and I see no issue with that. So open it up to some brief discussion here if anybody has any objections to allowing composer to move to deprecated status. So my I guess it's a clarification to me end of life means we're not doing anything with it. I'm fine with it going to deprecated status but if they're still going to fix certain you know issues that that are found then it's not really end of life right or is it think stages. The first is deprecated where the intent is that the maintainers are trying to fix at least emergency issues and the community can be moving off to other tools and then the second is end of life to where there won't be any more changes to that project. So is it correct to say that the plan is to deprecate it and then wind down towards end of life in six months but with Simon's note that they might take longer than six months meaning they might fix things longer than does that six month window. Right is Simon on himself or Caroline or Dan all right I don't see them on but yes that's that's what I read from the email that they want to move immediately to deprecated status which is effectively what they've been in for a while now but they want to keep composer in deprecated status for about six months but they just want to keep that end date loose so if they need to merge in an emergency patch they can still do that. Any issues with that? Well I'm fine with it going I just if we declare it end of life then we shouldn't do more to support it at all I think by definition so is end of life a separate voted on step as well? Yes versus okay so then yeah no I'm fine with this. Okay I think we said that we had to take a vote is that sound right Arnaud? Yes I think that would be good. All right so let's do just a voice vote then who's taking minutes this week by the way it's like Dave's on? Yeah I'm here are we doing this roll call vote? No we'll just we'll just do a voice vote I just wanted to make sure that yep I yeah we're freaking this is being recorded yeah and Ry is here so he should be recording it so the votes will be captured and reflected in a minute. Excellent all right so all in favor of allowing composer to move to deprecated status. Any opposed? Any abstaining? All right that passes okay on to the Gardner proposal and where we left off with Gardner sort of dovetails into the subject that will follow this which is the TCF proposal there's some observation of some functional overlap there with Gardner being an oracle and TCF having an aspect that is potentially like an oracle and there was a request that those two communities talk and come up with a plan so my understanding of that plan is that Gardner would like to create a lab for the Gardner code base and then also simultaneously to join the TCF community and work towards integrating components that come out of the Gardner code base and otherwise working to improve and create the TCF code base. Is there anybody from Gardner proposals on and or TCF that can say if I've got that correct? It's Eugene Jarmusch from TCF I think so but I think there is somebody from Gardner as well. Yeah this is Ekin here I'm from Gardner and yeah yeah this is what we agreed on doing this week with TCF. That's wonderful well I'd be happy to sponsor that lab if you still need a sponsor and the process for creating a lab is posted up on the GitHub site there for the labs but we can also direct you to that on chat or the mail list as well. All right that sounds good yeah yeah definitely that'll take the kids up and how to get that lab started would be nice to you know maybe some sort of introduction the process like one-on-one as well or like somehow like that. Yeah absolutely so we can set up time to do that outside of this meeting. Well I think that's great that both of your communities were able to get together so quickly and show some quick collaboration. Yeah it's very excited we're very happy that the Gardner team to work together and yeah we're excited about TCF and the value that we can create together. All right thanks. All right without further ado then we can move on to the TCF proposal so Eugene would you like to take us through a summary of the proposal I think most or all the TSC has reviewed that over the couple weeks that has been out there. Sure so proposal obviously is online and the idea here that we're trying to address the scalability and privacy issues using the different trusted compute options starting from the Intel HGX and then adding additional components what is we're trying to do also trying to make sure that we use these trusted compute options to afloat execution from the blockchain and the most specific examples would be the example genomics that can run days or it can be IOT streams that can produce the volume of the data that too many to process on the normal blockchain and that is type of usages that we really care about we also want to present preserve the computational trust and we believe the trusted compute options and including ZK, MPC and ET environments provide a good way to instant computational trust to these type of use cases and the finally we trying to be to drive adoption of the standard base implementations because we believe that this is one of the major obstacles for adopting the DLT technologies in enterprise world so we're starting by implementing the specification that's called off-chain trusted compute specification developed using the enterprise Ethereum Alliance and using the trusted compute work group so that is pretty much kind of like the high-level summary and we do have a pretty good community that already interesting in the this project I think we have total 13 sponsors and practically all of them committed real resources to work on particular areas of interest and the good news that they focus on different areas so we can build up community make it productive I believe pretty quickly so that pretty much all I have for now and feel free to ask questions okay thanks for that Eugene one thing that sticks out to me is that I think this project has the largest sponsorship of any that we've seen so far if not the largest certainly close to the top so I think that speaks a lot for it Eugene can you talk a little bit about what the sponsorship commitments are to the project so we have a number of different commitments for some companies has been involved in these work already that for example like I exact the the initial code base that has been committed to hyperledger lab is actually came from three sources it came from the initially from the PDO project private data object it came from the then it was taken private and the Intel made the necessary adjustments and modification to turn this into TCF but also during this stage had the I exact as a contributor so I exact current level of contribution primarily focused on what we call a proxy model integration for the Ethereum and the they also working on the use case a vision the heavily promoted vision the call trust in tokens the chain link is a company known for town crier is going to work on the attested oracles the the gardener that we mentioned during the previous topic of that is actually they're going to work on some debugging tools we have IBM contribute as a contributor who is interested to integrating TCF with fabric Intel could obviously going to work on the core components we have an interest from Alibaba they want to provide the goal and environment by do also wants to integrate the MSAT environments we have a BGI the company from China working on genomics and they want to continue on that and also contribute to hyperledger fabric will have the contribution from can sensors but this is mostly on the architectural side because they very active in the EA we have collider collider is a company that provides manageability solutions and they're going to work to provide manageability solution for hosting trusted compute service and cloud services we have Microsoft that provided the Azure resources for the hosting T testnet and we also in discussion with them only some number other topics are there for integration for example for EA we have a certain there which is the bank federation that I'm going to work on a number of finance related use cases and finally we have we pro who is going to contribute to developing new form of the more trusted compute options like ZK and MPC okay that was quite a mouthful Nate did you want to pop your question out here to the to the group John take the lead on this question but as we've been diving through this project proposal it really clear that it seems to have pretty broad base support especially from the traditional smart contract approach for those of us who kind of sitting out a little bit outside of that smart contract approach I'm having a little bit more trouble understanding how it overlaps with both the transact project as well as with Ursa relative to both the aims around multi-party computation and zero knowledge proofs but also around how low level is the the component and how reusable it might be relative to to what we're doing with verifiable credentials and other mechanisms for creating at the stations so I can take just a piece of that anyway the so TCF sets up a lot of potential off-chain workers and it accounts for zero knowledge mechanisms but probably not yet in real specific detail so I think one of the ways that that I foresee interacting with this project and Ursa is trying to take what we're working on in Ursa and make sure that that can be leveraged in TCF and supply any requirements that that we can provide to make sure that that can be described through the TCF interfaces so if if TCF is an interface-based system what does that mean relative to hyperledger transact so that is a little bit different approach as I understand so we are looking into this area and my understanding then Tragnzact is mostly focused on the executing the smart contracts on chain and they may or may be a trusted compute options or they just can be a regular environments while the trusted compute framework focuses specifically on the only on the trusted compute execution options and executing these smart contracts or workloads we call them the off-chain so that is I think that is where the difference how to converge them we would have to look more closely and that maybe another way of thinking of it is the transact is about the sort of what you're executing and TCF is more focused at least in this incarnation about where where do you get the resources to do the execution so so Nick what would you how would you describe any convergence that might happen there you might very well have a way of running an instance of transact inside one of these trusted execution environments that are allocated so if you think of the the TE what what you are running inside the trusted execution environment that you're receiving is independent of the specification of TCF so you could put a transact instance inside there if you wanted to and and I'm saying that in the most absolutely general terms possible because I have no idea how to make that happen but but you might imagine that or you might imagine taking a wasm or EVM and running it inside there as well so it's it's less about so TCF is less about what runs and more about how to allocate the resources and get the results back in a trustworthy way yeah and I guess my concern here is as we get into a practical implementation that they'll both solve the easiest parts of the problem and they'll turn out to be the same parts of the problem but if we're kind of visualizing that there's overlap either in the personnel or in the approach in the sense that they're at least theoretically something they can come together I don't think I have much of a problem with that I don't see any theoretical problem I see a lot of a lot of engineering issues in order to make it work and and I will say from our side you know the work that we're doing and on the PDO is really the research that's feeding ideas into things like TCF and so you know trying to come up with for example a wasm contract interpreter that could run inside an enclave that could be you know a stepping stone towards a more general execution environment and those are the kind of things that we're worried about yeah so how I think of them at a high level is transact as a library that facilitates integration for contract interpreters and TCF is in a way a set of contracts that facilitates discovery and dispatch of workloads to off-chain stuff and that off-chain stuff is where maybe there's another potential integration point that really Mick was talking more about that if you're going to treat that off-chain execution environment as a smart contract interpreter then maybe you would leverage the transact library in how you construct that but I see them as occupying principally different areas I think so the other end of the integration sorry for this as well is and the bit that interests me about TCF and Gardner is scheduling your off-chain computation from a smart contract so requesting some work to be done and that happened I think the other perhaps dividing line maybe to draw there is that this is a kind of this is an asynchronous model you wait to get the results back whereas transact is synchronous so just a question because I'm not a big security guy but is this reliant on SGX or is it one option it's a one option okay because SGX hasn't been accepted by the upstream kernel right by what it's has it been accepted by the ups in the upstream Linux yet yeah there are definitely Linux drivers for it there's Linux drivers for it but it's not upstream Intel offers drivers right not let's go too far down I yeah I was gonna say I don't know that that's a I hear what you're saying the installation process of the management processes are pretty straightforward so yeah GCF is a spec in the talks about how you could do off-chain trusted execution either through a trusted execution environment or through empathy or nizek so yeah so yeah so mark just to remind you that one of the contributors one of the sponsors is specifically focused on adding the zero-knowledge pieces of this as well and there are other TEs beyond SGX that would be potential places where you could hardware-based TEs where you could do this kind of execution as well. The spec is actually pretty general. Do we have any contributors or maintainers looking to support anything up in the SGX? I think Eugene mentioned one of the companies is is actually focused on doing the zero-knowledge group yeah the Russians on it and it's still very early clearly the first implementation will be from the SGX side of things but that is also clearly not where we want to stop. Okay thank you. So I had a question. Sorry I have another question to just follow up with that. So I think it's still very early to talk about you know the release of this framework someday but what would you envision the release of this framework would contain would that be SGX in the addition to zero-knowledge or in addition to other trusted framework implementation or you would come out or would it be okay for you to come out with only one solution provider? No the one solution provider probably won't work because even the specification and its current state calls out for these three different types of transaction options we expect that to continue to grow and one of the key objectives for the release of the TCF would be to make sure that we support all of them or at least most of them so that is the criteria for the release well let's call that product release of the TCF. Great thank you. Okay my question yeah thank you. It's kind of it's a little bit what was discussed earlier but I'm wondering let's imagine we have a network with lots of participants that's what we want to have on networks and you've got one participant who has chosen to do their trust would offload in SGX and you've got another participant who's decided to do it with zero knowledge and those participants want to do business together or transact or operate on the chain in such a way that they both end up executing their contracts or they move something between them or whatever so they have to trust the operation of the entire chain and both of those contracts into the operation. What's the plan for how person A or party A would validate the attestation and the quality and the security of the TEA chosen by party B and vice versa is there ever any suggestion or intention that all system participants should be able to deep quote all as all trusted aspects of the system because the diagram on the wiki only really goes as far as the contract owner trusting the offload of a bit of their contract to their chosen enclave technology but of course not everybody trusts the same stuff. What's the thought about mixing and matching here? So the it's a very dry document but there is EA specification and from that EA specification the summary would be that is a specification itself treats all trusted compute options identical and treats them as a black box as long as party A and party B agree that two different trusted compute options equally suitable for them they can execute their workloads in those options obviously the workloads going to be different so how are they going to know that there is going to be a published information attestation reports about the each of the workers so they can know that they can trust those workers and once they execute it there is a mechanism how they it's called a seeds how these receipts recorded on the blockchain and the boss parties can acknowledge they agree with the results. So fundamentally the is the assumption that they have to be mixed and matched freely for the execution obviously since we don't have real implementation for multiple options yet we will have to finalize the details of the specifications and obviously the implementation to make this real but that is definitely the intent to mix and match them as needed. And just to be clear on that Eugene what you're saying is that the trust relationship to really punted to the parties that are trying to agree with one another rather than being formalized in the specification right? That's correct so certification is kind of dry specification and it leaves a significant room for the interpretation and so in the application specific implementations so obviously we cannot define everything in this back. Okay I think that runs the course of the questions that we've seen so far in the interest of time and getting to our expansion and convergence like to move that we take a vote on the TCF proposal. Somebody like to second that? Second. All right let's go ahead and do a roll vote as this is a project proposal. Do we typically do roll votes for project proposals? That's my recollection. I'm getting to the I'm getting to the list. The list is at the end of the page. Otherwise you can just click on the technical steering committee on the left and you'll have a list of people. So Brian is pointing out something good that we should probably approve condition on a new name from the marketing committee or a new name in general? Yeah so I think what we decided is that we don't approve views that'll be worked out between the marketing committee and the project proposers. Okay Arno? Yes. Bow Wow? Yes. Ben? Yes. Chris? Chris? Yeah. Dan? Yes. Hart? Yes. Kelly? Yeah. Mark? Yes. Mick? Yes. Nathan? Yes. Silas? Yeah. Motion passes. All right congrats to the TCF team. Excellent thank you guys. All right now on to the main event in some sense. Expansion versus convergence. We've had pieces of the discussion over the last year and the opportunity to bring in Bezu is sort of crystallized some of the possible outcomes of of those two options. I've linked in here some of the thoughts that have been captured on the mail list and back to the notes from last week. I think we may have even talked about it some in the week before that. So want to open it here to some discussion so that we can get all of our thoughts on the table and then ideally we'll be in a position to vote on Bezu after that. So I guess can I start? Yeah I was gonna I was gonna help tee it up in case people would put your word to get going but please. Okay I'll get it rolling and I'll sort of bring back you know or bring up the the points that I was trying to make and some of the more recent comments in the thread. You know I think that you know it's fine if in fact you know Hyperledger is going to have a feel that's more like Apache than say Cloud Foundry right. You know where there's multiple projects some are competing or you know overlapping in their capabilities and you know maybe you have different constituencies or what-have-you versus projects and sub-projects that are really coordinated and organized around a common framework or something like that right. Because again when you think about okay so let's just consider from a sort of a marketing perspective if you will Apache markets Apache and the Apache way they don't market Hadoop open whisk you know Kafka rabbit whatever that's you know those are the projects are not the thing that's important the important thing from an Apache perspective that they communicate when you know they have their annual conference or at various other venues they're promoting the Apache way right how they help projects incubate how they help you know drive very rigorous IP licensing regime over the code base so that the code bases can be trusted makes it easier for people to consume the open source that comes out of Apache because they can trust that it's not gonna be wackadoodle from an IP perspective and the fact that they have you know a ton of volunteer mentors in the community that work with the projects as they come in and ask you know seek to be incubated and and work through their incubation stages to become active such that it scales to I don't know it's close to 300 projects I think Brian maybe you know more than I do but it's about 300 or so projects now but again you don't see Jim Jielski or Sam Ruby or you know anybody else running around promoting Kafka for instance right that's interrupt that's not quite true we do have the concept of hats horn this is Jim Jielski speaking by the way and so for the projects that I am involved with I do a lot of promotion about those projects just right but you just said you're wearing your whatever project hat that's right yeah well that's that's a clear distinction from wearing your hat in your formal role on the on the Apache board or in the leadership right okay I just wanted to clarify the confusion that the ASF as an entity does not provide services or promotion to the projects beneath of it well but they do so conference itself you'll see that the number of sessions which are specifically about Apache itself the Apache way is very very small regarding the actual projects that are being promoted but I'll let you finish yeah but my point though is that okay again there's no overarching architecture you know technical steering committee what have you that says how the projects have to relate to one another or any of that right there's it's definitely the whole function of the ASF is to provide a safe place to collaborate and build communities around projects that's it right I mean you know at one point you know it was Brian and a few of his colleagues building you know the HDP server but it's grown into all kinds of stuff areas that had nothing to do with the original purpose of the ASF in terms of what projects it was hosting and and and in fact many of the projects have sort of competing marketing endeavors to sort of you know Cassandra is better than spark or whatever you know and and that's fine right but Jim you don't have to run around and choose sides right you know or try and make you know sort of arguments about what you should you you know should you use spark in this circumstance or Cassandra or Hadoop or whatever in some other circumstance you're neutral on that point unless of course it's a product that you're working on in which case you're speaking on behalf of the project I guess that's my point right when we have a lot of the messaging that comes you know Brian you know when you go and talk and you present here the collection of projects that we have but then there's this sort of inherent need to try and rationalize them against one another when in fact it's just a collection right if that's the case you know they may be organized around a common sort of a theme of blockchain but boy I tell you I it just I don't know how you get to the point of trying to do the reconciliation of saying without necessarily getting you know into sticky sort of situation about recommending what people should do and yet I think they come to expect well hypervisor should be sort of telling us what to do this is this is the problem that I have again I'm not I'm fine if that's what we want to be but if we are going to be like that then we have to provide a means where basu can sort of market itself and fabric and sawtooth and what have you and yeah there may be projects that are designed and intended to be you know like Ursa and transact and TCF and so forth that could be used in multiple contexts but you know what do we do with the top-level ones hey Chris this is Brian since you call me out specifically on this again I'm not calling you out I'm just making that observation it's it's a challenge for sure I don't want to minimize that and it's a challenge that can only be really met by working with everybody on the different projects to describe people articulate the unique advantages of the different projects and the more that they directly overlap obviously that's that's hard right and ironically the more we work towards convergence the less those differences may be right but but we're up for it I think you know we I think we went down a path pretty early on that was a middle ground between you know Apache you know having having a really expensive from it anybody can come in or or any of the kind of single architecture kinds of projects out there including the Linux kernel right but but this is not out of trend with where you know the cloud native compute foundation goes or you know some of the newer projects CDF continuous delivery foundation those sorts of other examples I gave and I think we're not alone in trying to figure out the answers to these questions but that this picture of a portfolio organized community like hyper ledger is is becoming more than norm and we're certainly eager to learn from others on how we can be both champions of the broad as well as champions of the specific and anyone who's heard me talk has probably heard me go into you know advantages of many the specific platforms including fabric and I don't plan to let up the gas on that so I think I think let me just wrap up with convergence is is a process it's not an end state and I I feel like as long as everybody is committed to other projects coming in are committed both that they are distinct in what they offer like they are actually offering something new and genuinely committed to participating in convergence related processes no matter what the end state ends up being then the night that's that's all we need to be able to go out and be a champion for each of these projects and I think I think to be able to pull together as a technical community as a portfolio okay thanks Brian thanks Chris I think there are some other viewpoints that were being discussed on the list more on the the technical aspect as opposed to marketing and so maybe if if those individuals can speak up at this point particularly on that architectural convergence front looks like Hart and Nate are battling for who can make the longest paragraph on chat yeah and I'll go ahead and summarize what I've sort of said is that sure if we have more projects and you know more things going on in hyper ledger it might increase fragmentation and make it harder to converge within hyper ledger but it's naive to think that if we don't include projects that they're just going to go away they're still going to compete for contributors for users for everything else with this outside of hyper ledger potentially in a much less friendly way and we will drive more convergence in the space as a whole I think if we accept worthwhile projects and that that's just my opinion in a very brief summary and my paragraph reflects some of that same sentiment that we're really trying to get the best folks at the table to collaborate on ideas because it's not just about the projects we have in the greenhouse today it's about getting the right people to talk about things so that we get the right have projects in the greenhouse for tomorrow and you know my hope with that is that we get a lot of quality contributors that will help think about things differently and help us move forward in the convergence efforts that we've been working on yeah and I want to follow up with with that with an observation that today and I said this before blockchain technology is in its infancy we need we need more innovation we need more creativity in this space and and you know because of that your competition is good you know I I model a quote from the godfather you know keep your partners close but keep your competitors closer so so today we see well you know we bring in another competitive framework but but you know it it's good for us you know competition drives us better you know competition help us or at least you know it forces us to do better so so because of that in my mind and I on the other hand I also believe in the people right you know packages dropped in I heard 26 developers or so so there's a lot of people here and I believe that they will contribute in other common projects like OSA like transact like the project that we talked about and voted today so to me it is a number game a bigger community is likely to be a stronger community so you know regardless of the the technical in the innovation that they have today even though I feel like you know not a whole lot of that coming into and on framework that we have evaluated but the people behind that would really enrich our community and because of that you know I I am favor of having more competitors rather than that all right thanks for that Ben Mark's got his virtual hand up yeah so I guess I think it's great that we're having this discussion and I guess a question for Brian and Dan since Dan's our representative on the board is how much of this is really a technical steering committee decision and how much of this goes back and it's a board decision as it impacts the direction of hyperledger itself well I think our precedence up to this point is that we that we accept a variety of overlapping projects with an ever-raising bar on on what on what differentiation means for those it would be nice if the board could have weighed in on the the long-term picture that they would like to see as far as expansion versus convergence that's certainly something that I think I would still appreciate hearing from the board but I think we'll need to resolve this immediate question before the board next meets on the 16th and probably would not be able to give us feedback I'm guessing for yet another meeting after that and I won't speak for the board but I mean Mark you've been on those calls as well as you're a representative of the general members to it and you know I think I think they they want to be supportive of all the convergence efforts and want to figure out how and we're trying to work to prepare for them options for the next budget cycle and how to or if we want to you know specifically resource certain convergence efforts and what that might mean you know how do we just help the community move further along on that but I I do think they expect us to figure out this kind of meta road map kind of story in the technical communities I think they they believe there's strength in that obviously they're concerned about whether we get overloaded from a resource and staffing and marketing point of view as well but you know a pretty and just for the sake of everyone else a pretty regular part of the board meetings is a pipeline a sense you know a report to the board of you know here's the projects coming down the pipe that we know of you know sometimes we don't know of them but you know every board meeting we have a conversation about kind of what that pipeline looks like I and you know there hasn't been any pressure to say no on the basis of lack of resources I but yeah again I don't I won't I don't want to speak for the board on that front but I have not heard anything negative about the principle of trying to attempt to both expansion and convergence simultaneously okay yeah thanks I just wasn't sure how much sports business I could discuss on the call so I this is on I have to say I totally agree with Nate on the point that you cannot force those things I mean this is open source people will do what they are interested in and you know the TSE for sure has been very supportive of collaboration across all the projects from the beginning right and I don't think that has changed and you know we have now seen a few projects and I think everybody welcomes that but it's not like we can sit there and say hey you need to collaborate with this guy and conversion and so and so what I do find an interesting question is you know we keep coming and VPIN keeps bringing up the role of the working groups and then Mika said before you know the working groups have no teeth and it seems to me that you know there's actually a link to what might you know the role that EA might play in some way there is you know if we were to define some standard modules that could be used by different frameworks for instance should we have some kind of specification that says this is the standard API for this or the standard protocol whatever the case might be and you know who is in charge of doing this unless we had a charter where people say hey this is where we're going to define these things and if you care you should participate I think the working group will still suffer from lack of you know recognition and support and I think we discussed some of that last week or no as well and you know it would seem you know maybe we don't call it a working group but we discussed how while everybody has their own language programming language and there's no clear APIs for a lot of things and it's sort of when you pull something out of Project X to make it a separate project that can be reused I haven't necessarily seen and maybe I've just missed it but you don't really you know you define what the API is so if it's back into your project you don't really work with the other projects up front to come and say okay you know what's the best API to get reuse here and I had asked them you know well could the architecture working group be used for something like that and the answer was that's not really what they do but I think you know if we want to do a lot of reuse and convergence it would be great to have some type of team to go off and you know maybe try to figure out common APIs and things like that and how to use things and people migrate to that over time. Okay I have to say I mean I mean this very you know I spend a lot of my time working on standards and the way those things happen is not by force right it's people get together and say hey we all have that same problem can we all you know come up with common solution that we can all then support and remove a pain point for everybody and so to me again this is this notion you have to make it possible but you cannot force it in this case we would have to have some kind of shorter for working group to say hey this working group is going to define how to do this or how to interface right this kind of component what what's expected of the component what kind of behavior and and so on and then you know if there is enough people who feel like yeah this is valuable then we would have a support and people would engage and create this and then support them in their framework and then there would be a win for everybody but we don't really have that mechanism today and I don't think the kind of working groups we have today have this kind of support. Okay and with that we're down to the last five minutes here for me what I've been thinking is that Bezu or Pantheon would be successful with or without hyper ledger I think it's got enough backing behind it so the question for me is really would hyper ledger be more successful with with Bezu with another stack and I think what I what I hear that's persuasive to me in this discussion is that we're more likely to have the kinds of collaborative discussions with that community if Bezu is a part of the hyper ledger greenhouse or open range land as Nate is alluding to there but I think either way uh we owe that project a vote and so I move that we take up a vote now on Bezu. Would anybody like to second that? I second that. Okay um Arno. Yes. Fawao. Yes. Ben. Yes. Chris. Yes. Dan. Can I pause longer for more drama than than Chris provided? Yes. Hart. Yes. Kelly. Yes. Mark. Yes. Mick. Yes. Nate. Yes. Silas. Yep. It passes unanimously. Fantastic um so that went quickly enough we have maybe a couple minutes uh Mick wanted to give a quick update and then I would like one or two minutes at the end for something. Yeah I'll make sure that this is really quick um so I know I've been so there've been a number of discussions about okay not sure who that was um there've been a number of discussions about kind of futures of working groups um some have been on the mailing lists we've been trying to capture all of the notes um on the working group task force page um we've got at least a start uh a couple of the proposals just wanted to invite in particular um kind of the working group leads to go and I take a look at that um and make sure we get some feedback on it uh so um I think at a minimum the convergence that we're having right now is that the working groups have to be much more finely grained in their scope um focus much more on specific tasks or problems rather than general areas um and then the question becomes can we take the other role of working groups which has been to foster discussion and either leave that as the role of the working group or move it over to um to more structure so that's essentially where the discussion is going at this point um please weigh in on the ideas that we have out there okay thanks and I moved on so quickly I don't think I gave a uh congratulations to the Bezu team so congrats for that uh and uh so as we close up this meeting this is the last meeting of this technical steering committee uh as the vote concludes next week a newly enacted collected group will take over here maybe we'll have some of the same faces maybe some different ones but I would like to uh at least personally thank everybody who has served on this technical steering committee uh I think over the the year or years that we've been working together on this we've found good ways to collaborate uh especially where some of us have started in maybe more adversarial competitive positions we've arrived at more collaborative competitive positions and I think that's to the betterment of the whole community so uh thanks to each of you for the extra time in your day that uh this committee is consumed for you and thank you Dan for being such a capable chair thanks everyone's out first all right and with that we will draw this meeting to a close thanks everyone thanks