 with the HackFest planning. All right. I can give a quick, quick update there. I'm really happy to see the response on that. We are just about at capacity for the HackFest. If you have not registered, please do so as soon as possible. We're closing registration today. I've just dropped the link for registration in there. Lastly, here is the draft agenda. Quite a few topics have been dropped in there. Anything else you want to see happen or potentially present, please get that slotted in on the first day of the HackFest. We will get that all mapped out. And then the other thing, we're still looking at March tentatively to do a HackFest in tandem with the Hackathon that's happening in Shanghai, as well as May in New York. If you have space for either of those timeframes or cities, please get in touch with me as soon as possible. And then the next item, just a quick update. I know Rai has been working with LFIT. It looks like we should have Rocket Chat up to kick the tires by the time of the HackFest next week. Okay. Any questions for Todd? And we have the link to the agenda and again to the registration. So if you haven't registered and you're putting in coming, please do so. And then just one note on the agenda. I, you know, we tend to sort of have these things be more of an unconference than anything else. And we'll discuss whatever topics seem to be pertinent and relevant and whoever wants to have some time that's typically granted it. But I'd like to make sure that one of the things that we try to accomplish in San Francisco next week is some actual, you know, hacking, if you will, you know. I mean, and so this can be, you know, whether you decide to sort of take a trip and, you know, experiment with one of the other ledgers. If, you know, one of the other platforms, if you're, you know, working on fabric, maybe you can take a spin on a Roja or Sawtooth or what have you just to get a sense of what that is. And then, you know, if we, you know, if we can think about, you know, potential areas of collaboration and cross-pollination, you know, I mean, I'd like to get us to the point where maybe we're starting to think about doing much more than just talking, but actually doing and, or at least mapping out, you know, what the work items are and so forth. So just keep that in mind as we're starting to think about the agenda. Yeah, I think that's a great sentiment, Chris, and I'll kind of put myself on the spot that if I leave the hack fest without having gotten a chance to dabble in some fabric code, then I will not have satisfied my objectives in showing up. Yeah, yeah, I think I feel the same way. Thanks, Dan. All right. So I guess with that, the working group charters are up next, and I think the only one we have, is that right, is the updated identity draft, is that right? Yeah, correct. All right, Vip and you're up, and if somebody could post the link in the chat, that would be helpful. Yeah, unfortunately, I'm inside the firewall, but I can now look at the charter using another private device. So if anybody has the link, please post it. I see somebody has posted it, right? Yeah, Todd posted it. Yeah. Anyway, so we had quite a healthy discussion yesterday. The main point was, this is a charter, not the actual document. So I had expanded on the identity definition, and done some of that work there, but it started devolving into a discussion of maybe a 100,000 year old problem, which is what is the self, and all kinds of stuff like that. So I had to cut it off. Instead, we decided to just have a very bare bones definition in the first paragraph, and then the second paragraph of the introduction is the purpose of the identity working group is to discuss, research, and document ways to capture, store, and transmit, and use identities. And then the scope is limited to the life cycle events and use of identity needed to securely participate in the various Hyperledger project DLT implementations. The group talking about DLT, Thomas Ackerman has suggested that it should be expanded in the first paragraph, and that will be done right now. And then use DLT throughout. I don't know what the group feels about it. I did use the word blockchain once, but most of the, once or twice, but most of the other uses are DLT. That is one area which could use some clarification. The scope, right, and then the work products. Mostly it is going to be a document with a more comprehensive definition of identity. And then it will also include a description of an interface for a standalone identity component. So to go back to the scope, it'll focus only on the functional, rather than the design or implementation. Details of identity component. I call it the identity component because that is a central direction which the architecture working group and more and more people are on this TSC itself are driving towards. The next part of the work product is a suggestion which opens with the words, this could include a document which opens with the words, this could include, you know, and then the list. Really speaking, the more detail you have on the charter, the, you know, it attracts, you know, more and more debate which could be more appropriate in the actual work product document. Then it also talks about advice and learn from the architects and designers of identity solutions being constructed under the Hyperledge umbrella. In addition, the group will consult or advise the implementers of identity solutions who wish to join the Hyperledge project. This was brought up by Brian as a possible, you know, activity of the identity working group to talk to the people who are interested in putting forth solutions. The next part is the collaborators. Dan had a comment there that, is there any formal requirement that the people in this group should sit in, you know, any of the groups mentioned below? There is no such thing, it is completely informal but we will basically take the best practices or the debates that are under, you know, in many of these organizations, actually there are methodologies and actual verifiable use cases for claims use cases, for example, or the ID 2020 or the, you know, language like SAML 2.0, we will take that as input into our thoughts to produce this document. And the process, of course, is open and whenever possible, all the decisions should be made by the consensus of the attending parties and when the decision is significant, it will be transmitted more broadly to get wider consensus. Sorry about that. Meeting minutes, the transparency portion, which is similar to what the architecture working group said. Amendments and disbanding, all of these are very similar to what is there in the other working group documents and my thanks to Jonathan Levy and to Hart for helping me converge on this particular version of the document. So like I said, the only other change that will be made is the suggestion by Thomas Ackerman, the first paragraph saying that, you know, expanding distributed ledger technologies to include and then shortening in test DLT. The other, you know, the only other question is the use of the word blockchain versus DLT. Arno's comments from last week, I believe have been answered by removing most of the definition of identity that was here before. You know, we don't go into the details of self sovereignty and, you know, all those issues that we will tackle in the actual work group document. So this is what I have for your consideration and waiting for your comments. Thanks, Fippen. Just a couple of thoughts. I mean, I think generally this is fine. The thing that I'm struggling a little bit with is the work products aspect of it. And I'd like to understand, you know, and again, I'd like to have others weigh in as well, but I'd like to understand what we think we're going to do with that. In other words, are we, you know, are we putting together a document and then saying here's this thing and you can implement it if you like? Are we going to be building something? Again, this is an open source projects or a set of, you know, open source projects. Are we going to be building something? And, you know, in the sort of, in the words, you know, the infamous words that we have with ITF and with Apache of loose consensus and running code. Are we going to implement something that can potentially be integrated that demonstrates its utility and value overall? I'm curious to hear what others think. You know, if we have this sort of abstraction as a document, I think it would be, you know, from my perspective, I'd like to understand, well, what are we going to do with that, right? Is this something that the other projects need or want? Is it something that, you know, conflicts with what they're doing? And I'd like to get a better sense of how we think this fits in overall. Yeah, I'm all ears. You know, in keeping with what has been done in the architecture or any other working group, it is always about some kind of a functional description rather than an implementation. It doesn't prevent us from going ahead and doing a reference implementation, but that is a separate topic, and it is not for, I don't think it is for a working group like this, because even to get agreement around a document, we are having such problems, you think implementation is going to be easy? It's not, implementation has to be naturally focused work by a small group who agree. So, and plus, it doesn't seem to be the ethos of any other working group to have implementation. It's always been, you know, it seems to be more or less limited to a functional description, because otherwise, you know, it might, I mean, I don't know what others think. I mean, I'm eager to hear your views. So, just one of the, as you point out that we have taken a very prescriptive view of the working groups, and I think one of the, you know, you're right if we start from scratch and try to build an identity system, it's likely to be, you know, a multi-headed hydra that comes out of it, and I think the alternative is to go back and start with something that exists, and identify a path to evolve what exists into something that's sufficiently general. That would allow you to do something that's more focused on constructive, rather than something that's prescriptive this way. And this is a common issue across all the working groups, I think, right? Yeah. So you're saying that take one of the existing implementations and extract, let's say, the functional requirements from that and then see, I mean, sorry, maybe my mind was wondering, what is the core of your point? I mean... I'm just saying that our current approach to the working groups has been very prescriptive. That is, we go off and we design, you know, sort of the ideal, a description of the ideal system. And as Chris points out, that tends to be very paper-driven as opposed to implementation-driven. An alternative approach would be to say, hey, let's take a candidate system and let's adopt that as our core project and describe a very practical set of steps to evolve that into a general facility. Yeah, I like that. I mean, it turns things from a prescriptive into a very constructive decision or discreet operation. I'm not suggesting that we do that for this particular working group, but I am suggesting that as we think about how we can set up working groups going forward, we might wanna consider whether we intend them to be prescriptive or discreetive or constructive. Considering that no other working group is, you know, is contemplating an implementation, why... That's not really quite true, Vipin. I mean, we have... I mean, it may be particular to the fabric that it's, you know, we have the fabric SDK group that produces specification that is then being implemented in three or four different languages. All right, so, not exactly the same, still, you know... I mean, but there is a quite a distance from an abstract concept like identity and an SDK, which is by very definition, SDK implies some kind of a... Right, but I mean, when you're... Right, I understand. I guess what I'm trying to do, though, here, is just sort of help to sort of help focus the group on... So, you know, working on things that can have a concrete... Yeah, I mean, I agree with you, Chris. You know, in fact, that was one of my... One of my beefs with all of the working groups that I was a member of. Yeah. We were talking about, you know, like, what is the self and, you know, you know, it sounded like the open issues all over again. I mean, but... And the questions have not been answered. Obviously, you know, we can talk for weeks about the self, but it doesn't bring us closer to an implementation of an identity component. So, I'm all for it. If that is the way the direction the group has to go, then we need solid participation from some people who can actually deliver on these things, not just meet twice a week and talk about this stuff. So, one of the things that I think has helped with, you know, just with the white paper in particular is to come back and say, you know, we have a work product, and that working group is finished when that work product is done. Would it be appropriate to, you know, given the set of deliverables that you have here, would it be appropriate to say, would it, for us to charter you to deliver as your first deliverable, with, say, I'm just gonna pull a number out of the year, a six-month time frame, to come up with an identity kind of requirements usage API document. And then, at that point, transition the identity working group into a constructive group, which goes about that second group would become something with a charter of evolve an existing system to match the description that we put together or something to that effect. And again, I'm just- Or we can, what if we can charter? I like the charter, right? In the sense that it's consistent with what other working groups are doing. I just think you have an opportunity because you have a constrained, well-defined problem here. Well, I think that's the point. But it's not as well-defined as identity. Sorry, I have a great story. I'll tell you at the hack fast about a conversation about identity in an IT. Yeah, I mean, look, I mean, Thomas Arjano, for example, is posting up a whole bunch of API things, API definitions that could be part of the document. I mean, which I think is a very great step because so far we've been in the identity working group, we have been just talking about stuff in a very general way. And the first step towards implementation is indeed talking about an API. So I agree with you, make that, we put that in the charter, we leave the charter as it is, then once the product is delivered, then we talk about changing the charter because there's scope to change the charter and which would involve resources. I don't know who are gonna be the, people who are gonna implement the identity solution for the Hyperledge umbrella, but... Well, sir, I mean, that's dipping. That's kind of why I liked what Nick was sort of suggesting is let's take a look at something that one of the projects has and what would it take to make that more generally useful and still deliver and implement the capabilities that the identity working group believes are necessary in order to leverage an identity component in a DLT type of context. And I think if we could take a look at that, then I think that you potentially have a natural sort of catcher's mitt for the actual implementation aspects of finance. And you also have people that have a stake in how that's being used and so forth that will also help to sort of grounded in a little bit of reality. Again, I don't think we necessarily wanna go off and create something that's going to be ultimately useful, but that utility has an ability to sort of help focus people on what's really important. But again, if we can start thinking about doing something like that, then if we talked about at the last hack fest, we talked about, so Korda and Richard's not on obviously, but I mean, we talked about the fact that Korda did not yet have a, whatever you wanna call it, an identity membership services component. You basically, your identity was based on some certificate and you just recorded the public keys in a bunch of configuration files and you went off to the races. And so what would it be, could we potentially have the fabric CA component serve as the identity service for something like Korda in addition to fabric? And the answer was, well, we could, you know. Obviously, you know. Yeah, I mean, to your point, Chris. There's a certain amount of massaging to make it more generally useful, but you know, I think that to me has more constructive and concrete value to the community. I mean, to your point, right? The December meetings that I led in the identity working group, I invited Ben to do exactly this, which is to present the CA, I mean the fabric CA to the group and then use that as a basis for an interface conversation, which would then feed back into the CA part. I mean, which is what you're talking about here. But at that point he did not have a, you know, he did not have the, first of all, he did not have the time. Second, it was, you know, CA was still fluid. So all of these configurations is what led us down this path and in this particular charter, try to follow what was in the other documents. I wasn't opposed to having an implementation. I thought that this would be the first step to create a interface that goes, you know, starts off with something like the Fabric CA or, you know, the Sawtooth Lakes membership services. And then try to find the commonalities and then try to say, okay, now what else could we have in this? What about interactions with existing identity systems? What about, you know, those kind of things? And then push the edges a little bit and then try to get an interface and then as Thomas is again suggesting, you know, we could start building something, but I didn't want to introduce that into this particular charter. I mean, if you want me to make that change, fine. I'll go ahead and do it. It's very well within my, you know, my aims as well, because I'm coming from a practical place all the time. I mean, I don't want to write an abstract charter that, you know, people won't even read and then, you know, create an interface document that nobody needs to follow. You know, in the end, implementation walks. Everything else is, you know, useless. Yeah, so, Vipin, I actually like how you structured the scope of it. Like you pointed out, the other working groups haven't been generating, let's say, binary artifacts. So I think what might be more consistent is if a project is kicked off at the conclusion of a synthetic specification coming out of this work group that might be more consistent with what we've done before. And maybe to kind of incorporate some of the feedback I'm hearing here, it makes a minor amendments to this work group charter saying that the inputs to the API specification that you already have called out there, that the inputs to that are the identity services that are already designed or implemented for the existing hyperledger projects and that the intent is to look for some subset or superset of that functionality to call out for a standalone identity component. And that should be, that feels to me like a constrained enough goal and also a good precursor so that, you know, you never want to sit down and just start trying to write something without a detailed set of requirements or some kind of specification to guide that work. Yeah, so does this mean that we defer the vote on this for this week, make these changes and come back with it next week? Is that what it means? Yeah, I think that would be a good thing. And then maybe even next week we can have some concrete discussion at the hack fast on this particular topic. But yeah, I mean, again, like I said in my comments, I think that generally this is fine, but I'd like to see if we can't just sort of get it to be, and again, it's not just this group, I want to make that clear. I think all of them should sort of be, as we've done with the white paper working group, make it much more practically, deliver practical value and again, this is also part of, here we are just about to enter into the second year and I'm looking to see what can we do to start getting the various projects to be a little bit more collaborative. And therefore, if we're working on a working group that's coming up with an architecture and identity interface, let's think about, okay, so we're doing that because we actually want to have a common interface for identity and that's going to be shared across the projects. And then that means we should have this sort of close tie and collaboration between those who have the insights and so forth with those that are potentially implementing these things in the various projects that we have in incubation. So that's really where I'm trying to do with this. Well, I also, I think, yeah, go ahead, Ram. Ram here, I just wanted to kind of say that's a wonderful direction to go. I mean, the ultimate game of, for instance, what we're doing in the architecture work group is to kind of evolve the implementations to kind of towards the ideal architecture that we're developing so that it's modular components that can be reused across projects. I very much like the direction that, you know, we are kind of converging on how do we, and so I think it serves two purposes. Of course, you know, it is trying to evolve the group in the direction of this. And then also, so far, I think the amount of cross-project community development has been somewhat limited, it's been kind of siloed. So the more we use these kind of forums to put together common approaches across and collaborative efforts across the projects, I think, would be wonderful. So I like the direction, we just have to figure out how to get a resource, and you know, rather than wait for the end of the thing, I think probably it would be a good topic to explore in the face-to-face to see how we can practically start moving from just documenting the ideal kind of competence to how do we work on common competence, which ones we choose and how we move forward. Yep, I think identity is a great one to start with. I thought we had a project proposal come up for the fabric identity component, and one of the things that we discussed was, you know, can that be generalized? And I think, you know, we just need to figure out how to go about getting that started. So I think that would be a great thing to explore. Yep, I love it. Somebody else is coming, and I think... Jonathan, Liva's comments are very opposite. So is the conversation that they are having between Jonathan and Mick on the chat. So all that will be taken into account when I... I mean, the charter will not, you know, talk about the chain of trust and so on, but it'll basically lay out what we just discussed that the interface will be a jumping-off point towards constructing some kind of an implementation. That's the change I'll make, unless... And I'll put it up, so please read it and comment not minutes before the meeting, you know, which kind of makes it useless, right? I'm guilty of that, but I was at a hotel, really. You would be crappy on the outside, so I was... No, I'm not talking about you. I'm not talking about anyone in particular, but I'm saying, you know, we are all guilty of this because we say, oh, the TSE meeting is at 10 o'clock, so let me, you know, let me go and make some comments. So because if a document is tough, implementation is tougher, especially if it is a loose confederation of interested parties, you know. I mean, Chris, you know that, you know, if you have all your guys working on Fabric CA, they'll work on it because that's their full-time job. So to create an identity implementation from an identity working group is going to be a pretty challenging thing. Gentlemen, this has led a time on, everyone. Yeah, I mean, from an architectural perspective, there is the concept of starting from what's called a foundational framework. Now, a framework, as the word suggests, is constructs designed by the architecture-related that binds something together in terms of standards, expectations, requirements, call requirements, or prime requirements, so that you can take that and build from it. So the concept is going from what's called a foundational architecture to eventually end up as a solution framework which can be implemented. There's something, that's the way we headed because when we talk about a solution framework, really that's the domain of APIs and anything that's constructed and to be implemented. So we are moving in the right direction, I'd like to say. However, from the charter perspective, it's a charter, and the charter could become a project charter in terms that we are going to do something. Once you've decided what that foundational framework is and undertake in ourselves to produce a solution whether it's an API for identity management. I like that. And I think we all agree that's a positive change in terms of putting something out there that's very concrete based on any foundational frameworks that we've identified and we can discuss in the charter which could eventually be implemented as a solution framework and API as a component of an overall solution. So that's a very good direction. However, coming back to the charter, I think we should maybe not change it too much, but it's different as you've said, putting some other key elements so we can ensure it's a charter, almost like a project charter which could lead to some form of implementation whether it's a standard API based on the standard framework for identity. So I like everything that's being said. I just don't want us to spin our wheels too much around the charter, but make it in such a way that it could lead from a foundational framework of what identity management should really be and as we work closely with one or two of the other project team, you see we're already talking project because all these other projects, charter, et cetera, they're actually there to implement something and work closely with them to identify what that solution framework will be for identity management. I wanted to say, but I think we're heading the right direction. Any other questions? Yeah, I think so. Okay. Thanks, Zipin. Thanks a lot and thanks everyone for the good discussion. Okay. So the other working groups still need to come forward with their draft charters. So hint, hint. Much nudge, wink, wink. You're reminded. Yeah, Chris, could I make a comment on the protocol working group? Sure. So I chatted with a number of members. We have not had a meeting, working group meeting since I think it's October last year and the reason because of the, you know, the changes or the rabbit fluctuation of the projects that we have and the intent of the working group there is to document a common set of protocols, very much wiring stuff, for example, like, you know, to put together a transaction. What does that mean? What's the structure looks like so that, you know, maybe we put together one data structure and agree that from Saltwood Lake you can send a transaction and the same structure may be used for fabric and may be used for Iroha and so on and so forth. But I think, you know, the consensus from the group is that at this point things are still changing quite rapidly that I don't think we at the point that we can get together and document that and come to a, come to a conclusion on that. So we want to take a break there until perhaps having more project graduate and then revisit this work, this effort. Okay. That seems reasonable to me. Again, we don't have to force things that, you know, I don't want to have a working group that doesn't really think it needs to exist yet. So I think that's fine. Okay. Thanks, Ben. So, Hart, are you there? Yes, he's on. Are you on mute? Hey, Chris. Can you hear me? There you go. Yes, we can hear you now. So I think it's time to have a vote on the White Paper Working Groups outline. And so hopefully people have had a chance to do their reviews and are ready to take a position. But maybe if we could get a link in the chat, I think that would be helpful. And I don't know, Hart, do you want to just sort of remind people where we are? Do we have quorum to vote today? Yeah, we do. Well, we had, Todd. I think we're still a quorum, right? Yes, we are. Oh, perfect. Yeah, so just to refresh her, we wrote up what we're calling a skeleton of the White Paper that includes sort of, it's essentially an outline of what we want to cover so that when we do begin the White Paper, we don't have to redo a lot of work and we can kind of coalesce on what we think the White Paper should be. The document has been out for a while and I hope everyone has had time to look at it. I think the only thing that is still controversial is our discussion very recently about standards. But if anyone else has any other comments or anyone else in the working group has any other comments, please feel free to say anything. Hey, this is fine. Just to head off too much discussion, if we do end up in a couple of points like standards that could take a while to resolve, we kind of look at this in order if this was in the scope document, probably not, that the context for this White Paper is more or less immediate and that the expectation is that we would evolve the content like other ones, maybe create new drafts. So if, for example, our position was no standards today, that doesn't mean no standards come second half of the year or next year or what have you. Yeah, Dan, that was kind of my position on this. Obviously, if we do have something to say about standards, we should include it, but as far as I could tell, there was no consensus and anything we wrote was likely to be very controversial, so I figured we would just leave it out until we could get consensus on it. Hey, this is Brian, I'm not sure if you can hear me. I just dropped a note to the TSC working group mailing us proposing some language around standards, very short, simply says, standards may be defined elsewhere, they can be brought in, as long as they don't create any IP encumblance, and ad hoc interfaces may emerge out of our work at Hyperledger, in which case developers are free to promote that to the relevant standards body, so long as, with or without support from the TSC. Basically, trying to put an arm's length between us and standards bodies, but saying there is a relationship, it's potential, just don't confuse us as being a standards body. I don't know if that goes too far or not, but I just thought for some basic language there that might be helpful. And if I could say, let me tell you again, that we live in an age where everything is living, all our documents and living documents, they wouldn't remain on the shelf once we've written the charter or even the white paper, it's going to change, as someone just said, in a few months, more things are being discovered, standards are better defined, these standards come out, so they have to all be living documents. That's really the key to success in the age we live in. So yeah, with regards to the white paper game, I had to look at if it's a good outline, if we can improve it on this meeting, fine. So yeah, we can move on here. Apologies. Brian, I think that looks great. If other people are okay with something like that going in the document, in some shape or form, then I'm completely okay with that. Are other people generally okay with that? Yes. So I think what we should probably do just to make it quick is just to say, does anybody disagree with the current outline, speak now if we're able to hold the peace? All right, Todd, I think we have a rather hard, rather I think we have an answer. So I think the outline is good to go. And thanks for your and all the members of the White Paper working group separate on that. Great, we'll start writing. Thank you very much, everyone. Okay, great. So next up, I just wanted to sort of tee up a discussion for the next few minutes. We only have about 10 minutes left. But on openness and transparency of the various projects, this week there was a little bit of a, I'll just sort of characterize it as a little bit of a flare-up where on the fabric project, there had been sort of an ad hoc meeting of some of the IBM team members in Raleigh. And this was, again, it was an unplanned kind of a thing. And then somebody took notes and posted them onto Slack. And then there was apparently a sense that somebody was saying, oh, well, that should have been, and it was posted to the mailing list as well. And then there was some discussion about, oh, well, we should have been invited to call and so forth. I agree, by the way. But I think just more generally, when you're working in open source, there's a tendency, especially when you start from a project that starts with one company or one entity, there tends to be sort of a bit of inertia that the team that was working together on building something continues to do that and to operate in that particular mode. And when they're co-located, it makes it even more challenging because it's just so simple to just sort of gather in the open space or whatever and get a whiteboard in front of you and start mapping out and discussing things. And forgetting about the fact that, oh, but we also have these other people that are working very closely with them, contributing a lot of really good stuff, but they're not in the room here, right? And I think that, and Brian has sort of made this point and I'm hoping that Brian can weigh in and help with some of this discussion. But I think it's really important that we start thinking more and more, and again, this is also, again, cross-projects, I think is also going to be a good thing, not just within, but certainly within any given project, that we try and do a better job, sort of as our New Year's Resolution, so to speak, of let's make sure that the conversations are happening in a forum where everybody can contribute and participate, where nobody is being unnecessarily or even inadvertently excluded. And that can mean, and I know you had some experience with this and others maybe can chime in as well, but when you work in open source, sometimes you just sort of have to force yourself to have the discussion in email or on Slack, as opposed to the person who's literally sitting right next to you, just so that if somebody is sitting 3,000 or 6,000 miles away, that they can be involved as well. So I'll just sort of put that out there and invite others to sort of weigh in on that. But I think the more that we can all collectively do to think about, you know, as we're engaging in, you know, whether it's thinking about new capabilities or wanting to go through and do a refactor of, you know, making sure that we're doing all we can to sort of be fully inclusive of everybody in the community. Crystal, I could follow up real quickly with that. I get that a lot of modern software development culture is around the stand-up, whether it's the daily stand-up or whether it's the really tight-knit collaboration that happens when developers are pair programming or sitting next to each other in some way. And that is one reason why I'm an advocate for having our hack-fests and, you know, in these weekly kind of conference calls at the TSE level. I don't want to lecture. What I want to come across is, you know, kind of a manny on this topic. What I'd like to try to do is find ways for us to discover the value of having some of these conversations in a forum, you know, at the very least like Slack, but hopefully in a forum like email, specifically because some of these are technical, some of them are difficult conversations to have, and email gives us a forum that may be better for a lot of people, whether it's because of the language barrier, whether it's because of the time barrier, or simply because in an email you can explore some of these topics in more depth. And that's really the best way for us to turn what is right now, at least in fabric in the heads of a small number of people, into a much broader co-development, you know, constituency. So maybe that's something we talk more about at the hack-fest, and there's not a lot of time for here. Almost ironically, maybe we should talk more about this over email. Well, I don't think that's a good priority. I think there's some real value in that. I just want to leave it with, you know, I know my email in that thread came across perhaps is very chiding and moralistic, and I apologize for that if that came across poorly, not qualifying it if it came across poorly. I'm sorry for that tone. And so let's talk about it further at the hack-fest and over email. No, I agree. And I do want to sort of, again, I don't want to come across as sounding chiding either, because, I mean, I think the intention was very good. We need to share this, right? You know, we can't just be having this private conversation and it goes nowhere. You know, it's a tree falling in the woods kind of effect. And so that was a good thing. It would just be better if we could have actually had that discussion and all of that in more of a real time or even an asynchronous kind of a mode. Yes, it doesn't move quite as quickly, but yet, again, we have to be cognizant of the fact that we are scattered all around the globe, and we need to make sure that we're engaging everyone in the community or at least giving them that opportunity to be fully engaged. So that's really all I wanted to say about that. And, you know, speaking of mailing lists, then we have Morali and Richard and hopefully others involved in a thread on the GSL. You know, we've had, since the paper was published and first brought to the TSC, I think, back in late November, early December, time frame, you know, there's been, I think, you know, a little bit of, well, what are we going to do with this thing? And I think that, again, we should, you know, indeed be engaging in the dialogue on exactly, you know, where do we go with this next, right? Is this something that we can start collaborating on? Is this something that we implement with or in one of these or multiples of the various frameworks we're working on? Or is it something that can be built with one of those experimentally, and do we want to pull people together to actually do that? I'd love to see that conversation expanded to see where we might go with this next. There's not really much more to do with this, because I think Richard certainly is not on, and I think Morali is away as well. So that's probably not going to go further. So we're running out of time. I don't know, Brian, was there something that you wanted to follow up on the security badge discussion? I know we had that three weeks ago. I think we can meet some future agendas. I think we're fine. We just know what we need to do here. Right, and we just need to hire someone. Which, you know, we know there are jobs posted. You know, if you're on social media and you can help amplify the hyperledger projects post on the availability of these positions, please do share with your, you know, within your social circles. And then finally, Todd, another advertisement for your internship program. Yeah. So we are ready to get the internship program launched. So the first step of that, we are calling for anyone that is interested in mentoring an intern. So I'm going to drop the link into the chat window now. But so if you have any suggestions on projects they would work on, or different things like that, please fill out the form in about two weeks or so, depending on how many mentors have signed up. We will publicly kick off the internship program and start taking applications for students for a summer internship program. Hyperledger project will fund all of the interns for this. We will fund up to six of them. And we will also take care of all the backend, HR, logistics, finance, et cetera. So you don't have to worry about that. If you have any questions, shoot me an email or find me on Slack. And yeah, if you're interested in being a mentor, please fill out that form as soon as possible. Okay. And with that, I think we're at end of job. Thanks, everyone. And hopefully we'll see most of you next week in the Presidio. Yes. Look forward to it. Cheers. Bye, guys. Bye, guys. Sorry, everyone. Thanks, everyone. Bye. Okay, guys. Bye-bye.