 the IBM blockchain team. And he's the lead architect for the IBM Blockchain Platform. And he leads the user interface team that builds on the IBM Blockchain Protocol Console and won a prestigious Red Dot Design Award. And he's been a part of IBM for over 20 years now. And he's worked on many products as a UI architect. So at this point, I'm gonna go turn it over to Varad and let him go through his presentation. But I do wanna let everyone know that if you have any questions while we're moving through the presentation, feel free to post them in the chat on Zoom here and we'll address them. And then we'll also be posting relevant links as we move through the presentation so you can go in and engage with the community. And one thing that I always like to really promote is this is a great way to learn about projects, but we're always looking for additional contributors and maintainers. And if you're interested in really contributing to hyperledger fabric or the operations console, definitely feel free to follow up and engage with us and we'll be glad to get you engaged. So at this point, Varad, I'm gonna turn it over to you and let's go through your presentation. Perfect, cool. Thanks, John and David, I appreciate the intros and the efforts that you guys go through to set this up. So today, we're gonna talk about managing orders that don't have system channel. So, and then it'll have a brief intro and then followed by a demo. So let's get right to it. All right, so again, we're gonna talk about two different things today, right? I mean, two sets, right? So one is what is the benefit of the new fabric architecture? So fabric introduced, I believe in 2.4, the channel participation API and that removed the need for system channel. So we'll touch on the benefits of this new architecture and then we'll have a short demo after that to again show the new functionality that the console implemented to support what fabric did, right? And then we will open it up for Q and A and again, post questions like John said, right? Then as we go along. So the first thing is again, what is the channel participation API and what is the benefit, right? So if you look at the picture on the left side, right? With system channel, this is the legacy approach of managing orders. So we had the, again, fabric had the concept of system channel where it needed to know all the ordering service organizations and nodes that are part of the quote unquote sort of cluster, right? So in this picture, I'm showing a ordering cluster with five different nodes, right? That could belong to different organizations. And if you created a channel, right? Say app channel one with one, two, and three nodes, right? From again, different, the recording stopped it says, is that, should I? The live stream's going. We've got the recording on the live stream. Okay. So again, app channel one, so one, two, and three are the nodes on it. However, like when you create the channel and manage it, system channel knows about different channels that are being created and managed, right? So in this picture again, right? So let's say, I'm an organization that just needs to, as one, one, two, and three, however, if since say organization five is in the system channel, if organization five with node five is quoting the system channel, they know that that is app channel one in the system, right? So that's one of the gaps that Fabric tries to address with removing system channel. So on the right, you see that without system channel. Again, in this picture, that is of course, no system channel. And with the same set of five different nodes in the system, if I'm creating app channel one, nobody but the node organizations from nodes one, two, and three are the only ones that know what this particular channel, right? So that's one of the big benefits. It's a distributed, truly distributed architecture where there is no single kind of entity system channel in sort that knows and manages and needs that architecture, right? So that's the big benefit. So what other things, right? Again, no consortium, of course, the system channel had the concept of consortium which encompassed all the different organizations that are part of the consortium. So again, that's gone. So again, you need to think of the new architecture much like peers joining a channel, the orders are joining a channel. Like if you have that mindset, I think everything falls into play like when you, you know, the new architecture, right? It's not very complicated again, you know? So there is no consortium, nobody's managing system channel. And there is simple node creation. That's one of the things that fabric advertises as a big benefit, which I agree. So when you create a new node, right? New order, previously you need to go through this entire process, right? Where you need to create a node, get the, you know, the, you know, the TLSers, add that as, you know, into the system channel, right? You know, as the concentrers and all that, right? So, and then you need to start the new node with the new genesis which contains this node as a concenter. So it's that convoluted process that's gone. Now you just create a new node just like any other, like, you know, here you create an order with its own identity and then you can join a channel to that particular order, right? So again, that simplifies quite a bit. And then increased privacy, I briefly touched on it, right? So again, since there is no system channel, then there is nobody, not everybody in the quote-unquote consortium knows about all the channels that are being created. Again, that is, you know, that's one of the big benefits. Scalability is the other thing that, you know, the fabric talks about, right, as a benefit. Again, if you have a lot of different nodes that are in the system channel, when the order comes up, it needs to check all the other orders. So that if it sends, you know, heartbeat checks, you know, that are like going across the board, like, you know, multiple times. So that kind of slows things down. So, you know, the new architecture helps with, again, scalability, right? So actually let me quickly show the page where fabric talks about the benefit. So I added, you know, the link is in the presentation, but again, you know, you can see that fabric list, again, no system channel and then no consortium, simplified creation process. Again, you know, you can read through more of it, you know, from the fabric page, you know, there are some additional benefits that are being described, right? So, again, let me go back. And then there are new APIs, right? So the new, you know, approach, right, to the channel participation API has, you know, they added new three new APIs, right? Again, there is one that joins the channel to the orderer and now you can list all the channels on a particular orderer and then you can also remove a channel from the orderer. So all these APIs use TLS certificate on the orderer, right? So again, you need to remember that this is slightly, it is different than the general ordering service admin certificates, these are TLS certificates that come from the CA, right? Any, you know, TLS that comes from the CA. And again, just to reference, right, you know, the OAS and admin APIs are listed here in the fabric page, join list and remove all the three different operations and what console does, this is the main part we wanna cover, so fabric has these features. This has nothing to do with operations console. What operations console did is to support this architecture where there is no system channel and we leveraged these APIs. So the OAS and admin APIs are basically REST APIs, right? That are protected governed by again, these TLS certificates. So we will see how console is able to simplify this process without having to go to command line to do these operations. How can you do that from the console? That's the thing we are going to see and talk about. Any questions so far? Yeah, Rod, I think there's a couple of good questions here. So basically it looks like they're interested in, you know, how version two four is gonna be backwards compatible with version two two of fabric and so maybe you can talk a little bit about that type of backward compatibility. Okay, so that's a good question, right? So you can go to two four and still continue to operate with system channel, right? That's not like a required thing as part of two four. So again, you know, if you don't make any changes, everything will continue. You can start two dot four in the system channel as mode that are flags that you pass, you know, it's documented in, you know, in the fabric pages and IBM, you know, has operators, right? When you integrate operators, by the way, that's a plug for future talk. So IBM also open source operator, right? That is fabric operator if you look up that allow you to create nodes with again, two dot two, two dot four, it allows you to migrate from two dot two to two dot four with the right images, right? It runs on Kubernetes, you know, and all that, right? So IBM does support, you know, having a flow where you start with two dot two, you have system channel and it shows you the process to move to two dot four, you know, without system channel, right? So it is possible, but fabric itself is again backward compatible with system channel, right? And did I answer the question? I think so, I guess the corner question to that, I presume that let's just say maybe two that six or a later version of fabric then probably the system channel support will be dropped, right? I would think so at some point, like three dot two or something, I wouldn't expect them to drop support that drastically in a dot release. I think it's more like, you know, a big release would drop support, I would think, but there's no plan I don't think yet on when the system channel will be dropped. Got it, and I don't know if this is the appropriate time to go to the next question, but my uncle and I had a question around the migration of data. Migration of data? Yeah, so that's a good question, right? Because this does not change the data. Nothing changes from channel, nothing changes from the data. If you have an application channel, so the migration code and code is only removing system channel. So everything is managed independently by the orders. So zero things change in the channel. They continue to operate the same way. The peer join, nothing changed from the peer join. So none of that change, which is great, right? So it's only the fact that system channel got removed and now you have to join the channel to individual orders, the process change. Okay, so you can join the orders to the channels and then you can get rid of your blocks in the system channel if you want it. So there is no system channel, again, that's gone, right? So you don't rely on system channel to add a new consortium member. You know, you don't use that as for consensus to tell others, like, you know, this is clustered, that is what changed. Understood, thank you. Yeah, that's a good question, though, yep. And the other one, I'm gonna have Sonny come off and ask his question, but it looks like he's got a question about privacy. So Sonny, do you wanna just ask your question as well? Yeah, so originally blockchain was created for no third-party entities and allegedly it was considered private where no one could control it or get into it. But then now I'm hearing that it's on a public ledger and now everybody could see what you're doing. No, it's not entirely true. So it's not like everybody, right? So the way it works is again, right? Are you talking about legacy, like where people can see, you know, is that what you're talking about or the new approach? What is the concern, I guess, from public versus private? So I guess it's a system, where the blocks and everybody is able to see what blocks are being made in the community contributing and decoding. Does that make sense? Not entirely true, right? Because the blocks with the new are old, right? They go to, you know, again, you distribute it to all the peers that are members. Only the people in the channel that are authorized to see are the only ones that can query the blocks. Nobody else, right? Okay. If you have a channel and say the channel has three members, right, in organization one, two, and three, you define, like when you create a channel, you define these are the members of the channel and these are the right, they're admin's readers, right, you tell it. And only those operations are allowed for members from that, you know, role if you go, right? So if you say org one is only a reader, he's not even allowed to write, if organization two is using its certificates to query the blocks, they can only read, they can't do anything else, right? And if you don't have anything, nobody can query, right? Other than these three organizations that you define. Does it help? I mean, I don't think it's, unless I missed a point that you're trying to make. No, that makes sense. I appreciate that. Thank you for clarifying that for me. Yep. Anything else, guys, before we move? No, I think that covered pretty much the outstanding questions, but great job on addressing those and let's go back to your presentation. Okay. So the next one I wanna mention is the concept of Concentre, right? So Concentre Followers. So Patrick also introduced the, again, Concentre was already there, right? So it's basically you're saying these are the two nodes or not two, three or five, right? Generally is what we recommend for consensus. So these are the three nodes that are Concentres on the channel. And now there is a concept of Followers, right? So within the channel, you tell it, right? Organization one and two are the admins of the organizations that are contributing orders to this particular application channel, right? One and two. And as long as I have the certificates, right? I can use any of my orders to just follow. They are not Concentres, right? They are simply following meaning they're simply pulling blocks replicating so they are available. One of the reasons I think, you know, that this helps is, right? If you know previously, right? Let's say you have a channel with millions of blocks, right? So when you add a new node to the channel, they are like, you know, members of the channel, right? Or they are Concentre right away. And if it needs to replicate all the blocks, it takes a large amount of time during which, you know, that are members that are clients that keep trying and, you know, it can potentially fail. Like, you know, this is still coming up. They are not part of Concentre. What the new approach does is you simply, again, start as a follow. You simply say like, you know, if you look at the previous picture, like I showed on the right side, ordering so is one, two, or three are like Concentres, like that's how the application channel has the definition. And you simply voice an underscore F is joining the channel, but they are not Concentre. Again, what that does is once the synchronization is complete, meaning like, let's say you have 20 million blocks or whatever, right? You know, they pulled, they are up to date. Now you can simply say, hey, this node is now a Concentre. You can simply add it and it's like instantaneous almost, right? It's, you know, they become Concentres without having to wait, you know, and then clients are able to like just use them and all that, right? So that's the benefit of having a Concentre, you know, and follower architecture. You can read a little bit more on fabric itself, but from the console perspective, we do show allow people to be follow, allow nodes, I should say, to be followers. And we show like which nodes are followers, which are Concentres on the channel from the console to make it easier to manage it. That's basically the point I wanna make for the console side of things. So with that said, let's go to the demo. So I have set up locally, right? So I just have my local setup and I imported a bunch of nodes from, you know, IBB. So on the IBM blockchain platform, I created some nodes and I imported them, but you can create them using the open source fabric console, not console fabric operator that's available. Like again, we should have a future session on it, but however you create it, you can simply import them into the console. Again, I have three different CAs, right? You know, two organizations for orders. So that way we can see how the multi-node setup works. So again, just to reference these are the things we are going to see as part of the demo, right? We will see a migration scenario from, you know, with the system channel, how do you go into a, you know, two, four system without system channel that covers migration. And then how do you create a channel with the new approach and how do you join, remove, and how do you see the consent or follower of sorts, right? That's what we will see. So again, I imported two different, or created and imported two different orders. So order one, in this case, you can see is with system channel, you can see from the console what type of order you have. One thing you do need to do right after you import, I shouldn't have done that, which is you should create a certificate of type TLS certificate. So let me actually do this. So that way, you know, people don't get tripped up when they set this up. Let me remove that TLS certificate from the wallet that way you can see how it looks like without. So I'll start first, right? So now if you go to the nodes and then say, I go into order one, you can see, you cannot see this channel listed, right? So meaning it does not have the appropriate TLS certificate. So if I go to the order one CA and then say I want to just pick any, you know, any ID, I don't have to pick admin, right? In this case, I'm just gonna pick order, and roll identity, and then I type in the password. What I do need to do is to generate a certificate of type TLS certificate, and then it should generate the certificate, then I name it order one TLS. So now I have a certificate in the wallet, right? If you see it, order one TLS certificate, and if I go to the nodes, and then roll down into order one, you can see that it is able to list the system channel or any other channel on that node, right? So the bottom section, the ordering admins and all that, those are of course relevant only for the legacy approach. So just, you know, I'll add one just to show everything continues to work. Again, this goes back to the question of migration. So in this case, I have a two-four system that is operating with system channel, you know, and it has like application channels, you know, everything operates normally. The only thing you see in addition now is that we are listing the system channel and any other channels using the, you know, the new API that Fabric provides, right? So what you do for migration perspective is again, two-step process is what Fabric recommends. So the first step is you need to get the system channel into maintenance mode so that accidentally nobody's creating channels during this migration process. You know, if you have multiple nodes within the cluster, you know, you don't want like accidentally people becoming, it's just confusion. So they highly recommend that you flip the channel into maintenance mode system channel. So no new channel creation or update is happening during the space. So within console, we added a new option that sends the system channel into maintenance mode. You just click on the gear and then you say go into maintenance and then it shows the current state, which is, you know, it's not in maintenance mode. You flip it to this and then you see a message, you know, you will not be able to create or manage new channels. And I say update, that's important, right? So now the channel is in maintenance mode, right? So again, no new channels. All you do is just click on this delete button and then you paste to the channel name for confirmation. In this case, system channel is this particular one to system chain ID, enjoy, that's it, right? Now you are able to manage the node without system channel. And in this particular case, I should have, you know, if I had any channels ahead of time, like application channels, you will see them in this list. But since I didn't have any channels, it's a brand new system, you don't see any channels, but that's basically the migration. So put it in maintenance, delete the system channel. Any questions so far? I don't, you know, it's fairly straightforward, that step. Yeah, there are some questions coming through. So my neck, you wanna ask your question directly or would you like me to go ahead and ask it? I think it's a great question. He was asking about the migration demo, being on the same version as, or would it be different? So I don't know, do you have access to the chat there? You can then just take a look at his question. Okay, let me see. Migration is on the same version or the version would also be different. So if I'm understanding the question, are the nodes need to be in the same version if you have multiple ordering nodes? The answer is as long as it's a 2.4 system, it shouldn't work. The new channel participation API can only work in 2.4 system. So if you have a cluster, you know, the expectation is all of the nodes under the cluster need to move to 2.4. That's the first requirement. The second one is you need to enable the channel participation API. Those are two different steps that Fabric recommends. And in this particular case where I am removing system channel, I set up a 2.4 system with system channel on IVP. So let me just quickly show that screen. Just so you guys know, like with an IVP, how the options show up. So this is IVP on cloud. And if I create a new ordering service, I can create a new one. And I get an option to say, do I want to create with or without system channel? So it's an option. So again, did I answer the question? You need to have the same version or at 2.4 and higher and channel participation API enabled for the migration to work. When you create a new app channel in 2.4, which ones have to join first? The orderer or the orders or the peers already doesn't matter? Generally the orders are the ones that need to join and then the peers because basically you're saying, hey, orderer, join these channels. I could have like three different nodes or whatever. All those three nodes individually you're joining it. And then you're saying peer join this. As long as there is consensus, the peer should be able to join and operate as normal. But you need to, let's say, this is the case you need to consider, right? Let's say you have three nodes in the consenter and you need to join one at a time per se. And let's say you joined the first node, you haven't joined the other two nodes, you don't have consensus yet, right? So there is no point in joining a peer at that point. So you would want all the nodes to join, get consensus and then join the peer. That's ideal. The reason I ask that because an app channel that comes from 2.2 only has peers joined to it, right? So then in that case, you would have to join the orders after the peers would have joined already. Right, so you could have, let's say you have a single node, right? Orderer, you joined the peer, everything is happy. And now you need to add additional orders as consenters. Then of course, you would do it on the order and the peer would automatically know that the channel gets replicated and know that information. Sounds good. Yeah. Okay. And I guess my other question is, did he answer your earlier question or is this the right time to ask that question? Go ahead, ask the question. I mean, do you have time, yeah? The question was about configurations. So my understanding that the configurations, for example, endorsements of things that nature gets stored as blocks on the network, as blocks on the network. I thought they were on the system channel, but are they in the system channel or? They were stored in system channel. That's why it was a problem in terms of organizations within that able to see the changes coming in. So that configuration option, those are like not like applicable anymore because now you are working with the block that is stored like in console or like you stored it somewhere and then when you join the order, you give the order and say join this application channel. So you need to have all of, one of the nodes up and running to make these changes, but you're not, you're changing the channel within the scope of the application channel within the set of order or symptom centers and that. So there is no system channel in this case, right? So everything is managed with it by these orders that are in centers within the channel. Those configuration changes. I guess a really quick question on that. So when you go to two, four, do you have any configuration blocks on the system channel that need to be migrated to the app channels? No, so again, that the configuration changes are, you're not going back to any configuration. You basically the newest configuration that you have on the channel continues to live, right? So basically, there is no way to like say, like, hey, I wanna see what the configuration was like block 15, like two years ago, right? You're not doing that in this particular case, right? It's only the latest block that's persisted into that channel. Sounds good, thank you. Yeah, good question though, yeah. Okay, we got one other question that we can address and then you can continue on is from Naimra and they wanna know, is there any impact to the processing speed for the network if they have a system channel or if there's no system channel? I, in a normal operation kind of scenario where you are pushing block, I don't believe it affects the performance. It affects the performance when you start up a node and join and create channels and those sorts of scenarios. I don't believe it affects the performance in a working live application channel scenario but we can check with some other fabric guys on clarifying it, but I don't think it has an impact on the speed because it's again, not used for like consensus, right? That's only whoever is in the application channel is the only one that's doing consensus with me. Perfect. Okay, Varad, I think that's the good questions. So go ahead and go back to the demo and I'll monitor, see what else comes through. Thank you, John. So let me create a new channel, right? With the new, you know, so in this case, I don't have any, so let's save the channel. So I'm creating a new channel, choose one of the ordering services. This is the one we just removed the system channel and for reference, actually let me do that, just to show you the second node I created without. So order one MSP part of this guy and then order two MSP. So again, you see a message that this is the order without system channel and it tells me that TLS identity is not found. I need to create one. And it also tells me that, you know, I need to associate a regular admin identity. So let me associate identity, this is the MSP. Now I need to go back and the same process falls through before, right? Where I was showing, I need to create a new TLS certificate from the CA that's associated with the node. Oops, sorry, I'm back. TLS, next. And I say order two TLS. And now if I go back, it should show that, you know, it's a node channel, of course, so it's a brand new node. So basically I have two nodes, right? One from each organization, two different organizations. I'm gonna create a channel with both of the organization one and two and then join them. So that basically mimics the scenario where you have multiple organizations, each organization is trying to contribute different orders to the, you know, consensus process, right? So if I go to channels, create a new channel and channel two, then I'm just gonna say start with one. And first it's going to say, who's the organization like just members, right? Or one, who are the peer organization members? I'll just pick one. This doesn't matter for the demo. And this is the one of the important screens that's new screen that got added. Who are the orderer admins that are on this application channel? So the MSPs that you choose are the only ones that can join the order. So in this particular case, you can only join orders that belong to order one MSP or order two MSP, right? That's important, right? Because if you have just order one MSP, they won't be able to join because they don't have the right certificate. So this tells you who are the organizations that are allowed to contribute orders and then create. So what this did at this point, nothing happened at the order level. All it did was to create a block with the predefined configuration. You said, like again, we said order one and order two are admins and the order one is the member of the channel. We did that on, at this point, the console has a block, just created one. So when you hit the continue step, this is the joint flow that automatically gets initiated, right? So what the console did at this point is it looked at who the members are in the block. Again, in this case, order one MSP and order two MSP. And it also looked at the local config to say, hey, which of the orderers are from those MSPs? So in this particular case, it sees that one and two, like these are the two, they are already defined as concentrers. By default, I'll show you the process. By default, all nodes from that particular are becoming concentrers. So for the demo purposes, I'm just gonna choose only one to join, right? So to show you something interesting. So now, if I go into the node and then go down to order one, you should see that v-channel two is a member. However, I did not choose the other node, the node two as a member. So obviously at this point, I said two members of concentrers, generally you want three, of course, right? Just for the demo. So two are concentrers, but only one is joined. So at this point, the channel does not have a program. So when I try to go into the second node, I'm going to try to join the second node into the channel. So I say, get a channel from this org, right? So this is the error message or information message I want to show, right? So basically we are saying there is no program. Now you need to join using the block the console already has, right? So now if I go back to the channel with the console block, so we see that we stored the block in the console. Now what I can do is take the block, join the second node to the channel which will establish consensus. This may be a bit confusing. Let me know if it is. I can try to explain it a little bit more. But again, the general premises, right? I defined a channel with two nodes as concentrers and only one let join. The other one hasn't joined and hence there is no program and hence I cannot get any blocks from the new node. So if I click on this, now I can say use the block that we already stored in the console and join the second node. First node is already a concentrant and already joined with the tick mark. So I'm going to join the second node. That's it, right? So if I go back to the nodes and then go down into the second node, I should see that I joined and the consensus is established. So I can, like for example, if I did this, right? Well, I can't join any other nodes. Yeah, I don't have one. So I'll show the adding a follower part next, right? Because that's another important distinction I want people to see. But any questions so far in what you guys have seen in terms of joining a node, joining a channel to the node and then the consensus process and how we are able to use the block stored in the console to join. I'm not seeing anything in the chat right now, right? But I will say what you presented is very clear and excellent. So anyone who has any questions, they'll feel free to post them in the chat. Okay, so what I'm going to do next is, right? To add a third node, right? I already pre-created one. I'm just going to import one of the nodes I already created to show the follow process, right? So I'm going to add the third node. So the third node I created as part of order two MSP, right? There you go. So that's part of the MSP. So if you observe, actually, let me show you that that may make it interesting. So if I create a new channel, I'm not going to create a new channel. However, I would like to show, click on the advanced. So the channel three, so pick one, nothing changes. So I'll just breeze through these steps. Okay, one and two are the consent nodes. MSPs that can contribute, majority, whatever the policy, nothing changed. These are like, you know, things we used to have. This is the screen that's interesting, right? So by default, it's going to include all of the new channels, right? So I'm going to include all of the nodes that belong to those two order organizations in the channel. So right now I added a third one. By default, now it will try to include all three nodes into the concentrator, if I just unchecked it. But if I flipped it to like, no, don't include all of them, but I want to include only one guy, I can do so, right? I can say like, you know, include these two guys or whatever I want. So point being, if I flipped it to include all nodes, it'll include all the nodes at that point in time that are in the console that belong to those two organizations into the concentrator set. And you have an option to flip it and choose the specific nodes that you want to choose. So going back to the original thing, right? So when I created the channel, only two nodes were there and those two were automatically concentrators and, you know, you saw that. And if I go to this... So I see that one is a concentrator and if I go to the second node, it will also show as concentrator. And the third one, I don't have anything, you know, I'll associate this. Okay, that's... So I see that again, the third node, I have the third node, node channel, right? You know, it doesn't have any channels. So what I want to do is to join channel as the follower in this case, right? So I'm going to join channel and I say get the block from order one. So next, and then I say choose the order three. So if you noticed, right? We did not get the consensus error this time because there are two nodes in the concentrators and both are like, you know, in the channel. And you see that that is a star with follower, right? So this basically says, I have two nodes, you know, this goes back to the picture that I was showing in this screen where I have two nodes as concentrators and one is the follower, right? If you go back, not this side, join. So you have successfully joined the new channel. Oh, why is that? Okay, so let me see, join channel. So first node, take this. That may have been a bug that I don't know on my local, the code fixed. I pulled the, maybe that is a bug. Of course, it's demo time, so. But what you should have seen is that third node become follower on this channel. Let me do this for you and see if this will work just for, I'm curious. Otherwise, you know, again, we'll get the bug fixed. Yeah, this seems to be some sort of bug. But again, that will become follower. The third node would, right? Did I want, oh, the last thing I wanna show is the deleting the node from the channel, right? So if I go into the, again, the details, I can again add a node or like, you know, look at the information, in this case, again, the concenter and I can also hit the delete button, right? I can say delete this channel. So what this does is again, it only deletes the node from the order, right? So this does, as a concenter or like a follower, it simply deletes it. It does not do anything with the peer, right? The peer channel continues to remain. The fabric has, I think they already have a feature where you can, you know, remove a channel from the peer. Console hasn't implemented it yet. So that is a set of, I think PRC alike commands, right? That allow you to, you know, remove a channel, peer channel, just to show you guys. So, here then so peer node, yeah, I'm joined. So again, it's a CLI that's available in the newer fabric that console hasn't implemented, right? But it's a CLI. That's mostly what I wanted to demo. Did I miss anything? Let me just quickly check what I wanted to show migration, create, join, remove, concenter, follower, that one, I think that is some sort of bug that we'll look at. But any questions, any other questions I should say? Yeah, Barad, it looks like there's three questions in the chat. And if you want to look at the chat and just answer and that'd be great, or I can read them off to you. Let me see. So doesn't the operation to join channel require a tool of existing participants? So joining a channel, you are joining. So it's a block that you created, right? Like all one, two and three, whatever like you included. And only the guy that owns the order can join, right? There is no other pool required. Like, you know, I'm just saying, I have a consortium of three members and it's the distinction is the order admin is the only one that can join the channel to that order. So unless I have the right credential, random person cannot join my order, my channel into the order, right? So that is implicit approval, I should say that's involved here, right? Let me know if that's not clear. In without system channel, how you're gonna categorize which peers should be in which org and how do you know which peer from org confirm consensus? So the process of the peer and order organization did not change, right, with the new thing. So when you created a channel, when we created a channel, right, we basically said, right, let me go back to the channel creation. So when we create a new channel, it's still, let me just type something. We still have the same like organization list. In this case, I'm telling the channel, my peer can only come from org one MSP. I cannot have a peer from like some random MSP. So that's kind of the, again, nothing changed there. So it's only peers from the organization can join. Again, let me know if it's not clear. Again, consensus doesn't, you know, it's basically you're telling like all these peers and they are the ones that are like in authorizing the transactions and storing them and all that. Again, let me know. What are the advantages of sitting a follower? I think one is, again, the fact that you can be a quote and put listener in a conversation, not like an active participant in a conversation, if you will. So in this case, right, so all you need to do is to read the blocks, you know, from then manage like a node with all the blocks. If that node goes down, nothing changes. You're not consenting, you know, it's basically, let's say, you know, I have three nodes, you know, that are concenters and one is not concenter. If that non-concenter follower goes down, you know, things go on as usual, no, nothing gets affected. And I think one of the benefits that fabric specifically talks about, right, is the fact that, you know, the, let me see. So this particular one, the fabric, you know, that, you know, documentation doesn't quite talk about all the benefits of the concenter follower business. But if it's a follower, you know, it's quicker to join, you know, so just the particular benefits again, right? Once you sync them, then the node is in the ready state, you know, you can simply join. However, if you started with the concenter, then join, then during the time it's trying to catch up all the blocks, that node is unavailable for anything, right? You know, it's still seeking a block, it's not able to consent. So I think that's a benefit like, you know, again, if you sync up and then become a concenter, it's a quick joint process and it's right away available for like, you know, consensus. Hopefully that helped. How can you set, how can we do set up a scenario and make an strategy? So in order to set it up, if you search for operator, fabric operator, let me actually do that, right? So just wanted to give you this plug. So there is fabric operator, it's fairly quick to set up and get it running. And what the operator gives you is it also kind of bundles if you go to the console, there is a step to include the console and you can do sample network, right? And that sample network will have 2.4. So I think you can play without system channel and all that, right? It's a fairly quick and easy way to get the entire ecosystem lifecycle working, right? Where you're talking to Kubernetes, you have the console, you have the fabric network, you can easily add nodes, remove nodes and all that stuff, right? So I think this is one easy way to get your hands dirty. So again, I think we need to have a session for the operator and how to use it set up, but should be fairly straightforward to do it. They also support kind as an option, right? You know, Kubernetes cluster as an option. So this is what I use for development locally. I don't rely on much outside, but that should help. And then I'll post to this operator also, just so people have links and then the channel creation, this link, and then the CLI stuff, if you guys are interested in, or with, that's very helpful, yep. Okay, anything else, right? Looks like there's another question in the chat here from Kristoff. And I don't know if you can see that or if he can come off mute and just ask the question directly. Let's see, Kristoff, okay, follow up. Let's say we have three organizations that each managing an operator in a given channel. Now two new orgs want to join the consortium and then approval from the existing participants before the two can join. It should not be possible for a random organization to join the channel and synchronize the blocks. Yes, right? Because if you have a third organization, it depends on the channel policy. So there is, if you, let me see. That's a good question, yes. Let me go forward. So in this particular screen, when you're creating a channel, you're telling which are the organizations that are able to contribute notes. And again, in the scenario you were describing, right? There are three organizations to begin with and two ones to join. Then you need to make a channel update, right? To add those two new organizations into the order of organization. And the way this approval works is, right? That is another policy console for like, you know, the simplicity. If you're creating from the fabric operator, the policy is one organization need to approve for any new order of organization to join, which is not like ideal, but that's a controllable policy where you can say majority need to approve, in which case you need to go through the whole, like, you know, approval to add the new guy. But you're right that the policy is decided by, you know, again, that is a policy if you decipher the block, you can see the policy. And you do need, yes, you know, the current members to allow adding a new organization and then you can add notes from the new organization into the channel. Hopefully that helps. And the process to update the policy remains the same as in 2.2 by which you have to get that JSON, do your config change, generate the protobuf, do the different apply and see, I mean, sign the protobuf and then apply, that remains the same. Right. So again, there are two different things I wanna make sure people got it, right? One is the channel member policy, right? Who are the members and how does the, you know, peers join and like, you know, work with it? That's one. And the second one is the order specific list, right? You know, organizations that are part of the, you know, to do any modifications to the order level, you need to have these approvals, but both of which require approval from the organizations. And we definitely have channel level orchestration between multiple consoles to do the organization level policy, but I think we are close to being done with the order level policy update, right? So that's not something you can do at the moment from the console. Again, we send the default to like whatever, like single order need to approve, but if you need to extend it to other cases, console does not support it yet. But yes, it would require doing the whole, like a dance, right, you know, download that, you know, get protobuf, get it signed, get it, you know, submitted. Yes. And for the peers, that's what you do on the background of the fabric console, right? Exactly, exactly. That makes it easier for the peer because that's a more common scenario we have and you can do the whole dance from the console, like, you know, all the back and forth, but not for the order admins yet, okay? I think that's perfect timing. Any other questions, please, you know, send it my way, you know, or like open up an issue like we were talking about, but that's I think all I wanted to cover. Yeah, that was a great presentation, Varad. Looks like there's some other people that have a question of follow up with you. If you want, would you post your email in the chat where they could touch base with you? I think Sunny wants to reach out about a podcast. Let me post my LinkedIn, just so people have access to it. I should have included probably the, let me post that. And I think, you know, we're at the top of the hour, Varad, but let's just tackle one more question and then we'll call it good for today. And I agree with you. I would like to have a follow on a presentation by you because I think that there's a lot to cover here and let's just get on email and cover that. But it looks like there's a question about being able to set up the environment on Ubuntu 18 and an Azure virtual machine. So as long as you can run Kubernetes, you can run it anywhere. Basically, that's a gentle answer, right? So, you know, you can use kind or Kubernetes to open source the operator. That runs wherever Kubernetes runs. And, you know, I mean, I use for my local setup rancher and kind within it, right? So I think you should be able to run it. There is no reason why it wouldn't work because again, it's all Kubernetes. Okay, I think that that covers everything. I really appreciate everyone joining the call today and please feel free to follow up with Varad and please feel free to interact with the GitHub community there as well. And we'll look forward to the next presentation by Varad. And I hope everyone has a wonderful rest of your day. All right, thanks guys. Bye, have a good one. Thanks everyone. Thank you. Thanks everyone.