 Hi, good morning Jonas. Hello, good morning. Can you hear me? Yeah, I can hear you. Let's just wait for other people to join. Yes, I'm not sure what's going to be our attendance today. There's not some sort of big items on the agenda, but let's see. We have this bot which started to join these meetings, this meeting analytics. Apparently it's not from Hyperledger and they tried to ask them to stop doing this and they didn't. So I'm going to see if I can somehow kick it out or turn it off. It doesn't look like I can kick it off. That seemed to work. Yeah, that's good. Let's get one more minute and I think then we can just start. Last week we had a nice attendance. People from almost every continent. Sometimes more of a podcast and sometimes it's a really nice discussion. It varies, but I'm going to start sharing my screen and get ready. So can you see my screen? Yes. Okay. So yeah, welcome to February 23, and this is our Hyper Hyperledger anti-trust policy notice, which we shall display before our meeting begins. So I'll just leave it here for a moment. Right. And let's get started. So, yeah, again, hi Jonas. I suppose you're here first time, right? And I don't remember joining you before. Yes, I'm here first time. Yeah. Awesome. Awesome. I'm really happy to see new faces, new voices. Would you mind to just briefly introduce yourself since you're joining for the first time, you know, just like, maybe which, which company are from and like, what's your, what's your use for a CCA stuff stuff like that. What kind, what's your kind of text tag? Yeah, sure. Share. So, yes, last week, a colleague of mine Raphael also joined the call I think first time. Ah, right. Yes, we're working on the same project. So for the Swiss government. But he's more like the mobile developer. And I'm more in the infrastructure part. And maybe also in the future, trying to add some features that we need to every six. So I thought it would be great if I can maybe also join sometimes this call. Sure. Sure. I'll be happy to have you. Maybe just wondering, are you considering buying chance using every V6 on like the server side as well, if you are able to share that information, or is it just the mobile case? No, for us, just the mobile case and service. We're using a couple. Right, right. Yeah, that's, that's common pattern. Yeah. Yeah. Okay, so, so let's just get started and proceed with the agenda. Well, since you introduced, let me also introduce briefly some I'm Patrick Stasch. I'm one of the maintainers of the six repository. We forked it a couple years ago. It was originally developed by every name then we kind of took it over and been trying to improve it over time. A little by little. And here we are, we started doing these community goals about a half year ago. And my Saudi, I'm, I'm, I'm, I'm working for Apsa as a South African bank. And yeah, there's, there's actually a few of us maintain this at this point three of us participating in the maintenance of the repo. And we mainly, mainly JavaScript and Node.js stack, moving mostly around, around the backend and infrastructure areas as well as you. Yeah, so now let's let's get down to agenda. So I guess we covered our start meeting discussion here and today's pretty brief. So as for the overview of the recent items, which has been done we had zero 52 release. And the thing that was released after a longer period of time was more than a month was more than a month. Yeah, it includes a bunch of goodies. There was a huge, huge rewrite around the connection struct connection abstraction. And that was, that was something we have added only reason in like recent months so we were able to still, I mean, it will still, it's, it's, it's still reasonable to do this kind of like significant changes it was pretty new feature. But yeah, it's much better. And now we are basically thinking how to how to apply the same types and pattern on the other state machines, every state machines we have. But of course, we would try to do that with less of a disruption. Since here we were able to just rewrite it from from scratch make a breaking change but for the for the other other state machines with state machines which has been part of the repo will be probably more more cave careful and try to provide some smooth smooth migration path. So this was very cool stuff by done by Bogdan. Next up. Yeah, there was some following up adjustments to this PR. So it was just some fixes, some renaming and fixes around the Node.js wrapper, a regard to these changes. And then we had part of this release was also embedding VDR tools dependency in the repository. And I see that we also Bogdan and made a slot join so welcome guys, these are my colleagues. Hello. I don't know, did you guys join if you hear heard Bogdan's mind introduction. Yeah, and I trust policy. Okay, right. Yes, I know about you, but Jonas, but Jonas is a colleague of Raphael who joined last week as well. And yeah, so now we are covering the agenda so just doing this. I've joined pretty much with Bogdan. Yeah, I see. I didn't know this when when you join. Okay. Yeah, we had embedded VDR tools dependency in the repository. Followed up by some like huge purge of unnecessary code. And then some minor updates updated Tokyo to a page version, and then the other updates in this release was around were around livey CX was one PR from Raphael as a first time contributor to the repo, always happy to get this kind of PR. And then some adjustments to notice wrapper that also relates to livey CX and CI. Yeah. Coming back here. I guess I'll just once again note for as it's important information that going forward, the livey CX is considered somewhat deprecated. In fact, the next item on agenda here is this PR where we are splitting livey CX into two crates livey CX as it is. Yeah, but we basically livey CX will still represent livey CX as is today but it's a smaller crate and we extracted its core piece into new a new crate livey CX core. And this is consumed by both livey CX and the node JS wrapper. And yeah and so going forward will be like officially deprecating the livey CX along with the Java and iOS wrapper, which are built on top of it, which in practice means we won't be adding any new features here. And it will be just like minimal level of maintenance, maybe there's a security patch or something like that, that that can be included. It's just like no no active maintenance but if if if there will be interested parties in taking this, you know, taking, taking maintenance of this over. And I think we are more than happy to, you know, give out that that maintenance responsibility just we don't have the resources to maintain this piece anymore. So it's open open to committed to possibly pick up, but that ties again to another item we have on the agenda here, and that's the updated read me files. So this has been just fresh emerged this morning. And basically we talk about the deprecation quite a bit. The main read me page is separated for like the rust developers kind of introduction and for the mobile developers. And here we reiterate the deprecation piece quite a bit. Basically, we say the livey sex is along with Java and objective C wrappers are deprecated. There's a deprecation notice now. And basically we say that we encourage people to rather use recently merged unify areas vcs. However, that's only in a stage of proof of concept so it's very incomplete and there's lots lots of work to be done here. On the other hand, it has like much brighter future potential. So we are looking for contributors here. Well, I mean, we encourage this definitely more than the BCX, but it's up to community and up to people. In the end what they decide to go with them, maintain and work on. But but from our point of view, this is this is the right way forward. And so the read me itself, it's pretty much updates all their read me file so it's the read me for the this main read me the areas vcs also also somewhat updated. I think I'm not going to cover it all but I believe it's much more friendly now, and it's going to be important as areas vcs. Now it's going to be included in the hyper ledger edx course. We should be released today 23rd I believe some looking forward to to see the mention there and see if we see if we notice any increased traction of interest as a result. Now, moving forward to the stuff which is in progress there's like two work streams right now going on and one is from Bogdan side and one is from the side. So I don't know guys if you want to do like any any update on these items. I'll, I'll the floor is yours. You can, you can, you know, choose to do it just brief, brief update or I don't know if you have something interesting to share. Go ahead. Well, I'm not really it's still work in progress. I guess the more interesting stuff was showcased last week about the messages this realization and the message type parsing. Right now it's just a matter of like previously just to get that working I use the message stubs and now we're pretty much working on implementing proper messages and that's almost done. And then I guess the upcoming work regarding this is implementing some traits for common behaviors and some message builders where necessary. But yeah that's that's pretty much it and there's also like the protocol registry which I want to rewrite and basically have static or rather compile time a compile time registry of the protocols and their versions that are supported by, you know, a certain agent and the protocols and their versions would be pretty much allowed through or triggered through feature flags, not sure about the future flags right now and what they would look like. Because that's less important as of yet. Pretty much the idea is just having that registry that's generated at compile time. But that's pretty much that's overall the the last item on the list. When that all is done I initially I planned to and I guess that's still right now the plan to integrate the new messages great into areas VCS with its current state. And then we can move on to refactoring some other protocol state machines like we did for the connection state machine. But actually wanted to run an idea by by all of you. I'm wondering whether there is a benefit in retrofitting the new messages great into the existing areas VCS since we're going to rewrite the protocol handlers and all that. Maybe it might be worth it simply have a separate branch where we merge all these changes and we can review all these changes the messages great to each individual protocol handler and so on. Basically have all these changes done in bulk and not maybe not spend time retrofitting stuff just to get it refactored later. Do you think it will be challenging to integrate this great. I don't know, probably not. I don't expect it to be to be that difficult. I guess I guess we'll see at that point. I find it. I would rather avoid that approach. I think it can be. I mean if it's not especially if it's not too difficult and I would just try to keep keep the main branch update as much as possible and trade on that. We're like better collaboration right if multiple people do some jobs and if it's to branches which start to diverge a lot it can be difficult to to get it through you know merge the game. I've also considered that like retrofitting stuff would help with iterative approaches, definitely. So yeah, as I said I assume it's not going to be too difficult like the message structures. The message structure itself doesn't change as much it's just about how we handle messages that will be different. So, presumably it's not going to be too difficult to to fit into the current areas BCX. Okay, well, regardless I guess in the end you're right about the iterative approach so we can stick to the initial plan. But yeah, that's that's pretty much the update nothing really worth showcasing, I would say. All right, perhaps a middle flower you know if you have any any thoughts or comments on the, you know, on the book dance and yes it's not like just just me ruling it out or something. I'm pretty much agree that I would prefer also integrating the changes of the rest of the code base and merging it to master. Keep it in keeping it in a separate branch. Yeah, I also agree with that. Okay, so I guess is a strong has been decided. Yeah, yeah, what about you know, how's a teach this thing going. What would also also not much, not much to update on that front I just updated the CX version to used in any agent as done as to 05020 to the latest release. And there's some changes which had to be done associate with this to make the, make the scenarios pass. And these, these changes were merged yesterday to the age. And so the results were run and are in other work. And, like, the ACAPI interop tests are working fine, a CX versus a CX of course, also fine. And there are only some issues with abj but that's because in other the version that they use is alpha and when I was this testing against the latest stable version which is 033 abj version 033 at like tests, which I, which were running were passing still so that's that that's why it seems in that or that's that's why some of the interrupt us against abj are failing in, in order. Anyway, so that's, that's the, that's like, all that is to on this topic. Thank you. Yeah, and then I guess for the upcoming work. I'm not gonna even put ending here. We are currently busy with these things and I'm not aware of any sort of like active. Well, I'm not sort of any active other contribution going on right now other than these two and also anything, anything new planned up in a like close close future. So we have like huge backlog of stuff we want to do. I think we could actually extend this a little bit with the stuff. Bogdan Bogdan mentioned. But yeah nothing I think no new items will be starting until the next week, possibly, I guess depending on how, how this thing will go. And that that's bring us to Dar and and meeting discussion so maybe I would just such as we can go maybe through the backlog here and see what we are missing and what we can remove. So, so maybe I'll start with adding the stuff you Bogdan mentioned so you mentioned you. You would like to do the protocol registry right that was one thing. The protocol registry refers to mainly to the discover features protocol. Well, actually I have a comment on that is that I'm not sure about the compile time idea because sometimes you can have a like agent, like, let's say institutional agent, which are like, yeah, let's say even mobile device, let's see a mobile device, which might be like, including the code for credential issuance, but typically, and I mean currently since we don't have some sort of feature flanks. It actually always does. So, so maybe it's like it should be actually like in runtime determined like based on, you know, whatever the, whatever the user or the developer chooses to to use and Yeah, they can do that. They can do that when they build their agents. Essentially, we provide a lot for building agents right so when you build an agent you can choose what versions and what protocols you want to But I think it's it's likely. I mean I don't know how we will go with the uni ff5 for example, how the workflow in a future would be for the developers. But, you know, like if you look for example the pattern with libcx like we pre built those like rappers. And we can choose whatever feature flags we need for driver we can expose all of them. I mean I'm not even sure about like the protocols themselves. All I know is that at least for versioning we should be definitely using that. So if someone doesn't want to use, you know, the credential, the issue credential v1 protocol and just want to use the v2, they should be able to do that. And not only would that lower compilation time but basically removes this code that's not going to be used from a certain I mean technically the compiler would remove that code anyway, but it's about compilation time and it would make that protocol registry be completely in check with what that particular agent supports without developer having to do anything at all. Apart from setting up some feature flags. And I have. I feel like it will be useful to have option to kind of select the protocols you want to support like on the fly. Let's say there's like two. Let's say there's a new connection protocol right you are running institutional agent. And now there's a connection. And let's say we have a connection 1.0 and there's connection 1.1. And you are not sure about the impact you know this upgrade is going to have on you or if it's if there's any risk involved so you want to do it. Kind of. It, it's relatively like just using 1.1. So you could you know if it's if it is possible. Yeah. So you could just like switch to 1.1, you know somewhere integration without redeploying and rebuilding your entire application. So, and there's no reason why 1.0 and 1.1 cannot coexist. It's just about being able to choose what you want so if 1.1 comes out and we like nobody's forcing you to you can enable absolutely everything and just allow things at runtime if you really insist. But I mean, usually that's not how you would do something like this. Generally you want to allow certain features so that you know for sure that if you don't want to handle something there's practically no way for someone developer to code that in. And again the big idea here. Like I said we can even just not provide any feature flags whatsoever. Although I would but the whole idea is basically having that static protocol registry. Which is created at compile time and it comprises of the protocols that are supported by the agent and that would basically be done by knowing what, as I said, what versions are supported and what that. Yeah, I guess, yeah, I guess it makes sense to, I guess. It's a starting point like it's like the boundary like like you definitely don't support anything more than what you compiled right but I guess I just think that it will be nice to have option then to opt out, maybe on the fly, you know, like you can actually even though we compiled, you know, connection 1.0 and it's in your code and technically supported, like you should be able to actually tell. Actually, I don't want to use this, even though it's, you know, compile I don't want to have it in a in a discovery, you know, protocol listed. Alright, so essentially this is just about, I mean there's definitely some some reason why you would generally support certain protocols, but you don't want to expose that to maybe some newcomer like a new connection or something like that, someone that like an agent that you do not know. So there's like it's not about sending only that protocol registry like exactly that protocol registry every time it's about having that as a baseline. Yeah, what you support and then you can obfuscate certain protocols or certain versions that you don't want to, you know, you don't you don't want to provide. So that can definitely be done and probably should be done. And in terms of, like, it would be cumbersome probably to have someone create like log in a feature flag for absolutely every minor version of every protocol so we can have a lot of flags that would incorporate other feature flags like we could have an old flag that basically says yeah just compile everything I want to support every single version that is being provided, or just have common things or we can have a latest flag that basically supports just the latest versions of all protocols I don't know. I don't know about the organization I didn't give that that much thought yet. Basically, as I said the the whole idea is having that protocol registry as a baseline which really just means that these are the protocols that are coded in in the agent, and whether you, you know, you want to manipulate that a bit and remove some stuff that's that's up to you. That sounds good. Okay, and then we are in sync. I think that sounds good. Okay, so let's do the protocol registry. Compile time. Protocol registry boundary, I will call it as you don't do definitely don't do anything else outside of what you compile. What, what is this about the cloning of the dog creates. I don't actually I don't remember I believe this is this was typed on based on some something you found. I think it was some changes you wanted to end it. I think it was about like reducing cloning but not. It doesn't have anything with it. It's just about reducing cloning. Okay, it was just across the board. Okay, so reduce the cloning, reduce cloning. And those two are basically what I'm like the the reduced cloning and the traits, like the macros replacing macros with traits. I'm going to cover that in the messages. Yeah, so I'm going to just delete these since this technically already is right. Yeah, you can remove the reduced cloning to basically covering that. Then we had the state pattern. Or the other machine so I think this is still intact. Then we had if implementation of issuer side using the credits libraries. This is definitely still outstanding. We have a very fire implemented with credits by George. But yet this is, I don't believe somebody's working on this right now. And it's going to be important, as we want to eventually migrate away from VDR tools dependency. So this is still waiting for us. I'll be bigger task, possibly. Then we had the coupling. Okay, I'm not sure. I'm not entirely sure about this given the state. I'm just not sure how it's going to still fit in or if it makes even sense. This was a duplicate. I don't think it will make that much sense really. Yeah. Essentially, VCS will be an implementation of protocols. Hmm. Yeah, I'll, I'll remove this probably at least for now. And maybe we can close the issue too. I'll see after the meeting what kind of a reasonable command I can write here and close the refactoring. Okay, unify submission approach. This was this is also something what doesn't really apply as we are essentially going to rewrite the state machines with with state pattern and then that's essentially the unifying itself. So I'm as well going to delete this. I don't think it makes sense to invest in some sort of unification of the current approach are using. So I'm deleting this one. And wait, those issue linked there. Okay, I'll close this one too probably. This enable out of band test in the 808 that's what Smirno is working, working on right now. So I'll just link this. This here. Then we had eliminate usage of mediated connection in tests, I think that's still valid. The connection is similar to the V6 also the pre-coded long term, although we still have it and support it. I mean as long as Ios and Java wrapper exists. Mediation connection will exist in the code base probably possibly behind a feature flag, but it's going to be, but the focus should be to start using the simpler version of the implementation. So I'll just made it a bit more specific in favor of collection. DDO is a first class citizen. I think I'll have to look into what I meant by this. I think there was some ideas like I think there was some ideas as to what kind of patterns we should reduce and we should kind of there's places in code where we are passing I think some sort of arguments maybe like various service or some sort of internal abstraction and I believe that DDO should be used instead. So that's why I think I originally written this point, but at current moment I cannot recall the specific places so I'll leave it there and maybe take a look if I can describe this somewhat more specifically and I'll keep it or not. Adding more typing across the code base that relates to like the usage of in some places in code we use string where we know it's actually URL. I think this is still valid and will be partially addressed by the work being done by Bogdan right now but things there's also other places possibly where we deal with URLs and and there's and in general I mean this applies not only to URLs but also there's many places across the code base we use string. We should instead have some sort of DID type. I mean we are not really leveraging Rust typing enough. So as a two example just right here. The DID type will like require work in itself I believe we talked about this. That we need to basically create maybe you can even add this to the list that we need the DID parser and implicitly a DID type because essentially we have to parcel the components of a DID properly to handle them correctly. And the URL doesn't really take care of that because it doesn't recognize the schema with host and it's basically it doesn't parse it correctly but essentially that's what the IDs end up being. They're sort of like the URIs. So yeah we kind of need a parser for that. And I think we can also hear this brings me to DDO resolver which is also not a resolver too. We need to implement the resolver but we do have issue for that so I'll just link it there. Resolver is here. Where is it? There we go. And then yeah implementation of new protocols that's kind of a longer term if we should probably first do the state patterns across the board and only then starts adding actually new protocols. So make sure that everything's nice and clean before adding new features. And yeah that's that's all for the backlog. Do you guys, Jonas, Miroslav, Bogdan, have anything else you think we should add here? Anything comes to your mind? No, not really. Nothing else for me either. All right, okay. So then we came to the end of our page and just blank white space here, which means there's nothing else to cover, I guess. Well, but before we sign out, since this is like admitting this question for anyone, do you guys, anyone have anything else to cover? Or any questions or discussions? All good from your side, Jonas, don't you have any questions or stuff since you guys are like recent adopters, you know, don't you need any like assistance or anything? No, currently not really. So at least from my side, at the moment it's more like a side topic. Maybe it will be a bigger topic in, I guess, April. Yeah, but first it's then it will be more like, yeah, new protocols, that's already the backlog. And maybe also a big thing for us would be to also support ACAPI as a mediator. So like to support the V6 agency and the ACAPI. I see, I see, so that would basically require implement, we can add it here in the backlog actually, like it will be nice, let's say it's nice to have, or like, I'll just put, not nice to have, I'll just put it here. So it's a valid feature in every ecosystem. So ACAPI mediator, I suppose, is speaking the pickup protocol V2. So, you know, you're just a board that will need to implement mediator, mediator, every mediator client pickup protocol V2. So currently we have a Mediation client, but that's specifically for the V6 agency node, which is kind of proprietary protocol implementation. I mean, of course, but it's custom. So this will be somewhat similar, but it will be new client speaking different protocol. So, yeah, that will be cool. And that will be useful for the Uni-FFI wrapper, as the Uni-FFI wrapper itself is not going to be using the V6 agency node anymore. So it will definitely, in order to be useful, it will need to have some sort of Mediation support, ideally, and it will make sense to implement something like that and incorporate it there. Yeah, so it's good. Okay. Very well. So I think that's it. Thank you guys for joining. Good day and pleasant weekend is coming soon. And I'll see you next week. Thank you. Bye-bye. Thank you. Bye-bye.