 Greetings. I said, can you hear me? Well, either you don't hear me, or you are muted, or maybe you're AFK. So George just texted that there's a technical issues. Hello. Hello, hello. Hey, sorry, I could hear you, but my zoom was freaking out. Works now. All right, cool. So we got the technical issues out of hand. We can get started. Bogdan is not joining today. So unless anyone else is joining, it will be two of us. Let me show my screen. So last week was canceled, but this week we are back online. So welcome to April 27, 2023, Aries V6 coming to call. And this is our antitrust hyperledger, hyperledger antitrust policy notice. All right, so let's jump into our agenda. I'll just repeat once again for anyone who might be listening that you can feel free to join these calls anytime. It's always 9AM EDC. You can just hop in here and discuss whatever is on your mind. Or you can also feel free to come here on the hyperledger wiki and tweak the agenda. And put some additional points into the program. So let's start with the first point here. So good for issues. We've been a post a little bit. This got like really amazing traction. Lots of people being interested. Lots of people have contributed a PR and basically all of our good first issues has been taken and addressed at this point, every single one of them. There's been people asking what could they pick up as people eager to to contribute. Unfortunately, there's a there's overhead just creating and kind of managing these issues and at this moment we simply like ran out of them. So people would like to like kind of get started with the repo and have a first contribution. And I just have to wait a bit more until we come up with something more. Right now, we have a whole bunch of PRs here waiting. And just by the way, there's often false positives here, I think it's something we'll have to address on CI for example, this PR right here it appears red but it's really just CI issue. Okay, I'll definitely be making like more of this in the future so stay tuned. Next up, we have somebody's, somebody's texting. Yeah, someone's asking for zoom I think link. Okay, we'll have a new visitor here. Let's see. And maybe I should include the link when I'm posting the messages on discord I just post the link so I'll be easier for people to find it they don't have to browse through through Wiki. Yeah, there's like pinned messages as well. I wonder if. Yeah, I should take a look at that. All right, let's move to the next point so the mentorship program. So we are current there's no significant update we are according to the program dates calendar we are still in this period of mentee application on LFX mentorship. And there's a link over there, you can find more information about how to apply. We will continue all the way until 10th of May so I think that's like one or two more weeks. Well, next up. Yeah, that's pretty much it for the kind of intro and think from your side George. Before we dive in. That's over me now nothing. Oh, and we have by we joining our call welcome. Thanks. Thank you very much. Would you like to send you usually when when we have a new visitor we like, we give option to introduce a kind of briefly, the people so would you like to say a few brief words about yourself. Hello, everyone. Actually, I'm an undergraduate from India, and I'm absolutely new to the technology and I've chosen areas for the like LFX mentorship program for like to pursue it. And yes, I'm also a learner of rest right now, but previously, I'm an open source contributor, and I've been contributing in open source projects of application development before, but this time. It's the first time of mine in hyper ledger technology. Thank you, thank you. Welcome. Thank you. Anyway, have you, have you already submitted the mentorship application. Yeah, I've submitted the mentorship application but my resume and CV is still pending and I'm working on that to like, give the best of give the best of it. Right, right. All right, thank you. And let's, let's go further in in our agenda so as for like the overview of the work done we have most significantly just pushed out that really 055 which significantly contains a migration to the new messages great. This has been tested pretty thoroughly. And actually, it got squashed in a few more upgrades, other than just the message in the new messages create integration. There was a changes to testing, we got rid of all of our, well, not all many, pretty much all of our testing feature flags. Unfortunately, on the way, we also lost some unit tests. But this will be addressed as we go and anyway we are, we are now in kind of transition their period where we are migrating lots of code from all the implementation of state machines to then you kind of type stick pattern as we, as we, as we used to call it. So that was which PR and just to point it. It's among the close ones. Yeah, so we had the 055 release just four hours ago and then those these refactors like replacing messages, it was a huge effort by Bogdan. Yeah, this was also tested outside of the repo as I mentioned here on some internal projects across also cross tested with all the versions of VCX and AFJ on the on the client side. So kudos to Bogdan for pulling this off. It was really a long long term effort. And I think on a way we also, or maybe especially Bogdan learned on about all of the other stuff which has a potential to be improved and I think, I think bright, bright, bright, bright days are ahead. Lots of lots of a lot more improvements coming. Next up for the stuff in progress, and also kind of, we come, we talk about priorities priorities and next point so I just stick to agenda so what's in progress. Well, there's two most kind of second second in in the order significant PRs. One is the ID resolver. So this, this is a foot from Merro Mirgi. And basically, it's really nicely described here, it's still in a draft state and needs to be reviewed. So we have some comment here too. So this contains actually a whole bunch of crates, as is described. There's a DID parser for simply parsing strings into some sort of DID typed DID REST structure. There's a did dog builder for constructing W3C compliant did dogs. There's did resolver, which is kind of a general. Let me, let me, let me get right there's did resolver, which is kind of a general trait for implementing did resolver. So whenever you want to add and support for a new DID basically would go ahead and implement these two traits mentioned here did resolvable and did the referential. And for right now we have one DID resolver implementation, which is did solve method. But it can be expected that we'll be adding did in the method, which will be a kind of as per my understanding it's going to be new DID method on in the ledger itself so essentially two alternative ways to write and resolve the did the documents. And lastly, there is a did resolve a registry, which is a create which kind of well as names just it's a registry of resolvers so in practice in let's say in terms of areas DCX integration, probably we're going to have one DID resolve registry where we inject a different resolvers which you want to support in runtime. So you might choose that when you want to use areas DCX you want to your application should support did solve resolution and let's say Bitcoin the idea resolution. Then you compile then you can choose to compile simply those resolvers and with their respective dependencies, which are interested in and then get them registered into this registry in runtime. And then this will be Canada, the interface which areas DCX itself would interact with, and underneath this registry would call the individual resolver implementation implementations through the did resolver interface. And all of the all of this resolving code is pretty much harnessing these two other crates for the dog building and the ID parsing any any comments. Any comments on this one. Looks good. Awesome. Yeah, I think meto did a good job, but I mean it looks really nice. Just, just need to dive in and take a take a deeper look at it. And yeah, I encourage everyone to do the same and leave leave feedback here. And the second among pretty much equal, I think priority is the state pattern. And in particular we already have credential holder state pattern cooking. So we have this PR with extensive discussion around it. Where is it. I lost it. Yeah. So it's in a draft state. We had a bunch of discussions here. It was a bit of my radar for a while. So I don't know if there's been any, any updates. I don't see any new new comments. So yeah, I'm sorry. Yeah, a bit of an update. So after the meeting two weeks ago, I worked on it in a new branch for about a week. And I haven't merged that new branch back into this one yet or reopened the PR. But yeah, I just decided to do it on a new branch because a lot of the message stuff going on. I'd opened that original PR before the message to stuff. So yeah, there's a bit of refactor that needs to happen. All that needed to happen and now needs to happen again with now that it's merged in and integrated. I'll probably do that this week. And in terms of the API's for that holder structure. I'm not sure if we reached like a happy conclusion in the comment section of that original PR. But I think the approach that I have at the moment is pretty good. And it won't take much to adjust it if we decide to change some things. But yeah, I really just need to rebase and work on it this week and hopefully have something by next week. Awesome, awesome. Yeah, and then I think like it would be nice basically once we have this credential holder. And if you manage to also do like in the same fashion credential issuer that will be really nice to I already put it here I kind of I'm kind of jumping now but but what the hell. It's relevant. I was just thinking that we can start kind of approaching the testing in a new kind of new new generation testing where we can start writing the kind of integration tests with like revocations and I mean we have a whole bunch of these kind of issuance and revocation scenarios. And we could start approaches in like completely new fashion start kind of new testing infrastructure. And most of all do it connection lastly so there's no need to do with connections when testing credential issuance slash holder protocol like we can just assume that the messages are burden delivered some way and since we are no longer embedding the IO into the state machines anymore, and we have all the messages sending kind of is responsibility of the state pattern consumer, then it'll be really easy to write this kind of connection less tests I believe. Yeah, for sure. And great. All right, now let's, let's follow our points in the order. Sorry for the tour here to the next point. So we have, I would like to just mention the other PRs honor, I always like to honorably mentioned new contributors on the call and makes me really happy when there's new people coming in and, and they put their time and effort to to have a contribution and and learn, learn about our code base. It's amazing. So, first of all, this encoding attributes, this been, this been going on for a while, I really appreciate Steven as persistence through this because we picked pink did back and forth multiple times. And last time he got, there was some further feedback from Bogdan, and Stephen reply that he's off for a while but he will be able to continue in the first week of May so let's let's wait for him. I mean, this is not urgent. So, even if it's later than that I think we can wait and it's it's not biggie it doesn't really conflict with anything else we are doing. And it's, it's definitely improvement already now, but, but there's space for for for further improvements per Bogdan's comments. So happy about this one excited to sit sit during to completion. And next up we had the first time contributed contributors wapture, which took the PR, the issue to update time dependency to the latest versions zero three 20, which is was not completely trivial. It actually included some sync up in the code as that the crate has done some breaking changes from the version where we are right now to the, the latest version so there's all these adjustments to make it compile so thank swaptor for for this one. This is passing, as I mentioned, we are getting this false positives failures on the CI where, when the PR is being made from a fork repository, this publishing job fails because of permissions. We need to adjust CI so it just the CI so this job wouldn't even run if the CI is running from the fork repository. So we'll get this tree then I will be more rewarding for the new contributors when they actually can see straight away that there, there's the PR is green. So we can actually merge this pretty soon this looks good. Next up, we had some deserialization tests I think this is similar story, I believe. Again, failing on the publish docker, but it's it implements what it should there's like two, two tests for serialization deserialization. It's useful even in terms of like, kind of documentation like you look at the tests, this kind you look at this kind of test and you see immediately like how does the serialized version currently actually looks like and was the testing so this is nice. Thanks to nachi cat Kanore. And let's move on to the next one and there was similar PR it's similar kind of tests, again serialization and deserialization of some some structure we have. The structure is mainly harness and V6. Nevertheless, again, it's useful just for the kind of documentation element of it. So thanks to tech badge first time contributor. I am the son so. Oh, thank you so much. Yeah. I see that's you. Okay, good. Good to have the different nicknames so it's good to be able to match the names through this core and the github. All right. Last there was a post message PR from Andy Wayne this will also kind of going on for a while, and they will have a bit of a work here to sync up after the marriage. There is a whole bunch of conflicts here but I don't think to be too painful to do. It will be a little pain, but I think it's doable. I just put a big message to Andy if he's gonna continue working on this. So let's see. And these also are first time contributor. There was one more. First time contributor. There was some cleanup in constants dot RS file. There was a whole bunch of constants which were not being used. And also, it was not really formatted. So now that it's easier to when you're checking tests to check what is some test matching against it just simply much, much easier now to take a look at. Just a nice json than just a json online. So plus one for readability. Thanks to press on 023. Again our first time contributor. And that's brings us to the end there was one more PR from me, which is removing some dependencies which are not necessary. I haven't solved before, but I'm trying to get it working again. Looks like I'm running to some failures, so I'll have to sort this out. This is removing in the logo create an Android logo from areas VCS. These kinds of things just simply don't belong there. These VCS should not dictate what kind of logo implementation is used. And it should be a responsibility of the crates above it. So if you are consuming areas VCS in your own trade, beware that you need to plug in the ENV logger yourself if you want to use it. We do it, we had to do similar change here for the node wrapper where we previously didn't have ENV logger as we rely on the one in the areas VCS. Now we have to plug it in and make sure that it gets initialized and set up all the logging format. This has been pretty much copy pasted from the areas VCS. So if you want to maintain the same capabilities, same format, same everything, you can again just kind of take it out from here and move it to your project. But this is this is nice cleanup for areas VCS. Also, there's no reason why areas VCS should be like aware of anything related to Android. So this definitely had to go right. There's no comments and we can move on. So just upcoming work, I think there's not really any new items coming in right now, more of just setting up priorities, you already know what we're going to focus on. So they'll be getting the DID resolver, all the DID and did dog related stuff reviewed and get it integrated right now. It's simply contribution of those crates, those components into repo, but so far there's no integration so there will be probably separate PR after we get this one merged in. And second priority, I mean equal priorities, the types that pattern and the new approach to testing which kind of comes along with it. So I think it's pretty clear. George, I would like to just ask if when you will have a moment, have a look at the DID parsing. I'm sure that Mira will appreciate any any feedbacks on it. Yeah, yeah sure. But also anyone else. Bobby, if you, if you, you know, feel, feel like you want to give you want to give it a shot, you know, I mean it can be pretty challenging but my point is that everyone is welcome to leave review leave code reviews on this PRs, even though if you even if you are not maintain or directly or something like that. Yeah, for sure. But first I'll have to like learn about the ideas only. It can be, you know, it can be your kind of a learning experience. I mean, definitely not something you have to do, but it just, just, you know, throwing it out here like it's options for anyone, including you, and it can be probably, you know, whoever is like a new contributor. I mean this will be extremely challenge, and especially if people are also new to rest. This is going to be extremely challenging to review because it's like a new domain. And it's also possible like, like fairly new language for people. It can be just simply opportunity for you to learn something, you know, you can drop in, people can drop in questions. Why is this the way it is and stuff like that. There's a mirror did a really good job documenting it. So he linked all the specifications here. You might be able to kind of better understand like what links to which standard what is what is specified where where it's implemented stuff like that. Okay, and that's our priorities and coming work on the previous meeting we were discussing the trade naming. And we came to some conclusion but still kind of open I think at that meeting, both of them wasn't here and I would like to also hear like opinion from from mirror. Maybe you can just discuss this on on some chat. There's just a question mark if there's any new good first issue candidates. I think there might be I mean I have some ideas. I'm not sure if it's right time to create a new good first issue and there's still so many like first time contributors. If we are spending, if we create more good first issue I'm sure people implemented but then they're going to wait for a long time to get it merged possibly so let's let's get this little bit paused for a while and then we can maybe next week or so after things get resolved a bit we can we can do something new. On the good first issues. I have an idea but I'm not sure if it's a good first issue. Maybe you can let me know but all the interfaces for all the trades for, you know, base wallet base and non creds and base ledger. They all take in Jason's at the moment Jason strings and and return Jason's. And it's sort of a bit of a thing that smells to me. And it could be improved. Yeah, and the reason actually is, I think it's kind of, I mean, you implemented those interfaces and the way you had to implement them in a string way was because long time ago, I mean, it was not so long time half a year ago. You still were using FFI to talk to Liby and the and everything else string so that's kind of yeah exactly this is I think this is great for as good for this issue so I think you should go ahead and try to, you know, formalize it into issue or maybe split it down into multiple. If you think there's a way. Okay, I'll do that. So it's good. Don't be great. But the issue sounds interesting to me. Yeah, if you would like, like to assign it to me if you want, whenever like you update the issue. Okay, great. Yeah, I'll let you know when I make the ticket. Maybe, maybe you can George directly tech. Bobby, I mean, you're using the take a bash nickname on the get up right. So maybe you can just take him so other people wouldn't take it since Bobby spreads his interest, you know, because there's like fight for his good first issues. Everyone wants to everyone wants to do them. Yeah, okay, great. Sounds good. Thank you. Okay. Anything else guys. Um, I was wondering as well, will you all plugged in be working on type state patterns in the coming future yourself or. Yeah, I think, like, I would like to do the you're implementing holder I will do I will probably start working on issue or or maybe I don't know probably one of us would start at peace and then we can finally start doing those tests. I'm really excited for that. So I'm excited to see all the tests to pass in like, at least 10 times faster. Yeah, yeah, because I was, I was going to say I'm doing holder at the moment and I take your point about doing issue and next would be good for the sake of making some nice tests. But I think my priority after hold up will probably be to do the prover type state. If that lines up with things well. Yeah, I think that's fine. Then probably we can do very far on the other side. Okay, great. It's kind of perfect synergy, because you guys are more interested in the like prover and holder side and we are more interested in the very far and sure so it's pretty. Yeah, pretty nice. Awesome. Cool. symbiotic relationship. All right. If there's nothing else. And I think we can conclude this meeting as complete. So yeah, thank you guys. Thank you for joining. Both of you. The meeting will be again next week 9am utc. Same thing. Same time as always. Have a nice rest of the week. Friday and then enjoy the weekend. Thank you guys. Thanks everyone. Hey Patrick maybe look into pinning the zoom link in the chat. If you can, that'd be good. Yeah, I will do that. That's a good idea. Cool. Thank you. Thank you guys. Thank you.