 recording. Sorry, David, just to say that there's no containers on regarding the no SDK today, so I'm not sure, but if it's recorded, I suppose we can pick that up, okay. Yeah, yeah, we'll record it, so folks can listen to it later, give any feedback if they want later. Okay, let me just show the JIRA dashboard for the roadmap. So these are basically any Epic in JIRA that's tagged for v2.x. I will start with the update for improved fabric samples since I'm currently sharing. So the samples, updated samples for v2.2 and using test network are well underway. We've got a whole series around asset transfer scenario. There's a bunch of chain code samples done. I'll show you that over in fabric samples. So there's asset transfer basic, ledger queries, private data and secured agreement. Those all have chain codes done and they are in various states in terms of the applications that can drive those chain codes. They can also be driven through CLI, but we're currently working to finish out all the applications at least for the basic samples so that there's a model for people to use for any language to drive a basic chain code. And then as you go down the list, they get more advanced in terms of ledger queries, showing how to use private data, showing how to use state-based endorsement. And then a final one kind of puts everything together for what we call the secured agreement scenario. Anyways, the applications are in progress for those and so are the tutorials. Some of the tutorials have been updated already. We've gotten, for example, the test network tutorial and the chain code lifecycle tutorial updated from Fabcar to use the asset transfer basic and we're rolling through all the other tutorials to update them as well. Any questions on the samples? Okay, so then I guess we'll go in order here. Jason, are you on? I'm going to give a quick update on VFT. Yeah, I guess I can give a quick update. There's some work that's been progressing on the library, but there's some items that have sidetracked me a bit, so it's been making a little less progress than I'd like it to, but still aiming to have at least a feature-complete library by the end of the quarter is my hope, but we'll see how that goes. And from there, we would start looking at integration. Okay, thank you. Channel Participation API. Will, do you want to talk to that one? Sure, yeah, I can chime in here. So yeah, things have been moving along pretty smoothly here. Yoav's been continuing to leave the charge on the join channel work. So I think we have a good base of that in now, as well as some refactoring work around some of the order registrar and things like that. So that's continuing along. We have the remove channel, also in progress, and some integration tests around. So yeah, nothing out of the ordinary really to report with any of that. Okay, thanks, Will. The config transaction library. Yeah, so there's been a couple of releases out for that already. I've just seen some initial ones. The development of that is more or less still ongoing pending feedback from initial consumers. So we've made a couple of changes already to the original API that had been released as part of the 001. I think we'll un-release 007 now with periodic incremental improvements securing their two pieces of the API just based off of feedback from community members. Still looking for more people to kind of use it and provide more feedback and then continue development on that as needed. Okay, cool. And then the doc around fabric network deployment guides. Yeah, thanks, Dave. So work is continuing on the fabric deployment guide. We've started work now on the peer deployment process. We have a work group that happens on Thursdays at 2 p.m. Eastern if anyone's interested in joining. Similar to what we did for the CA Deployment Guide, we're planning a three-part topic. Part one is going to be planning and considerations for your production peer. Part two is the configuration settings in the core.yaml that you need to understand. And a side shout out if anyone else has favorite settings in the core.yaml that they want us to highlight, they can join our work group call. On Thursday at 2 p.m. or put comments in the fabric documentation channel on rocket chat. And then part three is a tutorial of the deployment steps. So that's where we are with that. The other thing I wanted to bring up is that we need to start thinking about documentation for the fabric 2.3 release. Specifically around the ledger snapshot and checkpoint work and the channel participation API. We plan to follow the normal process where the developers draft the documentation content and then we take it from there. So I would ask the developers who are working on those features to start thinking about what kind of documentation is required, how you think it should be docked and where the dock belongs as we will start to work on that together. So that's it for me. Okay, thanks Pam. And then ledger snapshot and checkpoint. Yeah, yeah. So in this one on the development front, you know, like we had divided the this thing into four or five high level user stories. So on those, the snapshot generation story is done. And the bootstrapping story is done basically leaving the private data aside. And then to expose these functions at the peer level, the engine is working on CLI commands. So that should be done soon. And our going forward, the plan is that in parallel, we will start with the we would like to start with the system tests so that we get to see some input or some issues which we run into when we perform these things on high data volume. And so we would like to know basically those issues sooner than later, while in the background, we would keep working on the bootstrapping private data handling. So that is the development side will keep going in parallel. And after that, there are like some minor tasks kind of adjustment of existing commands, rollback reset, etc. So those should be, I think, fairly straightforward. That's the overall status. Any questions? Okay. Thanks, Manish. And then finally, the programming model updates to add high level programming model to the go SDK. Okay. Hi. I'll be quite short because that's been completed now. And for is available in the beta two release of that. I don't know how much more you want to go into it. Yeah, no, we talked about that a few weeks ago. And we've, you know, talked about maybe if that would be ready for production soon, we decided to hold off and keep that in beta for a little bit while longer and get some more feedback on that. But Leslie, and maybe if you could just update the current status field for fab g928. I think it is updated. It's actually closed. What? I mean, just this field, it says in development, you can highlight that the beta is available. All right. Okay. That's in the current status field. If you've never seen that, that is right here. All right. Okay. I've got that. Yeah. Thank you. Okay. So I'm thinking with, you know, ledger snapshot and checkpoint and the channel participation, channel participation API potentially coming in a next release might be good to do it to do a deep dive on those two topics and subsequent contributor meetings. So we'll see if one of them is ready to go in two, in two weeks or four weeks. But we'll try to do a playback in this meeting for those two items since they're kind of the next two big features coming into fabric. And we'd like to get feedback on those as well. But any other questions on the overall roadmap? Okay. So let's hand it over to David. He can show us what he's been doing around the module for Fabric Admin. Yeah, thanks. Can you see my screen? Yes, we see it. I will charge a typically technically specific and try to keep it in case we see it because we just had a little about trial just this trial of slides. Okay. This is the name of the MPM module. I published this here. Some, yes, it's already several months ago because as long as these admin capability parts of the Fabric SDK, Fabric Node.js SDKs will remove the community peoples are keeping on asking that where do we go? Where do we go? So I spent some, our roadmap is one month store or deeply dedicated for to create this compensation, compensation parts of admin capabilities, portion of the SDK. Okay. Let's go directly. It depends on the existing SDK modules that the Fabric SCA client, because it is unstable. Fabric Commons, another part is quite simple. It's my personal format. It only contains some of the constants and format adapters. So it's simply for development. Actually, if we in the future, we can get rid of it because it's just some statistics, static files. Okay, it is dependency. And this sign is, firstly, I will follow the design of like most of the rest part of the SDK that is object oriented, just coding styles. And we try, I'm trying to recover most of the helpful function as deleted from the SDK itself. And the features is now current base cover includes the channel operations, some of the query join update and check operation install approach can be. And I intentionally not to touch up about doing actual transaction part because it is quite nicely handled in Fabric Networks. So this is my design. And some of the, some of the, why see some of, one of the helpful function that I did not recover is the channel come, get channel dog gun, get channel come back from peer, do not be reviewed because nowadays from, after the refactor of the US service that we can easily get it from peer or a gate from order. And I additionally, I give some things like a gate policy Jason is the chest data for the gate DSL to end out of the syntax. I follow the, follow the design of the Fabric Core of the policy parts of the code. So you can easily have a string representation of gate DSL DSL to a portal message, which show us, show us an end out of syntax. Okay. Component map again, because aside from the deletion of the, of February SDK, I mean capability parts, some of the component is highly renamed for the newcomers when you have already played good with the old SDK that you will find, where is the PRJS, where is his order here. Now I also have a conversation parts that it is recovered, but it is built based on the new design of the Fabric SDK. So it is PRJS, it is a combination of the end also in the inventor and order, which is work as a committer and inventor. Now you may see that why the order PRJS have to work as an inventor because event, it is not designed to be, because the order is not designed to be can emit an event. I build this because I, because for the, for the intention that we could easily get directly get block from the order and the channel operation as you all know here's channel creation is just another part of the sample of the channel update. The channel update process is placed in the channel update of JS, aligned with the fabric command design. You could either use, I've decided two fashions to use as in channel update. You could either use an envelope entirely, or you can use a compact area with signatures. The first one is quite, if you can use when you want to use a combination fashions that you, first you use the command lines to, based on PR channel to sign the config, then you load the config files into the envelope, into four SDK developments. This is one fashions, another fashion is that you want to play it all within JS. So I provide two fashions here, and the channel operation, the next part is channel join, PR join and channel in nature is sending a system chain proposal to PR. So it is done in the cccc proposal of JS. You can extract the genesis data from a file, or you could use a method that gets specific block in signing identity JS. If you, or as the new design in the committer, so it's here, you could never get a block directly from the order of JS. So I compass, I, however I say, I would say it's reviewed of the old gap block from the order, the functions based on the GIPC streaming back to the order of JS. So that you can get us use other JS as the, as usual as before. And the channel operation parts they're separated in the, in the life cycle, life cycle mostly, life cycle proposal, JS mostly, it is here is the most, JS is more, more like this. For the painful package part, I will not, I have not included in that module because there are several ways we can packs, make our archive. I will provide a sample in another NPM package, but it's not included in this NPM package. Yeah, so as the, as a proof, as here, which shows all is done in these fashions. The proof for my org is a function inside the JS. And others I also implement a stream this discovery service in discovery JS. The only return, the only return the robbery resented of discovery results, no further object rebuilt in size. So for some developer, they may want just to inspect the, what is the, the raw percent raw results when the discovery has done instead of the recover all the peer and order and channels into the, they are already convect the in memory objects. And the rest is the mercenaries you may use or not to use. And I, if it is not required in, or if maintenance say it is not necessary to include in that package, I would like to remove it. This simply just wrappers, something like an event hub for event service, identity surface or wrapper of identity surface and user JS for common, the user JS in fabric comments. And some of the utils includes not here. This is the portal transmitter. This part can also be refactored in a little bit because nowadays I have noticed that the fabrics SDK had already refactored the, the port fabric portals structures is nowadays they based on fabric portal six, you are pure JS and a passion to do that inside the bee. This is another utils. I require, I recover or build collection configs function from the ones and add another functions. Now it's for a standard. What does it mean? Is there a translator from the collection config.json? What, what I have to make it that from the standard because inside the collection config.json, which is show in a sample of fabric documents that the syntax to, to represent a sign and endorsements or rather say endorsement policies inside the collection is used gate DSL instead of N out of. So along with the previous the translator where what I have mentioned about it is that I also incorporate here with a translator with, with a translator of gate DSL to the N out of syntax. You may, you may, you need to know that we as the test coverage of that entire MPM modules, I have to say, because while I want to keep it, keep it keen, I use another project is here if I fabric is me, my main main, I maintain for just as a home of the network push a composer and also the home of integration test. Some of the unit test is done inside the MPM module but I see it's not enough for the rest of the first part of this, this MPM module. I place it here. So my plans is I have, I remember several months ago, I discussed with the red logans he's not here. I want to, whether we can propose this as a third party or community contributed development tools when people were looking for the, do some big abilities for people by using private SDK as they usually, as they usually do. And the second my friends do is miscellaneous stops. And that's all of my presentation today. Okay. Any questions and I'll suggest that I could you share. Thanks, David. So what's your vision for this long term? Would you envision it being contributed to hyper ledger eventually and being kind of the notice DK for admin operations? I, I would like to contribute to the hyper ledgers because I'm, I'm also having a technical investor. So, but it depends on, because I, I am not exactly, you know, the why this, this part is removed from the fabric SDK nodes. And so when I contributed back, I am wondering which is best format or structure I could contribute back is the best for the communities. I would like to contribute in any ways. And I would like to see what kind of help but it all depends on the maintenance. So it is important for your feedbacks. Right. Yeah. I think it was just a, you know, a prioritization that it wasn't prioritized for to, to, you know, to the Fabric 12 chain code to update the SDK. So I think it would be good if there's a contribute contribution like this. And if it got, you know, consensus and community behind it, then it could become, you know, if the official hyper ledger contributed SDK for admin operations. But I think, yeah, it's, it's, you can, I would recommend putting it out on the mailing list. And people can start using it playing with it. And we'll see if it gets some traction. Okay. Yes. So I remember I posted in the node just the blockchain channel and some of them use it. But I, because several things have already passed and there's not too much discussion on this part already. So I will try to remind it again in a merit maybe. Yeah, I know a lot of people had have asked for this in the various forums. So I think it will, you will see demand for it. Thanks for helping. I'll try. In terms of the experience is if people were using the admin capabilities and the 1.4 SDK, would they see a similar use model here? A little bit different, but I try to keep the function names are same as that the old ones. Maybe you can see it because at least you will see the chunk of stories total difference. And before the package, something like I try to keep it the same experience as before. It's sometimes hard. And, and actually in 2.0, the structure of the new, actually why I see is the pool, the new, new, new structure of the SDK itself is quite good because we expose the fabric portals outside that we can place entirely. So, so, so that's the code is much more slimmer than previous than the old ones. And you do not need to have all things inside the channels. And most of, most of the, how will I say it? Another way, another fashion I usually decide is I'm trying to keep it stainless instead of keeps all that all the components inside a channel or client. You have to keep that in memory object very carefully. I will play I the way I decide this when you play out, play with the operation, play with the class, you can entirely get rid of it for the next times. So you do not have to keep this instance globally inside a node just one time. So it is designed to be stainless. In all, in all design of fabrics SDK nodes, sometimes not purely stainless. So I've tried to avoid that. From this point, I sometimes it is have different experience. Okay, thank you. Any other questions for David? All right, thank you, David. Like I said, put it that out in the mailing list. I think that would be the best place to publicize this. And then we'll see what kind of traction it gets. Thanks. Yep. Okay, anything else for today? Anybody? Could I stop sharing? You can go ahead and stop. I think we're done. If there's no other input today. Okay. Thanks, everybody. We'll see you in two weeks. Bye.