 All right, antitrust policy notice, just reminding everyone weekly on that. And for the agenda, a couple things today. So first and foremost, just wanna let everyone know Dan Middleton has been elected as the TSC chair for the 2018-2019 cycle. So congrats to Dan and also a huge thank you to Chris Ferris for his leadership, all the hard work, just bringing the project from inception up to this point and seeing the umbrella grow from no projects up to 10 projects. So that's been really exciting. But with that, Dan, if you want to say, couple quick welcome words and then we can move into the agenda from there. Yeah, thanks, Todd. I guess in addition to the notice that we normally kick off with, I also just wanted to kick off these meetings by pointing out that all are welcome here. We're interested in having the most enthusiastic and constructive participants who are interested in advancing blockchain. So that is the main criteria for joining us here in this meeting and in others. And then also wanted to give a special thanks to Chris. Unfortunately, he's not on to hear this, but I think in my experiences as an engineer and other places in life, if you've got a well-defined problem, usually the solution to that's a little bit easier than being able to define the problem in the first place. And that's certainly the case for having launched such a large organization as Hyperletcher where we had essentially no definition at the outset. And as Todd just mentioned that we're up to 10 projects at this point in number of labs and working groups. So I think that's quite an accomplishment. And I know it was an extra burden for Chris to have handled along with his other roles that he contributes here. And then my last thought along those lines is now that we do have enough structure that we do start to have what look like, if not well-defined problems, problems that we can hopefully get some additional definition around. It would be good to start addressing those. We've got a rather full agenda today, but I'd like to send out a note probably right after this call with some thoughts on what some of those areas would be. And I would like to get everybody's robust discussion going in the direction of whether those priorities are the most important ones, if there's other ones that we need to be considering and some ways that we'd go about addressing those. And I think without further comments along that lines, then I'll hand this back over to Todd to drive through the rest of this rather full agenda for today. Sounds good, Dan. Thank you. Thank you for all that. Looking forward to working with you. All right. So moving into the agenda kind of standard set of stuff. The first thing, the next hack fest is just over a month out. We have around 90 registered for that already. So that's fantastic numbers from my view. I suspect that'll continue to grow from there. I know Tracy and Rye have been socializing a draft agenda for that and calling for any potential topics so we can get this laid out in advance. That seemed to work well in Amsterdam when we had a more structured agenda as folks walked in and we can hit the ground running. So please look for that in the agenda or the minutes that go out and start putting your thoughts in there and we'll work with everyone to get that shaped up. The next section, thank you, everyone that indicated interest in the doodle poll for Q1 of next year for APAC hack fest. Based on that, what it looked like was March 4th was the best option for everyone that week. So just wanted to do a quick call for any objections for us to hone in on a specific location and specific date pattern within the week of March 4th. Are there any concerns with that? So I indicated I could not attend and I probably won't be able to but that's not an objection obviously because I don't feel like, you know, the train should stop just because of me but I have to say I was looking at the doodle poll and it seems like a lot of people have not responded in especially the TSC members. Yeah, so we've sent this out multiple reminders or sent it out. No, it's not your fault. No, I'm looking at Dan Meek and other people like this. to have skipped answering. So I don't know what it means. So what it means from my perspective is I don't really have plans set that far out. So it's somewhat unclear to me whether I would be able to attend. So I don't want to necessarily commit that yeah, that date's good for me. And at the same time, I wouldn't object to any of those dates. I'm in the same boat that, you know, it's quite far out and I can't make the season on whether it's January or what, any month. So instead of having my boat on one month or the other that's through the other, I accept any both that people come up with. All right, then that means you can proceed, Todd. I don't care. It might be good in future polls to have undecided or something so that we can indicate that we've seen it because I'm sort of in the same boat. I don't know that I can get funding to travel that far out, especially that far away. And that's the same situation that I'm in. Okay, we can wait on this a little bit if that's helpful for people. One of the things we've been trying to do is, you know, from the direction of the TSC was do more advanced notice than we had been doing because the short amount was not sufficient. So it looks like we're still working for the sweet spot in terms of that. I think that's actually fine to get the date out early and then that helps fix an otherwise moving variable in everybody's calendars. And at this point, what we're really trying to do is just make sure that we're not conflicting with some major conference or something that we're gonna lose a bunch of people at, right? I mean, if we're doing it this far out. Yep. Okay, that all sounds good then. And then the last event reminder was just around Hyperlogical Global Forum. Again, flagship event. It's the first year we're doing this event for the entire ecosystem. So technical community members, users, the full scope of that. So really excited to see everyone in Switzerland December 12th to 15th. And the agenda was announced for that a couple weeks ago. So please check that out and get registered there. Yeah, on that point, I just want to pass the, you know, there's a bug in the agenda. The agenda for Friday and Saturday is a copy. So I doubt it's exactly the same. Great question. I had the same question myself. And so that is by design. The reason for that, I think that's the workshops. And so at each hour there's, I think three, four or five parallel workshops. And the idea of having it replicated both days is so that someone is able to go through multiple workshops because they can't select all five, four or five at each hour. So it does sound like we need some sort of notice in there because that's not the first question I've received. It's very confusing, but okay, that makes sense. Thank you. Yeah, we'll have them update some verbiage in there. I suspect we'll get that question again. Cool, any other event questions before we move on to project updates? All right, then I handed it over to the cello team. Okay, for where I'm happy to be here to share the current state of the cello project. Firstly, I must say the state of the cello is good. The community focus on the 0.9.0 relixing. Since this release will contaminate new features, so people are very active in the rocky tracks recently. They go there and they go there to give feedback and report back. And the most urgent issue is the 0.9.0 release on this weekend. In the past several months, we focused on developing the Kubernetes engine. With this feature, cello user can add a Kubernetes class to cello's resource pool and deploy traffic class on it. All these operations could be manipulated through a friendly UI. Meanwhile, our contributors also work on supporting the February 1.2 and reflactoring the user dashboard. The user dashboard can allow user to easily deploy and remote-chain code to the fabric across the whole state by the cello. So basically, there are two dashboard in cello. One is for the manager to maintain the fabric trust. And through the user dashboard, the normal user could apply fabric trust and deploy or remote-chain code to the fabric trust. We also have an internship program. The intern is responsible to integrate the February CA into the fabric trust. The purpose are replacing the couple of gen by a hybrid February CA client and server to generate all the crypto material and enable user to explain the February network flexibly. So in the current state, the main work of the Kubernetes agent and the user dashboard are finished. But the February CA need more time to investigate. The 0.9.0 release will contain four agents. There are Docker, Kubernetes, Resphere, and Ansible. However, the only Docker and Kubernetes agent could be operate through the manager dashboard. But we will support the others in the future. So any question here? Then I will go on. So in the past quarter, we added a new maintainer and now the maintainer of the cello are coming to floor. There are Bao Hua from the Oracle, Haitao and Nitong from the IBM. And we look from the everywhere. The maintainer also partially attempt the make up to improve the influence of the cello among the hybrid community. So the current plans of the cello is the most, the most important is ensuring the release of the 0.9.0. And we are planning to support the other hybrid platforms like Brow and Indy. Also, we will introduce the Hemtrat tools into the general project to use the, to take the advantage of the, take the advantage and the flexibility of the Hemtrat and Kubernetes community. And last but not least, we got 45 patch sex review and merge and five new code contributor get involved in this project since June. So that's the current state of the cello project. Do we have any question about the cello project? Yeah. So I don't see any significant issues listed, but I just wanted to give you another chance to talk about anything that our challenges, maybe not from within the internal operation of your project, but things that maybe the TSC should be aware of. Sorry, could you say again, not here really clearly? Yeah, let me try again. I'm just wondering if there's any issues that you would like to highlight that you feel that the TSC can assist with. Can fix it? Can help you with. Can help me with it? Yeah. I look at the question is actually whether the project needs some help from the TSC side, maybe like help promote the cello project or improve the collaboration with other projects, I think. Okay, so actually we are developing the covenants agent, which is already complex and all we feel contributed get involved in this new feature. So maybe we need more power or resource to improve this new feature because I think covenants is a very important platform in the current environment. So this is the main. Okay, thanks. Looking for maybe some helping recruit people with Kubernetes skills to go make contributions. Yeah. Okay, great. And then I'm curious for your geographic diversity of maintainers and contributors are most contributors in Asia time zones or are things predominantly in US or European time zones? In Asia time zone, we got three maintainers in Asia and basically in Beijing time zone and one maintainer in the US time zone. Okay, great. And then that might be different than at least some of the other projects that have maybe a higher concentration of US time zones. And I wonder if there's any challenges that you observe with cross project meetings or working group interactions that might relate to having different time zones or other communication factors due to the geographical differences. Yeah, but the communication bit are most happening in the rock chat. But we also have some communicative tools like VChat. So basically, we basically don't have types of each other to, so yeah, this is a quite good question. And I'm not exactly know how to. Well, maybe let me add one comment. We're committing or chelow it's Friday evening in Beijing time while it's the morning of the US side. So maybe it's for the US developers they need to get up sometime earlier like at seven or eight. So that may be a kind of challenge. Okay, thanks. Well, I think as we're starting to develop maybe another community working group which is down lower on our agenda, if any of those communication or other factors occur to you, it would be good to introduce those into that discussion. Yeah, definitely. Thanks Dan for the question. I had a question as far as since you're more or less based on fabric, how closely do you follow the fabric release? So fabric just released 1.2, I believe. So when will cello be compatible with version 1.2? Yeah, yeah. The cello is compatible with the 1.2 right now, but you know, cello have many agents like Docker and Kubernetes, and as far as I know, the Docker's agent is compatible with the 1.2 right now, but the Kubernetes agent is only compatible with the 1.0.5. However, we have already texted the Kubernetes agent with the 1.1.0 fabric, but in the 0.9.0 release of the cello, the Kubernetes agent will only support the 1.0.5. Yeah, so this is the current situation. Thank you. So what are the main technical challenges around bringing the Kubernetes agent up to 1.2? The biggest challenge is that the network products are really hard to figure out. And as far as, you know, a user of the fabric can define their organization, right? They can define their organization and demand their life, or what you want on example.com. However, this demand won't work in the Kubernetes, within the Kubernetes P, the peer to discover other peer have many restricts in the domain name. So we don't want to bring this restrict to the fabric user. So this is the biggest challenge we make so far. And we, so we have some pranks like introduced and ingress to resolve those demand, demand where we have not do, we haven't investigated too deep so far. So I have a different question that has more to do with the project, life cycle status of this project. I mean, not that I, you know, want to push the project per se, but have you guys looked at what, you know, it would take, I mean, so your project is in incubation, I would expect any hyperledger project to have the ambition to eventually graduate to active status. And so I wonder if you guys have thought about it. Oh, could you please, how to enter this question? Yeah, that's a very good question. Actually, our plan is to release a 1.0 at the end of the year and after that, we will try to become active. So that seems a bit backward. I mean, we've allowed for some project to go to 1.0 without being in active status, but we all kind of said, well, it's not desirable and shouldn't be the norm. So I would expect you to seek graduating, graduating to active status first. Actually, we, it's not decided to become active after 1.0 for us. We consider to be active for our code quality. So currently there are still several major features in plan and we need more adoption of the project to Facebook. So, but we will definitely consider your suggestion. Maybe tomorrow actually is our weekly meeting. I will propose this subject and we'll discuss with other maintainers. Okay, and again, I mean, I don't, you know, I don't mean to push you especially specifically, but I think it's a good exercise for all the projects to kind of do this kind of assessment every now and then, you know, looking at the execut area and saying, you know, the execut area and saying, okay, where do we stand now compared to those? Because it can kind of give you some guidance as to maybe some area that need a bit more improvement that you should focus on. Yeah, I agree with that. Thanks, Lusadez. Thank you. I also see comments on Rocket Chat about supporting other blockchains. I did take a look at the cello proposal to refresh myself on the intended scope and I know that originally there was an interest in supporting the breadth of hyperledger frameworks. I think that would be something that I would be looking for in a move to, at least a move to a 1.0, if not a move to active status, that the project was on track to reach the scope that it had been chartered with. Look at the health comments. I think that's our, that's definitely the project plan to support the multiple platforms. Yeah, actually, we already consider support and implemented the spot of Explorer and we have also contacted with the Composer team and the India team. And certainly in weekly meetings, several weeks before, we discussed the home chart support with David, which we believe may be more efficient to use home chart to support like the SO2.0 and the AD. A question there, do you have any plans or strategy for reaching out to some of those communities and trying to recruit contributors? I know that if you don't have someone kind of involved in the project, it can be difficult to track changes or figure out how the architecture fits. Yeah, this is Chris. I know that Google and Red Hat are both working on home charts, certainly for Fabric. I don't know what others that may be doing. But I think, as Nathan said, there are definitely people out there that are doing this. And I think we do need to figure out how do we get them all together and working together. Okay. We have developed the home chart to support the Fabric clouds. But it does have some restrictions. The most important is it required a user to provision and MFS server first. And maybe we could, MFS server basically to store the certificates of the Fabric peers. So maybe we should replace, take out the MFS server and use the Kubernetes secrets instead. So with this feature user, the Hamchat user will not be required. We will not require user to prepare the MFS server. This will make this to more flexibility. Well, look, I know that you have been also getting into the Kubernetes community. And I guess it might be helpful if we can attract more developers from the Kubernetes community or people with experience to help the trailer project, then it may be more efficient. Yeah. Let's think about it. Okay. I imagine that for several of the frameworks where you have people who are working on deploying those users end up in the community of that particular framework. And I wonder if there's a way that you can attract those developers or users into cello. So you're not necessarily trying to, you're not gonna need to rely on maintainers of, say, borough. But if you've got somebody who's using borough and deploying it or they're using Kubernetes for that, that's a user that would be good to attract over to cello. And then that might help grow some development for those platforms within cello. Yeah. Okay. I think that we might be winding up discussion on this that I do wanna leave enough time to reach the other people who have prepared an agenda items for today. Is there anything additional importance that anybody wants to discuss before we move on? All right. Thank you very much for preparing the updates and doing that in a timely way and for facilitating some good discussion here. Thank you. Hey, Dan, can you guys hear me now? Yes. Oh, great, finally. I can fill in some of the blanks in like 30 seconds. Over the last month, I've been going through our community finding all of the Helm charts and Kubernetes YAML files and reaching out to the authors. And I've been asking them to start going to the cello meetings. So what they were touching on earlier is that we've been talking about Kubernetes and Helm charts and cello for the last month. My proposal to the cello team was to become the tool for using Helm to deploy to at least to handle the underlying deployments of the blockchains. And then all of the higher level functions of cello could lay on top of that. And so we wouldn't have to manage so many agents underneath. Maybe we want to, but it seems to me like Kubernetes and Helm is sort of the standard that all the cloud platforms are adopting and that's the direction of momentum. So there is work here. If you have any more questions, email me. I'll fill you in. It's still informal right now, but we're trying to get it all organized. Thanks, Dave. All right. So for next week, Hyperledger Explorer update, please. And then now, next up is architecture work group. Ram, are you on? Yes, I am. Good morning, good evening folks. So getting started, is there a link that you can post? Yeah, let me drop that into a rocket chat one moment. So overall the working group is quite active. We are making steady progress on three work items. Participation has been quite steady about eight to 12 participants. And there's actually given that we have two tracks and three work items. There's a little bit of diversity in the fact that some of, we are attracting new people who are interested, for instance, specifically in the privacy and confidentiality track. And so, we do see new participants show up in the different topics of interest. In terms of issues, there's no specific issues at this time. We definitely like the TSE support, especially in getting more active participation from the different projects. At times, some of the companies and projects have not had regular participation. So if we could kind of encourage that, that'll be fantastic. Activity in the past quarter, we've had regular meetings. We have, as I mentioned, two tracks. The regular track, the main track has been meeting every other Wednesday, alternating with identity work group. And on the alternate weeks, we meet on Friday for the privacy and confidentiality track. Besides that, we've had working sessions. The last one, for instance, was a face-to-face meeting that Oracle hosted in the Bay Area last week. Thanks, Oracle, Todd, for setting that up. And we've been making steady progress on three work items. The first one, which is pretty close to getting done, I believe, and that's the system identities work item. We started engaging the technical writer, so hopefully we are at the home stretch there. The second track is the privacy and confidentiality track that Mick has been driving. And we're making good progress with both the model and the paper, and I think we made good progress in the face-to-face meeting there, so that's going well. And we are getting started with the track on interoperability stance, when taking the lead and kind of putting that together. And that's still in the early stages, but I think we have a good framework and starting progress there. Any questions on that? So, work product, I think we're working on the system identity paper and the privacy and confidentiality paper. And once we make more progress on the interoperability, then we'll get started on that with the next work product. We have, as I mentioned, I think we've had good diverse participation in terms of a good mix of different project representation and companies. We continue to not have as much of an active participation from Iroha, as an example. So, we've kind of reached out to them, but I guess they're a small group and they've been quite busy with what they've been doing. So, whatever help we can get from the TSC to kind of encourage more broader participation would be great. Questions, comments? Thanks, Ron. I think that one thing that I'd find interesting across the working groups is, whether it's in these updates or maybe in separately scheduled agenda items to get a better sense of sort of the meaty things that are going on in the discussions. And that could be, here's a contentious technical topic that's being discussed or here's an interesting finding that we didn't expect, but some way to make sure that we've got a good connection between the technical path that the work group is finding for us and keeping the TSC connected with that. So, with that in mind, is there anything that jumps out? And I think maybe I'll suggest out of the system identities paper, you mentioned that that's reaching close to a mature level. Is there some synopsis of the findings of that paper that you could share with us now? Yeah, I guess I would invite all of you guys to actually let me post a link to the paper. And I'd invite you guys to take a look at it and provide feedback. And actually that would be a good way to kind of get more folks plugged into the paper itself and the work item. And the approach that we've taken here is to, again, stay with the functional requirements and this is similar to what we've done for the other main functions that we've looked at, such as the consensus and smart contract and so forth, to try to attempt to stick to the functional requirements for system identities. And so that's been the approach we've taken. So if you look to the paper, it's talking about one of the functional requirements for establishing the root of trust, enrollment, how do you enroll system identities in terms of binding the keys and the identities themselves and how we prefer to have that registered in the ledger itself. Authentication and authorization, revocation and change management, privacy and interoperability between identifiers. So I would say none of this has been quite controversial and there's been very good consensus on the functional description. What the next item that we want to have is to have the different projects actually fill out the way. And so this is the typical split that we've taken. We talk about what in the first section of the paper and how each of the projects are going to be implemented is going to come from each of the projects themselves. And that's the section that we need to kind of complete before we kind of publish the paper. So that's giving you an example of this. We should probably set up some time to kind of go over this. The other alternative is to perhaps schedule a review in one of our architecture work group meetings and invite the TSC members to participate. Or if it makes sense, we can actually set up a full review during one of the TSC meetings in the future if you think it's managed for time. Thanks. Yeah, I think it probably deferred to you or to maybe some more discussion here to see what amount of time is required. But what do you see as the goal of this paper? Is this to reflect the current state of this part of the stack in hyperledger projects? Or is this to add requirements that the projects may or may not be satisfying? I think it is. It stacks out with minimum describing the functional requirements that we all agree on is already there and should be there in the roadmap of the different projects. So it's not intended just as a description of what's there in the different projects. But if there is consensus that that's the architectural framework that we want to create, we want to provide that as input to the projects who don't need that functional requirement yet. That's the direction that we are suggesting. Of course, we are not mandating that they do that yet. But that's the approach we're taking. Does that answer your question? Yes. I'm shocked both. Right. I think I'll probably take a little time to figure out in what way is best to use the content that this paper will arrive at. So that might be another topic for when we discuss this as a group again and your thoughts on how this would be applied, whether it's towards the informative side for consumers outside of our communities or whether it's more towards the normative or requirements side for the projects. I don't know, you just said it's kind of bold. Yeah, I mean, there's no direction there. Sorry, the first two papers in the series attempt to do a little bit of both. They were clearly informative trying to capture sort of broad concepts and use those to actually describe the platform. So in each of those, there was sort of a high-level description of consensus and a high-level description of the smart contracts pieces of it and then bringing that down to the existing hyperledger platforms. And at the same time, there was also some sort of speculative or normative expectations both in the language and in the architectural descriptions that we had for those. So I would not expect anything different from this one. Thanks. And of course, the Holy Grail, if you will, has been to kind of come up with the functional descriptions of the different functions that can be the common framework that hopefully the projects are working towards. And as any ideal Holy Grail kind of effort tends to be, it's more aspirational and we are not, of course, so far trying to enforce any of that. And it's more of, here's what we think the functional requirements should be for each of these modules. And here are the information elements that would make sense to have in the interfaces if we break it out into these modules for these functions. So that's kind of the aspirational normative side, if you will. Okay, thanks. Any other thoughts, questions? All right. Thanks, Ram. So moving forward for the workgroup updates, just quick reminder, next week is the identity workgroup update. And onward from there, Tracy O'Ri, Hyperledger Community Health Workgroup. I know that was teed up last week. There was some discussion there. It's there updates to provide or kind of questions back to the TSC that resulted from there. So yeah, we definitely went through the working group charter and made some updates, which we attempted to capture in the change log based on the discussion that we had last week, really rewriting the introduction to focus on how we're changing this to provide extra bandwidth to projects and working groups that want to work on improving participation and engagement, so we're trying to find the role of metrics that it's, it's a tool that we can use to help improve participation, but you know, it's, it's not the goal of this group to fully produce metrics. It's just one tool that we'll use. And that we wouldn't publish those, unless the project or working group wanted to, to find, you know, have that data at their disposal. And that was just, you know, a question I guess for the TSC is, do we want this to truly be a working group or, you know, should this be some other sort of structure that maybe we don't have very well defined today. That would basically allow us to gather people together who are interested to work with these different projects and working groups that express an interest. But that's, that's really, I guess, up to the TSC as far as direction that we went ahead with this particular working group charter. So Tracy, this is Chris. So Dave posted something in the chat and apologies. I'm remote and only have my phone. So I don't have access directly to the proposal itself. But, and so basically his suggestion was, well, yeah, let's, you know, let's develop whatever these, you know, metrics and so forth are, but then just make that a function of what you report when you come up with your quarterly work group or whatever report so that, you know, we have some consistency in that regard across all the different ones. I know, I mean, I, I try to get, you know, specific actual numbers and percentages and so forth. And, you know, it'd be, it'd be useful, I think, to have, to have something like that as part of the, the quarter of the reporting rather than have a separate thing to come in and try and explain stuff. Because I think the project teams are more likely to be able to understand and make sense of the numbers that they are seeing. And also I think having that as a function of what the reporting makes it more likely that they'll maybe invest in trying to, you know, once they're measuring things, then they can try and improve them. Peter Drucker. Yeah. So, I mean, and I think that was some of what we were originally thinking, but I think we got quite a lot of pushback last week and, and not wanting to take over the, the quarterly project reports or anything like that. I mean, obviously we can do whatever it is that, that the TSE wants, right? It's just a question of what, what will be helpful to make sure that we're able to grow the community and have a healthy, diverse community. I have a comment. I saw this interesting article by metallic, among others, about radical liberalism, which has to do with the free rider problem in communities. And of course they are proposing a, you know, a solution that is based on quadratic wording and things like that, but it doesn't have to be just that. I think it is an important sort of avenue of thinking about these communities. The open source community has been laboring under this problem for quite a while. The tragedy of the commons, you know, the people contributing, but the free riders taking a lot of those contributions and how do you stimulate participation from the people who are benefiting from the activities of others. So I would urge you to read that, maybe not directly putting that into action in the community group, but definitely thought-provoking and I've been involved in this free and open source community for quite a while. And this problem is quite acute. As you can hear from even people like Ram or from the cello people, you know, there are, there is always problems expanding the number of contributors to beyond a certain number or a certain committed few. It is, it would be interesting how we can look at some of those problems through the community working group. Well, as I mentioned last week, you know, you're right. You're absolutely right. It is a challenge. It's always a challenge to really grow a community beyond, you know, sort of its initial core team. And that applies to companies big and small, you know, that start something, you know, just give you an example or two examples, I should say. So take a look at Kubernetes, for instance, and TensorFlow. Both are Google projects. One, they made a conscious decision to put it out as open source and actively cultivate and grow a community around it. And, you know, they have Sarah Novotny and others that are, you know, their job is to basically go out and, you know, and promote the community and help new people on board and encourage individuals as well as companies to come and contribute. And they've been very successful and they have like over a thousand people contributing to Kubernetes in various ways. So that takes a concerted effort of somebody who's paid to do that for a living, not a volunteer. Multiple, it's not just Sarah, there are others. I'm just highlighting her as I know. That's what it took. TensorFlow, on the other hand, they've decided that they want to retain almost exclusive control. They have cultivated to a certain degree a lot of sort of academic contributions, but they're onesy-toosies, right? They're not, there's no non-Google maintainers or committers, whatever you want to call them to speak of. Those are still all, so it's very still, very tightly controlled by Google. And unless they decide to put somebody like Sarah and make a conscious decision that they wanted to grow, they won't. And that's, so, you know, the working group is fine, but in the end of the day, you really need to have the energy around something like a working group that's coming up with different ideas, actually putting them into execution, right? That's the real key. The thing that I'm saying is that basically coming up with ideas, anybody can do that. But then actually going out and actively trying to cultivate people to come on board, start contributing, hand-holding them through their first commits and so forth. That takes energy and effort. And you can't just sort of, here's a couple of ideas. So really what I'm saying is if we're serious about that, and I think that's the thing we shouldn't be, then I think we need to think about how do we actually take some of those ideas that we may come up with in a working group and actually make them real. Yeah, I think that's an important consideration. How do we marry up the duocracy with whatever observations would be generated by this? And I think this is probably a big enough discussion that we probably want to continue it again, maybe at the forefront of the agenda next week. I missed the update on the documents. So I'll go back and read the document and maybe we can continue some of this through email as well. The other question I would have is what does the Linux Foundation have for guidance in this area? Did they have anything? I don't know if you've looked. So we've definitely been working together with the other community architects that are out there, community managers, whatever you want to call them. We also have chaos, which is a Linux Foundation project that is focused on specifically community health in the open source space, which we've done some looking at as far as kind of what they have and what we might be able to use if this working group does kick off. But in the working group charter, we do specifically call out the fact that we would work, we would work closely with the chaos community to make sure that we're learning from them. They're learning from us. Cool. Thanks. I'm really interested from the last remark, how many people spend 50% of their time on Hyperledger or other open source standards bodies or other stuff that is not directly their job? I do. I think that's one of those data collection points. Yeah, that wasn't a great modality to collect the answers. All right. Well, I think we are at the end of the hour. Maybe Silas, if you can remember that point to sort of kick off the discussion next week, that would be good. Sure. Hey, Silas. Bob here. I do, but I'm very exceptional. You're exceptional in many ways, Bob. Well, thank you. I think most people working for someone in a very traditional way are obviously constrained in what they can do. Okay. Well, thanks for everybody's time. And I guess, Todd, you can take us out here. All right. Thank you, everyone. Chat next week. Ciao. Ciao.