 So Chris, whenever you're ready to get things kicked off. Sure. Okay, so just a couple of items on the agenda for this morning. The first one is just a discussion on working groups and sort of, you know, just to keep track of them. There is some discussion and I'm still trying to catch up on my email and I have a long plane ride to hopefully I can do some of that. But I think it's, you know, I've asked a couple of times to have updates from the working group sent to the mailing list so that we can keep tabs on what's going on if we're not able to sort of join. And, you know, some of the workgroup chairs are, you know, graciously thank you very much. Doing so, thank you, Ron. I know I saw yours and I think I saw one from Dave. But I think that one of the things that, you know, we've observed is that with some of the working groups it's kind of difficult to tell if there's anything actually happening because it all happens either on the call or maybe in Slack and then rolls off the end of the world in a day or two. So I think, you know, Brian and I would like to see a little bit more, I would just call it transparency, not that I think anybody's trying to keep anything as much as when you have conversations in a very transient form like a phone call or like Slack, nobody else can really track that. And, you know, one of the things that I think we do want to do is give people an opportunity to participate in whatever way they can. And sometimes that's going to be asynchronous if they're in far-flung time zones and sometimes people need to be able to sort of read things. If, you know, English isn't their first language they need time to digest and so, you know, phone calls are not always the best way to do that. So, you know, if we can, you know, start to take a little bit of the discussion or, you know, a bulk of the discussion around some of what we're doing in the various work groups out onto mailing lists and so forth or discuss.hyperledger.org. I think that would help others in the community to sort of, you know, stay in. Is there somebody speaking? Oh, it was just some background noise. So that's that's really all I had for that. And, you know, I think that maybe rather than having work group updates as a regular part of the TSC call that we can just sort of do that in, you know, in email and use, you know, the work group update in the TSC occasionally if there's something special that the work group chair wants to bring to the TSC's attention. Does that make sense to people? Yeah, it does. Yeah, that makes sense. Chris. Yeah, I agree. Cool. Because it seems like there's not a lot happening out there or, you know, hard to get your arms around what is there and to try to put the whole picture together is very difficult. Yes, yeah, and I agree it's even hard for us that are, you know, you know, definitely trying to do that as their day job. I think there's, in fact, I know that there's stuff going on. I think that the problem is, is that it's hard to see it or it's hard to find it as the case might be. So, and part of that is because we've been in flux with the Wiki, I realized that, you know, some of the tools have been a challenge. And hopefully now that we have the Wiki live, we can, you know, sort of start leveraging that a little bit more effectively and putting things in some sort of order so that people can more easily find things. And I do think that, you know, as Brian said in his couple of recent threads that, you know, the more that we can use forums as opposed to Slack for some of the coherent, you know, sort of design discussions and not just for, you know, a little bit of back and forth sort of instant messaging around a particular topic. I think that that will also help people stay a little bit better in tune since we're not able to archive any of the Slack discussions. And Brian, did you want to add anything to that? Yeah, it's, you know, partly that, you know, I certainly don't want to create extra busy work for people in terms of extra reporting. And so one advantage of email is in the email conversations is you don't, you don't need to take, you know, verbal conversation and try to write it down. But I just want to make sure that, you know, we as a TSC take a look occasionally at, you know, the charter and the distribution of the working groups and kind of make sure that they're still working for everyone. One of that that sent up for me potentially is the identity working group. I know there's been activity there and it's been, you know, some interesting conversations and presentations. But it's unclear to me, you know, what their what their charter is as a group as it relates to, you know, the work at Hyperledger, right? So, and maybe that others are happy with that too, I don't know, I don't need to prejudge. But I just, some of it may be a lack of clarity around the mission of each, each working group and just, you know, we should, we should, on a regular basis, have a conversation about that as a leadership. Thanks, Brian. Any other thoughts? Okay. Is that nice? Was there some background feedback? Can people hear me? I can hear you. There was some feedback, some banging or something. Oh, okay. Anyway, so then the other agenda item is a proposal that came from, I think from Ben. But Keith Smith, I think is on. Is Keith on? Yes, I am. Keith. Would like to present. So why don't we turn the talking stick over to Keith and he can review the proposal. Okay. Let me know if you can see my, let me try to go full screen here. Can you see my screen? Okay. Yeah. Okay. So the proposal here is currently, I just said a high, let me speak at a high level first is current membership services at a high level was, you know, very closely bound to the fabric itself. And the desire here is to pull it out into a separate project. We, we'd like to be able to, and to have its own, own repo. This, they're still going to be crypto primitives that are, you know, that are part of Hyperledger fabric, but this is related to the membership services API itself. So the proposal here is to, there, there've been, there are currently two names on the, on the table. This is showing our proposal for the name being fabric CA. There's also the name fabric cop where cop is not an acronym. It's simply a, you know, means that it provides police like security to, to it, to the fabric. I'm personally okay with either name. I, I slightly prefer the name cop simply because we have already have code naming that and there were not have to be renaming, but I'm okay either way. So you see my self and Ben sponsors here, proposing myself and Ash Kumar be the maintainers. Let's see, I, so again, I've already given you an overview for the abstract part motivation. I should say the, the, the improvements, the reason, the changes that will be made in this is that the membership service, the only thing that is unique about it today is it's T-Cert generation, the E-Cert generation and some of the features that are lacking in it are really stand available in standard software in particular CFSSL and less encrypt, which is built on top of CFSSL. So we really like to, to use this open source technology not reinvent the wheel and, and then extend it as needed for, for T-Certs in particular. These things already support, you know, CRLs and different things. I mean, it doesn't mean that there's not some, you know, extensions that will be required, you know, for example, with regard to pushing CRLs into the fabric, but the main so that, you know, CRL list is actually on the ledger, but that part, so there, there will be a, from a connectivity standpoint or a dependency standpoint, there will be callouts from this to, to the fabric, but not vice versa. So the fabric will not, you know, ever need to call out to, to the fabric CA or fabric cop. I don't see anything else I want to say here. CFSSL already support, these are some of the things that it already supports. CRL, OCSP, which is a, you know, another way of doing revocations, certificate of expiration, supports multiple DBs today, in particular, sequel, my, sequel light, my sequel, and what's the other one? Going blank on the third one here, Postgres, yeah. And also supports PKCS 11. There's still some work for PKCS 11 for T-Certs. That's the extension part. From an efforts and resource perspective, you know, our squad that's already working on this, what's known as COP, what we've been referring to as COP, would, you know, would, would continue, would work on this, obviously. Let's see. Now two, we, this would be the fabric CA server client CLI would be separately deployed and tested. So it will provide its own set of test cases. Given the reference for the open source for CFSSL and listing crypto there. And we'll know what's successful when we are able to have support features that we wanted for quite a while, such as clustering for HA. You know, sort of this decentralization piece that we're also working on. And, and all of the other things that I pointed out up here, CRLs as BSP, Certificate Exploration, etc. PKCS 11. Any questions? Yeah. Oh, sorry. Sorry, because this is like, um, why is this a separate project? If I understood you correctly, you said that you're still calling back and you still have a dependency on fabric for it. Are you intending to break those dependencies so that it becomes a separate standalone unit? Well, yeah, absolutely. I mean, it's not a required dependency. For example, what I'm saying is that the only calls back into it are going to be for being able to push a CRL list into the fabric. But that's not a requirement. You can use this without having that, you know, it can provide everything else. Does that make sense? I was going to say I had exactly the same question that Mick did. And, you know, I've been traveling, so I haven't been able to sort of pay as close attention internally. But I mean, if we were, I mean, I think that having a, you know, the membership services or CA, whatever we want to call it, or a cop, you know, the function of being able to sort of manage enrollment in a network, whether it's fabric or anything else is potentially a good idea. I think that probably does affect the name somewhat if the intention is that we do something that could be shared across, you know, the broader landscape of various projects that are coming in. So I mean, a little bit of clarity, I think on is that the intention here? And if that's the intention, then I think we should maybe make that explicit in the sort of the charter for the project. If it is just, I need a separate repository to manage the membership from the fabric repository, that's, it's not really a new project, it's just I need a new repo. And so I'm just trying to understand where the thinking is with that. I think that if I could jump in there is that, you know, certainly we want to take one small step at a time. And the first small step is that recognizing that this component, especially what we planning for 1.0 is quite independent from the rest of the fabric as we're trying to change the fabric so that it can work with any kind of CA providers. So because of that, this piece of code, that so-called fabric membership services becomes quite independent. And so that's the first motivation to have it a separate repo. So once it's a separate repo, then we can talk about whether we can add additional capability so that it would be able to serve the rest of other projects within the community. And it seemed to be, you know, at the high level, it seemed to be there's nothing to prevent that from happening. But certainly the amount of testing and consolidation on API calls and things like that to build in that flexibility was not in plan for 1.0 timeframe at this point. So I get that's the flexibility that we have. We can move there if we want to. But certainly the timeframe that we call for is to be complete this by December, which is in line for our 1.0 plan to be released by March timeframe. So that's a constraint that we have to play around with. And Ben, that's the fabrics 1.0 plans. Again, it feels like this is like what you're describing is a fabric component. And by the way, I'm all in favor of having a separate enrollment service, identity service component usable and would be independent from the others. We have our policies set up in Saatu that we could take advantage of it as well. I just don't understand. And if the objective of the project were specifically create that independent service and that were made explicit, I'd be a lot more inclined to support this. So it's Richard here. I think I'm agreeing with what some of the others have said. Having a common certificate authority or something something common like this sounds like a good idea when we get to it. I mean, in quarter we have, we have, I think our requirements are slightly different, but we have some overlap. My, I guess my thought would be is maybe that maybe I'm repeating what people have said is, is this just means it needs to be broken into two pieces, having a fabric dash C, a fabric dash cop repo as part of the fabric project, it almost doesn't need any oversight from us at all, I guess. And that's just fine. And then at the point at which it either we've demonstrated the that sawtooth or row or cord driven once incubated, either either is using it or can be shown that it would use it or that there's agreement between more than two more than one project that it's the right path, then we then we make it a thing in its own right. And it's, it's an example of a, of a common hyperlegic component. But we, but we don't agree that now, because it sounds like we're not quite at that point. Yeah, I have similar feelings that at least from the description, it seems like it's intended to replace membership services, so replace a fabric component with a different fabric component. The way that we've managed this, this might be a good general discussion for how we want to take on projects generally. But within sawtooth, we would typically create an epic for something like this. And if there's some sort of interface dependencies or breaking interfaces, then we usually do some sort of construct in the code so that we can maintain a stable master, even though that some of the core components underneath are being swapped around. I think another consideration when we add a new project is, is the resourcing. And if I'm interpreting this correctly, it should be repurposing existing resources as opposed to adding additional resources for additional projects. That's correct. And this is Ram Jagadishan here. So in the architecture work group, we are currently talking about actually identity services, policy services, and the CA component fits in with the identity services. So I'm highly encouraged by the fact that we are thinking about this as a, as a separate module that can interoperate. But I'd agree with the rest of the group here in the sense that it probably makes sense to make it a separate project if from the get go we have the intention of making this something as an independent module that will work across several projects. So, you know, in the beginning, if the scope is to make this a fabric component, then I would agree that it could just be a repo. But it would be great if, you know, the intention is to make this an independent module. So if I can play back what I thought I heard from you, basically saying that, yeah, eventually this, this is, you know, something independent. And from a fabric perspective, you're looking to have the ability to be able to leverage a different CA, if that, you know, if, if, if somebody wanted to do that. So there's, this is a pluggable component to begin with. And of course, we're obviously, you know, from a fabric perspective, we're trying to get to a specific release time period. And so we're, we're working towards that objective. But if the scope of this project could be made a little bit more broad, it seems to me that, that still could fit into this. It's just a matter that what we're, what you're saying is that, certainly from an IBM perspective, that the resources that we're allocating are going to be allocated to providing the necessary functionality to enable us to do into, you know, to deliver fabric in the March timeframe. But it doesn't mean that others couldn't contribute and collaborate on that same component to try and get it to work in other contexts as well. And actually, if the, you know, if the APIs are coherent, it, it really, you know, should just be a matter of which function does it need, you know, which capabilities it need and do we agree on the APIs? So I think, I think it would be important if we were to take this step, if we could make that statement to try and get others, you know, to potentially reuse this component. Because, you know, if, you know, Cordo on its way over and Sawtooth could take advantage of having an independent module that we all collaborated on that managed enrollment in a permissioned network. I think that's a good thing. Yeah, I agree with that, Chris. In, in spirit, you know, we want to separate out to have that independent project that, that one day we, we can take it in that direction. But for, for, you know, the first iteration of this, you know, I would not like to have to unendate it with at least no requirements to generalize, you know, this so that we can focus on this in the next couple of months to have the core set of functions. At the end of, you know, we were using open source projects anyway underneath that. So certainly, you know, anything that isn't on top would be beneficial for other project as well in the spirit of trying to manage the members in the network. So I, I agree with your conclusion there that, you know, we, we want to go forward to support, in general, other project as well, not just fabric. As an, as an extension, this is Morali from DTCC. So can we take like two paths? I think fabric can go ahead and do the implementation, but maybe we can start a thread on defining the API. Either, you know, we can take it as part of the architecture workgroup, or it could be separate defining the API for a CA or membership service. Yeah, I agree with Morali here. I think this is a great topic for architecture discussion. So this is, I also have a question. Is the plan for fabric to discontinue supporting its basic membership service that's included in it? And then, you know, that becomes a must-have for people who want to actually run fabric. They also have to go build this and set it up. Or are you going to keep the membership service as a basic functionality that people get out of the box and then, if they want more sophisticated membership services, they can go install that one and replace it. Yeah, so from a core point of view, after we set up this repo for, for this component being proposed here, we'll remove the member services code from fabric. From the built, the existing built, the membership services is a separate EXE anyway. So it built two different EXE today. You know, so with that then, the built for the proposed project here currently called Fabric CA would generate a separate executable file in which the deployment would be similar to today by out of the box by default. So only anyone can deploy, you know, Fabric CA as a separate server to provide membership services without using their existing membership services. But otherwise, they could use their existing membership services as such as, you know, external CA because at the end of the day, all we need is a set of certificates for members to, to communicate within a network. The security functions such as access control and crypto primitives like be able to sign and verify messages are continued to be part of Fabric. So that remains the same. All right, thank you. So then I have another question. She's dead. So I know that for Fabric one zero your goal is to address the problem of single point of failure and single point of trust for the membership services. Does this open source, you know, that you're trying to leverage here? Is that going to help achieve any of these goals? Well, not, not really the single point of trust. That's sort of a layer on top of it that is orthogonal to any CA that you use. But for single point of trust, it does help us in that, you know, it's already supporting the, all of the databases that, so keeping state between the cluster members. So the clustering part it does help us with and as well as some of the other missing features around URLs and stuff that, that I mentioned earlier. All right, thank you. So, you know, perhaps we could talk about naming if, you know, so that it's not, you know, the first step is not too tied to Fabric. Maybe instead of Fabric CA, we could come up with a different name for it. So I like what I've heard about, you know, if it's necessary to put this into a separate repo, go that path. But, you know, that doesn't stop forward progress towards the Fabric one-oh goals. And then as the concepts are redefined or made to address some generality, then creating a separate proposal in the future as a separate project. I mean, well, just kind of moving forward with, with things within Fabric. Yeah, I mean, I guess, I mean, this is all a patch. You could always, at some point, if there's interest, you know, you can fork it and start moving it in so that you have, you know, one going in a direction that's more general purpose and one that's somewhat dependent or, you know, sort of specific to the Fabric. Okay, this is really just a reorganization then of some existing capability, although there is, I mean, it's, you know, it's taking a different implementation track. It's, at least, you know, as, you know, what it sounds like right now is that it's just another repository that's part of the Fabric project itself. That then, I guess, gets to the naming, so probably should follow the pattern of the, you know, project, you know, top level project and then dash, whatever. But that's, you know, so I guess, I guess the answer is it doesn't need to be approved by the TSC is, I think, what I'm hearing because it's just within the Fabric project and they can organize their repositories as they see fit. You know, just a sawtooth and a Roja and anything else can. That's a prerogative. So I would suggest we just sort of treat it that way, at least for now. And then maybe, you know, we can have the discussion wrong in the architectural working group and, and maybe there's interest in, you know, the general community to sort of take the, that thought and maybe even, you know, have a fork of the code that's working in a direction that's trying to be more general purpose. Absolutely. So we are actually currently in the middle of that discussion. So we want to start the API interface discussion to this module and during the design phase of this redesign. And that'll be a great first step. So I'd encourage the folks working on this to kind of join it in the architecture discussions. Okay. Okay. I think that takes care of that. And then I can just sort of ask if there's any other agenda items. If not, then I think we can adjourn and give people 25 minutes back. I don't have an agenda item but just a question here that since these, you know, these separate repos per projects coming up, how do we, in this proposal here, we kind of, you know, added another heading here to name maintainers for the subprojects. In general, how do we manage that? Because for example, in the SDK Node.js, I'd like to add more maintainers there, especially the developers who are working in and out on that repo. But since I'm not a maintainer on that, there's no way I would be able to do anything there. So what was the policy on that? So I think, again, I think the policy for a project is the maintainers can organize themselves as they see fit. The fabric SDK Node project was really, again, it's the same sort of thing. We've just moved the code out so that we can do a refactor independently and have something be, you know, independent just as with the Java and the Python. I actually didn't realize that the maintainers on fabric were not maintainers on the SDK. They should be. Or, you know, if we wanted to just organize it such that, and again, this is not a fabric specific, this is just generally I would suggest that the project maintainers decide how they want to organize themselves. And if they want to specialize in certain branches, or if they want to be covering all of the different components and repositories, we should try and figure out how to do that for ourselves. But I would see it as a function of the TSC to decide who's a maintainer. The policy is that a maintainer on a project can basically name somebody and the others, just a majority of the maintainers have to agree. Right, so project like this, say we're going to create this fabric CA, then the maintainer would be, who would decide that? I guess that's my question. The maintainer of the fabric. The maintainer of the fabric. Yeah. Okay. So as long as we have a little bit of time, I could just give a quick update on some of the things that we're working on with Sawtooth. Sure, Dan, go ahead. Okay, good. Yeah, well we often don't get very vocal about some of the projects that we have going on underneath Sawtooth. So I thought I would just socialize a little bit. I think Mick had already discussed in one or two of the working groups, the validator registry or the endpoint registry work that we've done to, it overlaps a little bit with the CA work, but it's specifically towards adding validator nodes and what are the permissioning policies to grant another system into the network. And then we've also started a significant redesign of how we're handling transaction families, both from client side submission of transactions as well as how those are handled under the hood. And so we've got a Python SDK sub-project, if you will, in-flight. And some of that redesign work is allowing us to carve out better process boundaries so we can actually operate separate processes within the validator that will then allow us to also support creating transaction families in other languages. So kind of on the heels of redesigning the Python SDK, we're also creating a Java SDK as the next follow-on for that. And I think once we get some patterns established there, there might be some opportunity to try to set up more separate projects to address some of the more, some of the languages that are also popular right now. And then one of the other things on the list right now is we've got, kind of like Chris had mentioned with an IBM, there's a separate interface which was already discussed a bit in the context of the Hyperledger Explorer project. We'll continue to work with that code to get that fully carved away. And there's probably some additional features that weren't discussed at the time of the Hyperledger Explorer project. But that code is going to, kind of simultaneously go out into the Sawtooth core will be available as a UI with Sawtooth. And then, of course, the main intent is getting that into the Hyperledger Explorer project as another example of how to have a generalized user interface interaction. Excellent, yeah. And I know that Gary's got Dave working on the Blockchain Inspector, it's had a couple of runs at getting merged. They could need a little bit more attention, but that's certainly also trying to get its way in as well. Great. Well, we've got a few other things going on, but those were some at the top of my mind that when we're starting to think about, you know, what's a separate project versus say an EPIC or something underneath one of the projects. We have to kind of get those out there and, you know, maybe discuss those a little bit more in detail once they've baked a bit more. All right. Thanks, Dan. Any other topics? If not, I'll let everyone have 20 minutes back, and thanks a lot. We'll talk to y'all next week. Thanks, Chris. Thanks. Thanks, everyone. Thank you.