 Hello. Good morning. Oh, well, good morning. Good afternoon. Good evening. Yeah, yeah, evening. All right, let's get started. So, so once again, welcome to every V6 community call it's 25th of May, 2023. And this is our entire trust policy notice. All right. And I think we can just hop straight into it. So quick update on the mentorship program for people tuning into this. We are the application application period has concluded and we are now selecting the mentees. And we still have time till the end of this month. I think the deadline is still 30th. And then then for the next couple days after that from 31st May to June, there's like a notification period and like acceptance from the from the side of the mentees so to the head of us. But moving on to our usual, usual stuff. We have lots of lots of big list of PRs finished this week. So let's, let's go through it very quickly. So first of all, softwares contribution to update, to update some dependencies was probably easy, easier than than expected as no no code modification has to be done, but nevertheless it's good to have this in. The next step we had ledger response parser ledger response parser I'm actually wrong here because I said it's in the VDR specific specific it's not it can work with any ledger client implementation. So that was this PR. It's an in memory cache with some like timeouts and some capacity. It's pretty simple but I think this could work pretty well, perhaps in like server scenarios actually. I'm not sure if how you how useful be this for mobile wallets I guess there will be value but I imagine that the mobile wallets would probably prefer to use like wallet based cash so when a person turns off the device, the cash will be still there the next time, I suppose. It's a modular so there's a there's a cash trade. So it's easy to implement other other implementations, we might do that in a future to add the wallet one. Okay, and next step. So we removed some functions from related to endorsing it just kind of needs to be as we came to conclusion it needs some rethinking and needs to be approaching more robust way. So we just got rid of some legacy essential legacy stuff we are not currently using and we are not aware of any users of these things. It was deleted. But those other PRs related to endorsing. So on the other hand, those this PR which enables endorsing using in the VDR ledger running through this. I think I put this cashing twice. Oh, I was apparently talking about something else I opened a parser before, and I was talking about cashing, but I'm not sure we didn't actually cover this already previous week so this was parsing. This was parsing so last week might be might be in Thursday Friday. So this was parsing of the responses. There wasn't much validation before as to what is coming back from the ledger. And in this PR essentially we we pulled out data model from VDR tools as if we found it useful. So this was a component of the VDR tools and used it to validate the responses coming from from from the ledger when using in the VDR. And then as I was talking basically before having wrong tap open. We have implemented also the memory response cashier. That's that. Okay, next up, we had some refactoring about typing prover data structures. Yeah, and this is this is yet pending review but I saw it was running CI and that it's about to be ready so I put it on a list already. So, yeah, this is this is adding a whole bunch of typing for knowledge functions, actually, I guess the ones for construction of the of the presentation is that is a correct. Yeah, yeah retrieval of credentials that are appropriate for a brief request and then the presentation of them. Yeah, yeah so we'll have to take a look at this but it's really great to see this type and also the comments. It's going to be way easier to deal with for sure. Really nice job with the comments and putting this together. Okay, and then we have a whole bunch of review spending. So starting the issue credits PR the important piece we are awaiting and looking forward to. So I guess this is ready and I see that George already left some review, but I'll leave some leave the mic for for work down to comment on this. Thank you so much to say I'm going through Georgia's review right now. Overall, it's pretty much done. Now, the sort of replicates what live your live video tools was doing least like functionally, and I guess that's mainly for two reasons. To be to make it easier to like swap between them. And maybe it's going to make the migration easier in the future. Everything seems to be running. And George is making some some good points so we'll see exactly how that goes but I don't expect much work to be needed here. I was thinking, and I'm not sure if it's right thing to do to put it into this PR but nevertheless it will be nice if we have way to opt into this like credit and basically it's modular profile from the VCX. So then we could also maybe run to isn't there the modular lips. So when you run live VCX or like no jazz vapor. It's going to use the in the libraries I believe right now, unless you changed it. Okay. I don't think I did no right so so it would be maybe nice if there's a way to opt into one or the other. And so then we can also run the CI, you know, in in the credit slash in the VDR mode with no just tests as well. I mean, I guess it could be done. I don't know exactly how worth it. It is. This is just some work to kind of finish this and this thing is going to go through a heavy refactor, nonetheless. So, like as we're moving forward. I guess there's no reason to discuss the plan anymore we've been talking about it for weeks but yeah but I don't know. Well, it will be useful for migration of not just applications. Because you want to try if the critics works for it. In order to learn like live VCX. I personally wouldn't do it in this PR. If it's anything like the first time I was working on the modular stuff. It's not as straightforward as just letting live VCX point at the modular lives feature. There's still some indie like or video tools dependencies in live VCX that won't make it a straightforward migration. Maybe another PR. Yeah, I wasn't sure about if it's appropriate to put it in here could be another PR might be more work than I think. Yeah, I agree. I don't know exactly what to expect but I don't really expect issues in terms of because it's it's no longer a matter of just having beats and bits and pieces right it's the full implementation right now especially with the ledger work that Mira has been doing. Essentially the modular lives implementation uses the credits ledger and the credits add on credits implementation so only the wallet is still in the like it's still live in the art tools. And as tests are passing. I don't really think there are going to be issues at least I hope they weren't there aren't going to be issues. Well, I mean, in terms of the interoperable interoperable still have to be some like migration right and then you Well, migration of the data is a completely different point. Yeah, that's kind of what I had in mind like maybe that's more important to do first and then consider the NodeJS wrapper because they actually have a better overview of what's going on. Like, you would have stuff, you know, created through ledger tools, you would migrate it, and then you want to see if the stuff is still working, but under credits then. Yeah. Okay, then. So we'll be next steps. That's good. That's good. We can review this. I'll continue with my review I only be like partial partial ones throughout the life cycle. But I had to finish the rest of the code and I was also pushes. I think the last review I did was couple days ago so it's looking really good bugged in. I didn't realize that the whole modular Libs profile is feature complete after this PR. I thought there was still ledger stuff left but mirrors already done it so that's awesome. Yeah, it's moving up very nicely right now. Okay, so then continue in our view. So this is pretty much all in like relate to the ledger. Wait, maybe not this one. Prover handler types. Yeah, I duplicated this again. Okay, so never mind. So then this four. Well, and the first one is also another ledger that's a wall of typing. There's also a contribution from tech bash. So props to tech bash for completing this seems like almost done. Almost done. I just missing approval yet. But the CI passing that's good. Yeah, I was wondering if one of you two wanted to have a look at it as well. It's relatively straightforward but. Yeah, I'll have. Cool. Thanks. And, yeah, and the three, then the three last items here, one on top of each other and they're like, they need your guys review. So I already went through them pretty much. And the first one, maybe just to give you like the 2000 feet overview. So the first one is doing the split of the base ledger to like four different trades. And frankly, this is like less code mostly modifications than I thought. I don't think there are four different trades, are they. So sorry. There are four different trades. Yeah, yeah, there are four different trades now. Okay. So basically on credits read on credits right that relates to like reading and writing those on credits primitives. And then just in this specific stuff separated out so basically this is the kind of trade which wouldn't especially the read one, we can imagine you could imagine we would implement it for like other ledgers other on credits like Cardano, Hadera, or web on on credits web, and whatnot. And we could resolve those on credits primitives from from any data store. And I'm not sure if we'll be, we'll see if we ever do this implementation for other ledgers. Right now we have implementation. Well, everything is only implemented for indie but it's really nice that these two are now generalized. Yeah, and then also is there many methods left in the indie ledger read and write. Yeah, not not really. We can actually open up that trade file. It looks very nice. Very gives very good overview of what's going on and what's the like structure behind these things. Or is it base ledger, I guess. And maybe I can view your file. Okay, yeah. Yeah, so there's a Yeah, it's small. This is really just like in the specifics or reading attributes reading the ID transaction uttering agreement. Set endorser, I think this was fixed. This was somehow taken out or adjusted in the subsequent PRs. This is not really read but I think those fixed. And getting transaction by like sequence number. In the in this specific right it's writing the name, okay writing the ID or stuff like that writing writing attribute. And then the end on credits is pretty straightforward. Three delta. I guess these things will need some thinking. Because This this kind of interface from to I think that's in this in the specific right now so I already discussed with Mira about this while we yeah I don't remember if I Launched the idea in one of these calls but here it would be really easy to get away with an associated type. So that you have an associated type on the trade that takes some options and the options can be anything. Oh yeah, yeah I think we mentioned last week actually yeah so this way we can handle pretty much all scenarios. That's good. Yeah so this is this is it. And then the other two PRs for me that they continue on top of this one. So then in the next PR. There's a split this is like in terms of implementation in particular so that I guess both implementation in the video ledger and in the SDK ledger, they both are divided into two separate like strikes basically, and they both both of these tracks have different requirements will they need to function so. So in order to to read from the ledger, as is described here, in order to read from the ledger you don't really need request signer or, or on the other hand for writer you don't need cashier or response it's kind of like the minimal minimal like function signature minimal requirements principle applied here on this constructors now. You need to construct two things instead of one but yeah that kind of gives you better granularity options. Yeah, and then on top of that. There's further improvement. In terms of getting rid of global state previously in areas VCS core create that was this a piece of global state in a like lazy static structure. We just storing transaction all the agreement used. And this this global status read whenever you try to write transaction on the ledger. And through this modification mirror did here. We got rid of it and the world was previously global state is now like local basically to the to the writer structure. And yeah so this is always get good is always nice to get rid of these globals. Never never leads to pretty places. So yeah these three PR states review I went to them, I only have some comments on the last one. I believe that mirror has already addressed them. And this is green so just have a look and we can get this thing merged. These things. And what, what order should these be reviewed pretty much. They're pretty much sequential so, you know, six to is based on 6463 is based on 62. Okay, great. And what about the issue of credits. I imagine there's some conflicts. I guess that would be pretty much separate large largely independent although I suppose there might be a conflict if we merge one or the other first. But I don't expect some significant conflict so I guess just whatever comes first comes first. Yeah, and I guess in terms of upcoming work. I have a bunch of things to merge the credits and this ledger stuff. So those will be the priorities. Finish are in on a side of the mentors. We need to pick out the because our mentees from all the candidates. And then, and then I guess just continue driving all these things to completion, the critics and the ledger stuff. And also, also the, I think I mentioned last week on to work on the, the idea is over integration I didn't really have time to progress a much on that front so. If anybody would actually want to pick that up. It's like free to feel free to go ahead just let me know, because I don't have much stuff down there. And yeah, we are breaking down, breaking down the interfaces in RZCX, RZCX core into smaller pieces the ledger is pretty much done. The end on credits I guess we can start splitting us splitting it out. Once the, maybe the credits is done and we get rid of the. We get rid of the VDR tools components. And then, yeah, also after it. So once these two things are kind of complete. We can start off thinking we can start thinking of the wall but I guess. That's still a bit further. And then of course the types that pattern. Once we, once we do the, once we do the whole running sure we can start writing those, those tests I think the priorities are pretty pretty clear now. Any, any comments guys from our vision and things lying ahead. Anything from my side, just to brace yourselves for all the work coming. Yeah, that's. It looks good. When does a non creds RS come into play is it the second part of that core breakdown. Yeah, I think essentially the outcome is going to come and play when we drop most of the video tools we do the migration from. The VDR tools to credits. And once we see that's working essentially critics is going to be dropped and replaced by on creds RS. At least that was my understanding. Yeah, I think so. And I suppose this like split out into interfaces that's actually like pretty. I don't think there's anything for holder, I think, and on on credits. I mean, that's technically because a holder does nothing with them. You just receive them. And I think that's pretty much it. It's a matter of just prove or at least I haven't seen anything like holder specific in any implementation. All right. Yeah, so I guess it's more of a prove or functions. Yeah, the same agent right so yeah. I mean there's there's methods like getting credential info from the wallet. Things like that it that's more of a holder piece of functionality which is okay. But in my opinion holder and prove are pretty much the same thing so it could be grouped together anyway. Yeah, I guess that's that's pretty much what I mean like they are supposed to be the same agent because being independent entities would make no sense. Yeah, yeah sorry yeah I understand cool. Well, all right. I was a quick one today it seems like. Unless there's any any other final thoughts, ideas, comments. I was wondering, were you looking at the ACAPI implementation of the issuer stuff when you're working on critics. Not that much. No. I think I mentioned in one of the comments on the PR that I kind of aimed more for like video tools backwards compatibility in a way like just kind of replicate what video tools was doing. I know it does a lot of bad stuff, like even this credits issuer implementation is not necessarily my proudest work but the goal was just to get this out of the way. And, like, I know, for me the target is the unknown credits are a supplementation on which I will work a lot on optimizing optimizing stuff and whatnot. But I agree there's some really weird decisions that were made in terms of video tools like storing that schema ID. When it basically can be pulled from the credential definition itself. There are some some quirks. But kind of replicating that I think will make it easier in terms of that migration which we kind of plan. Yep. Yeah, okay, awesome. Yeah, I was going to say, I've had your file open next to ACAPI is and the flow is pretty much the same so validating yours is relatively easy. It's good that we're similar to existing things. Right. Okay then seems like there's no more points of discussions so we can close it off and thanks for thanks for joining in. Have a good week. Cheers. All right.