 Hi, George. Let me just get things ready. I'll be in a minute. Cool. Yeah, I think we can get started. Let me share my screen. There we go. All right, so yeah, welcome to 8 of June, 2023, RSVCX Community Call. This is our anti-trust police notice. By Hyperledger. Okay, and let's dive into our agenda. But before we get there, I would like to actually just think about the agenda, like out loud. I might have missed something. We have a touchdown on the mentorship. We have the usual stuff. And just a second. Yeah, and I think we need to actually add some points there. I saw George that you've created some issue and you also are like messaging me about, you would like to discuss some stuff about ARI's agent as Harness, right? So we can put that on agenda. Cool. Yeah, anyway, it's good, even if it's saved till the end of the meeting, remember? Okay, maybe let's do that. I think perhaps the typical, the chore agenda will be relatively fast, I think. So we can put it here as discussion points. So that would be AATH. And then, and then you had issue about the creator message, link. Okay, and I think for now we are already busy enough. Well, maybe that CLI app idea as well. Oh, yeah, that's right. And CLI, yeah, lots of stuff to cover. Good, good. That's what these meetings are for. So, yeah, let's get started. So the mentorship program, so probably the applicants are already aware. We have chosen the mentees. So if you haven't been contacted by us and by Linux Foundation about being selected, probably you got already other message saying otherwise. Nevertheless, there was really lots of competition. So please don't feel bad and don't get discouraged if you haven't been selected. Just the competition was tough. There was lots of people applying for a lot more than we expected. And it took some time to go through all the applicants. Nevertheless, this is now concluded. So congrats to selected mentees and I hope best of luck to the ones which haven't. But also I want to know that not being selected as a mentee doesn't mean you can't work with us and join these goals and contribute. It's an open source and anyone can make a dent and contribution. So yeah, heads up and cheers. Let's get to the chore portion of the agenda. So basically we had a bunch of PRs in relation to DDO. Oh, and actually I just noticed that we have two additional members on today, actually three on today's call. So welcome. We'll have a space for some free discussion at the end if you would like to. But maybe I would, if you don't mind me, you can kind of give an update on what's actually happening with the integration like you started working on and what kind of PRs that led you to make if you'd like to comment on it. Sure, I can pretend that my memory was beyond one week. So we, I have tried to integrate the new DDO-created crates into every CCX and run into multiple issues. One of them was, for example, that the current did parser rejects an A in unqualified dates. So we should type dates whenever we use them. Currently we are using strings and we should distinguish qualified and unqualified dates based on context we might want or based on context the dates, their method can be either inferred or not. So in cases where it can't, the dates should be qualified and we are throughout the code base currently using unqualified dates. Another issue is that the did doc create is based heavily on the actual latest did core spec and for example, the services fields which or the service format that is used in connection currently is type which is not part of the did so code of spec for example. So it's not entirely compliant to the specs. And this means that except for like using this in the agent type, it also as you mentioned, I think the public key field is not a valid did doc field. So there are like multiple discrepancies between the format that we use currently in connection protocol and in the new implementation which means that it would be very, oh, I'm saying that there are like multiple hurdles. Another thing is that another thing is that for example, the current did doc doesn't implement just the referencing of key references but the current implementation does. And this is kind of basic functionality that you should support. It's used quite widely. And yeah, I think that's mostly right. And then basically you created this 864 PR and kind of found and actually richly described all these issues in the PR description. And then still we couldn't merge it because of some issues but some of the useful stuff could have been cherry picked and that's pretty much what we did here in this variety of smaller PRs related to did doc. Yeah, that was just some minor improvements that I had to make when I was doing the integration. So I guess once we actually go ahead with the integration having these things on the table and then we'll make things easier. But yeah, I'll just add here now additionally to what Miros said that basically we also found that other implementations like AFJ or ACAPI they also, they support this kind of legacy aspects like the public key which is not included in did core but they do support this legacy format for a connection protocol. And that's the protocol, connection protocol implement currently. And so it doesn't probably is worth the effort trying to upgrade our existing connection protocol implementation to use the new did doc create which is W3C compliant but rather just kind of leave it as is the connection protocol and then go ahead and rather implement the exchange protocol which supersedes connection protocol and use the new did doc create which is W3C compliant there. But yeah, I guess it would be handy if before that we also implement this missing feature in the doc create the referencing of keys which is generally used and we support it right now in our legacy the doc implementation. So we would like to preserve that capability going forward with the exchanges as well. Yeah, I think it could be like we can adjust the new implementation to remain fully backwards compatible but might be kind of unnecessary work perhaps. Hmm, right. Yeah, so we'll see but I guess and we wouldn't want to invest heavily on connection protocol some sort of like improvements or investigations since the exchange is kind of like obvious descendant and I think that's actually pretty much all the implementation these days they already support the exchange. So let's just rather roll forward. Yeah, so these are like some improvements PR those are all merged, I think at this point. Then there was this additional PR about the new implementation about refactoring of profile abstraction we had and just sign minor technicality but connecting to that one of the tasks which is in progress right now is actually removing this profile abstraction from Aries VCX main code base and especially using it in like method signatures as arguments. So just a recap for listeners and those who might not be familiar a profile in Aries VCX code base was kind of a basket of objects having certain APIs the lower level APIs. So for example, there was APIs to read data from the ledger write data to the ledger to work with credentials to like create them, store them and whatnot. And yeah, stuff like this. And so that's kind of what we're trying to do and this basically forces I'll jump into the relevant PR, this is this one. This is like a bunch of disadvantages as we're passing these profiles across Aries VCX functions basically sometimes the function needed a one component of the entire profile but because the function required the whole profile you kinda had to construct everything that the profile required you to contain whereas in fact, the relevant function really just required a small component. So you ended up passing a bunch of references to objects, which would never be really used down the road. And this PR is now in progress. It's mostly, I think it's close to completion although I have failing tests here. Did you find there were many methods that got like super ugly with the amount of injections that it needs or are they also relatively small with what's required to be injected? I think it's not terrible. I think like usually it's what, yeah, usually there's not so many functions in Aries VCX which really require all components. Usually typically it requires like unencreds and maybe reading the ledger or writing the ledger or some combination, but usually it's not more than two components those Aries VCX function require. I know we can just browse through some random examples here. Yeah, often times, for example, here was a profile but actually you only needed the wallet from it or I don't know, is there some bigger one? So here's an example of a bigger one. This was for sending credential requests, I suppose required profile, now it's two components from it's the unencreds and the ledger read but actually as we kind of touched like mentioned before we still want to actually break down these unencreds like into smaller components by role. So I imagine that in the future it's gonna be like inject unencreds ledger read and then inject unencreds holder or something like that. So it will be even more kind of compartmentalized divided into more components. Awesome, yeah, that's good. Yeah. And so that was in the Aries VCX agent we were just looking at. So I guess the agent and tests will keep using profiles for convenience but that's just sort of for the convenience of the agent and for tests. Yeah, yeah, so just to quickly show that change remove profiles. Basically, if I do search in Aries VCX for a DIN profile as a trade object we used to have it's only in the Dev setup. Oh, yes. But it's still used in like agents, it's widely used here. Also for the tests in Aries VCX, so if I look here there's profiles here and there's only a few occurrences here because that's just declaration of the trade object but they have many uses right now. I mean, there's profiles are used all across the place. Yeah. So I guess I would keep the pro I was thinking of picking out the profiles into separate trade but I guess they can just sit in Aries VCX for now as a kind of a side component, a useful convenient helper tool for other projects integrating. Yeah, I guess it's helpful for projects where they know that they want everything, right? They want all the components of a profile. Otherwise you better. Yeah, exactly. Or actually what I found like since we were talking about this one more thing I have in progress. The reason why I even started what we like doing this is that I wanted to use the modular lips profile in the VCX and VCX Node.js wrapper. The problem is that the modular lips profile and the existing currently used in the VDR, VDR tools profile, their constructions are quite different because you cannot really build the VDR tools profile incrementally. Like it's either you build, you either initialize wallet and pull advance or nothing. But that doesn't really place like so well with the Node.js wrapper and just like they have this different approach. So it's like I wanted to have like more control over how we manage memory and global state in the like the VCX portion of the code. But because every VCX itself forced me to use profiles which are somewhat opinionated. It was like difficult to modify, you know and even just to think about it. So this was kind of preliminary work to like remove that dependency on profiles from various VCX. And then I would like to actually tweak the profiles or maybe create new kind of a profile trait which would enable kind of incremental building. So you could initialize wallet first then additionally you could initialize, you know pull, unencrant and whatever you need but to kind of give them more control about the order of the initialization. Yeah, yeah, cool. Awesome. Makes sense. Okay, I'll just leave a note here. So this is like soon for review and then we have like just kind of thinking we'll continue with incremental profiles, I guess. Incremental profile in a... Yeah, right. Upcoming work, I'll put it here. And also as we already touched on while reviewing the diddog integration, we would like to implement a didexchange protocol and we would like to implement a didexchange protocol so we could actually integrate the new diddog trade and make it all in nice and W3C compliant and everything. And also obviously since we are gonna be building these we want to do it the right way as we previously discussed and agreed on some like state machine implementation guidelines. It should be without IO and it should follow some like rules to make sure that it's like well testable and provides nice APIs. So yeah, this will be like work for like upcoming kind of we go to maybe more, I think. I mean, implementing new protocol that can be all the work especially with a new approach. And yeah, just going on the next section well, let me stop by here for a second. Anything else you guys think that should be like put here maybe in relation also with this stuff? I guess this could be actually the right time to discuss some of these points. You know, the priority of the message handling issue the CLI, the ATH, what do you think George? Yeah, sure, if you don't mind I can give an update on some of those. Yeah, yeah, yeah. Yeah, so my question around the ARIES agent test harness came up after I was playing with VCX version 0.55 against Acropy version 0.8.1 which is I think the latest stable version of Acropy. And yeah, I just sort of found a couple small bugs with message related handling things. And I was thinking that's the kind of thing that AATH would pick up on. And so yeah, I guess I was wondering if you could share some information around what ARIES VCX's approach to AATH is and what that means and what's really tested by it. Right, right. Okay, yeah, sure. We can do that. I'm just thinking about the ordering here and where to fit this in. I think there's actually not really a need for discussion for this one, it's kind of stays as is in conjunction with the upcoming work. And yeah, we can just kind of hop in here for the AATH point now. So yeah, back to your question. Yeah, we have the AATH suits. We have the, how do you call it, back channel implemented on top of ARIES VCX agent the REST agent. And it's running against ACAPI and AFJ ACAPI, AFJ and itself in like pretty much all of the combinations. Not all, I think there are some suits which are disabled for some reasons. Some reasons and I think some features are just not implemented or in some cases maybe the counterparty was not fully implemented or there was some something like that. But I think the main, perhaps the reason why this was not catched as a message handling issue created, it was credential offer, right. I'm thinking that we actually have an updated our haven't synced up AATH with the main version for a while now. And I'm not sure the version is running. I think it was before the messages update and we did an update AATH since then. So that would be definitely something that we should put on actually our backlog. And it's quite high priority, I would say. Mira, I see you are muted. Yeah, it was last updated before we implemented the new connection. So about I think four, four, five months ago. It's using quite prehistoric version. Yeah, we should update it. Yeah, I don't know, George. This is actually like the part of a project like we strive to keep up a little bit. It's cumbersome to set up. But it is important, so we'll do it. But I just wanted to say if you would have like capacity to try to kind of get into this AATH profiles and maybe make some contribution there, like they'll be like super, super appreciated because we are, yeah, as you see, four months later, we are kind of struggling to keep up with these updates. I guess it's not always, it's not necessarily difficult. Like once you kind of have the infra and knowledge how to set it up, but from our team Miro is kind of expert on this one is all of HTA testing was pretty much done by mostly by Miro. So yeah, we'll have to put this on the backlog and I'm actually gonna put it here. Yeah, no worries. I can try to learn a bit about it. I have no idea how it works really. But I like the AATH, you know, I guess if we get it working smoothly and frequently, what do you think the right interval for running it would be? Do you think it may be? Also this is actually sorted out by the guys who develop AATH. They are running it, I don't know, every day or like really, really frequently. So you get feedback all the time whenever, you know, somebody in front of you, whenever, you know, somebody increments their version of the framework or we upgrade, technically we can like, you know, really immediate results with everyone or all our supported pairs. It's just a matter of really like updating the back channel to use the, you know, newer version and then seeing how it goes out and, you know, probably addressing any issues that arise from there. Okay, cool, cool, cool. And the back channel points at the VCX agent crate, right? So, yeah. So it's like Aries VC, let me open up the repo. Basically the way it's like layered is like Aries VCX, right? Then on top of Aries VCX, there's the Aries VCX agent, which handles persistence and just kind of, yeah, like the instantiation of the library creates kind of like this service abstractions and it's all using profiles. And then on top of this project, on top of the Aries VCX agent, there's the harness and that's directly underneath the ATH. So if I go to about Aries, we have a back channel here, Aries back channels and there's Aries VCX. And yeah, and this is like a layer on top of the agent. So this kind of is adding all the specifics, end points, the HTTP end points, which must be implemented for the ATH, maybe. Wow, cool. Yeah, awesome. Mira will be way more knowledgeable about like how this works and what kind of tests there are in like, in the suit and what we are supporting and whatnot. And also, I think, like, if you try to set it up, I think Mira will be like, able to perhaps unblock you if you run into some issues because I'm really not vulvers in this yet, but Mira was doing lots of work here. Okay, awesome. Thanks for the info. Yeah. All right, so we should update, I mean, at least to update version, I think in sync of the code changes, it shouldn't be that much effort to get it compiled. The question is, yeah, if we run into some, if we like get the drop in our test suits, a number of passing test suits, maybe we'll have to address some issues, that's what should be done either way. And then we can avoid running into like stuff like this, which you discovered the hard way. Yeah, there was another one. I discovered as well, where during connection protocol, if you're the invitee and you send to acupy request payload using the new connection type state pattern, the did doc that you attach in your request has a public key, control the field, that's just an empty string. And then that empty string causes some validation on acupy's end to fail, and then it ignores your message so you can't form a connection with acupy. Oh, okay. And yeah, I think I sent a message about that wondering if you guys had experienced that, but if you are unaware of that, then I'll make an issue for it. Yeah, I think it'll be good. Yeah, maybe should please. So we track it. Yeah, and then we have like two more points. Well, one more point, I guess, message handling and the CLI. Yeah, so the CLI, you also created issues for that, right? Kind of like idea for a project. A CLI demo. Maybe you can for all the other listeners who, you know, didn't read through it and are either listening on YouTube or listening here, you can kind of conclude the idea and also if you had a chance to react to my suggestions here. Yes, yeah, I've had a read of that. Yeah, so essentially this issue is just proposing the idea that we make some CLI application which demonstrates how areas VCX is meant to be used in the holder issue or prove a verifier roles. And so I guess this pattern of creating a Alice and Faber demo is a somewhat common pattern in the area's ecosystem. So acupy has one where you're running to acupy instances, I believe where one is Alice and the other is Faber. And they're talking to each other. AFJ or checked as an example as well of how two agents can talk to each other. And I think as well in areas VCX in the Java wrapper, there is actually a demo of two Java applications, Alice and Faber who basically drive the CLI to talk to each other. But I think that example is a bit old now. Are you aware of that? I wasn't aware that there is a demo for Java, but there is a demo for Node.js which we kind of maintain still. It's even part of CI to run the demo. And also we actually have like a CLI built with Node.js. But I would much more prefer a Rust-based CLI and demo because consuming areas VCX through Node.js is a rather specific way of using it. And having a native would be definitely easier to maintain and also keep the quality high. Yeah. So when I first found out about areas VCX, I think that Java demo was one of the first things I found somehow. And just seeing those two files and seeing what APIs are meant to get called in what order, I think it is really helpful for new consumers to know what they're meant to be calling on. Even if it's just a really simple application. And yeah, that Java application, it's just printing out some lines saying, here's what's happening. And sometimes it'll take in a standard input for when you have to paste an invitation, for example, and things like that. But it's all super simple. So yeah, I guess I was proposing if we should make some demo like that of two different CLI applications is the most common pattern I've seen. So yeah, two different CLI applications that talk to each other and their implementation is just simply using the areas VCX create directly rather than any wrappers. Yeah, so we kind of started basically this work. So what do you think about my suggestions to summarize maybe my points? Basically is that we kind of had the CLI and we just didn't drive it to completion and then we somewhat like gave up on it like we'll finish this later. We'll do this later. Let's not add kind of like additional maintenance burden right now. But yeah, I mean for this, but at the same time like I imagine, as you said, from your own experience like having like Alice Faber kind of demo like which is easy to run. It really can make people much more like it make it much easier to understand like what's going on. But so if we're going to do it in Rust and it's going to be like CLI based that you have to like copy paste those invitation. I kind of do a little bit of manual interaction to really actually understand what's going on. Then then we should have like good CLI CLI baseline. So that makes me think we should actually like reopen the 692 and make it like our baseline for the Alice Faber demo. And then the Alice in favor, I believe they should essentially be running the same executable, maybe just with like different like some different configuration or something, but I mean after all it just agents, right? It just agents talking to each other, one issuing credential to the other. So try kind of try to maybe create some sort of Alice Faber scripts or executables on top of that, like shared CL general like general every CLI. And also, I mean, it will be great, not only for onboarding, but also I think for testing kind of like maybe like manual testing or testing some specific edge cases which you don't want to necessarily script, right? But you want to use areas like one party in the conversation and try some like custom workflows then having a CLI could be valuable there. Yeah, I do have an alternative opinion. So let me know what you think. But yeah, I think if we were to build it on top of the CLI, CLI work that was getting done, I do sort of worry about the complexity of it. I guess I was sort of imagining, you know, two files Alice.rs, Faber.rs to keep it simple, where it's all in one file and you can see exactly what areas VCX APIs are being called rather than having to drill down into some CLI implementation. That CLI implementation seems more like a full fledged project of its own with potential like production value. And same case for using the areas VCX agent code, I think that would sort of hide away the areas VCX calls that we're trying to show off to consumers. I guess I'm imagining the demo is trying to show off areas VCX directly rather than show off the areas VCX CLI tool and the areas VCX agent tools that we've made. Right. If you get what I mean. Yeah, I get it. And I think it actually convinced me really easily. And there will be also a lot less effort like, yeah, okay, two files and it wouldn't be like maybe I guess as general as like I envision, but yeah, I mean, it would definitely make better job at demonstrating the code usage. Code usage. It'll be, I probably, I feel like it'll be, it'll be very similar to the like end to end test integration tests we have, but it will be different in a sense that it will be split in two files. You kind of have to run them both. You might be a little bit interactive if we ask the user to copy paste like invitation from one window to another. Yeah, I can imagine that. Yeah. And it will be, it'll be, I guess for this kind of demo, like if we were to build this Alice favor demo on top of CLI, then it will make sense to like invest lots of effort into like making the CLI actually good and make sure that it's like kind of production and great quality, then we don't have to refactor it out later again. But this kind of demo is, you can kind of just glue it up together and it's two files. You just update to get it, get it compiled. It doesn't have to be beautiful code, but it should be like this kind of explanatory code. I guess. Yeah. Yeah. I think that's my opinion of it as well. In my opinion should just be something where it's two small files or so where all of the, the fat of, you know, testing setups and, and everything else is cut out. And it's just pretty much only Aries VCX API calls directly, you know, straight onto the handler type state patterns and one run. And then that could be maybe referenced from the Aries VCX read me as a, as an example of how to use it. I think it could be like, well, depending on the urgency, although I feel like it's not urgent, it could be actually like good first issue maybe for someone to implement it. It would be challenging issue, but it will be extremely educative for whoever would pick it up because they would actually have to use all of the API is pretty much an initialized library and, and kind of go through the entire workflow. But I don't know, we can maybe keep it, keep it open for a while. At the same time, I feel like it'll be the way I could describe it. And I would pretty much like now agree to not make it too robust. It shouldn't be too big effort to get it implemented for like some, for somebody who's familiar with Aries VCX, I guess. Yeah, yeah, exactly. And I think, you know, maybe even that Java demo, or even the node demo, which, which I haven't seen could be used as a reference, how to implement this one. Any other opinions from the, from the participants? Or thoughts? I agree if it's, if the goal is to show off Aries VCX, the usage of Aries VCX, and just simple, like, simple demo would show, but if the goal is to basically test any, any scenario, any agent behavior, then more generic CLI would be useful. So it depends what the goal is, but I think it's entirely a valid goal to show off Aries VCX. Yeah, I had originally, when I was reading the issue, basically, I was thinking like, like, oh, somebody wants to like see the, understand the code usage, they can take a look at tests. But yeah, I see that. I said, now I see the value of like having Alice and Faber and running in the files, it's kind of a, kind of more, gives more satisfaction to see it running as a scenario and you run the scripts written in just running cargo test and you have like a bunch of OK, OK, OK, like a test passing. Yeah. So yeah, let's, let's do it. Let's create issue, we can make it a good first issue, give it a few days, if nobody picks it up, then we can just implement it. Well, yeah, I did that ticket to make it more clear what the intention is around what we just talked about. So I'll put it here, Alice and Faber CLI demo demonstration. And yeah, OK, this is checked, we mentioned, we covered. I think that's it. For our agenda. Before we like sign off completely as I didn't mean to let we have a, I see we have a Agnes and mysterious anonymous adult. Participant on the call. If you would like to feel free to like introduce yourself. If you would like to stay kind of anonymous and like just just be audience, that's fine too. So if you would like to introduce yourself. You can go ahead now. If not, that's all right too. All right, hi everyone. My name is Agnes. I just joined the mentorship program. I have no idea what's been going in the call, but Barbara asked us to just join some different project calls and try to figure out what the documentation needs might be. So my internet connection is a bit weak today. So Barbara asked us to just find out what the different projects might need in terms of documentation. So I chose I is because I'm more conversant with Python. So yeah, so I'm still just checking all the projects so that we go back and check what projects may be working with. I'm from Nairobi, Kenya. Yeah. Okay. And what, what, what project are you meant for? Oh, I'm, I'm into that documentation. We haven't chosen the projects yet. That's what we are supposed to do this week. Is it the AATH? We haven't chosen the projects yet. We're just generally doing documentation. We haven't been assigned the thing yet. So you asked to go and find just different projects and figure out what you might be interested in. Okay, I see, I see. If you would like to like connect and like, you know, if you have any questions inquiries about our areas we see implementation, then we have a, we have a Discord channel. So feel free to drop a question or reach out via direct message or Discord as well. All right, thank you. All right. Well, I guess that concludes that concludes it. And this was, we almost use entire time. George, do you have any, George or Miro, do you have any final remarks or points you would like to? Yeah, sorry, I just have one question about that a non-credits priority. So if there, if there is a tool provided that helps people migrate from VDR tools to the credits, wallet data, the non-credits wallet data, do you think we're then going to need more migration for credits to the non-credits RS implementation? If you know what I mean. Yeah, I'm not, I don't know how different, what kind of differences and challenges that that transition is going to bring. So I guess it's kind of hard to tell, but I imagine that there might be some sort of migration too. I'm not sure. Right. But I guess an alternative option would be if we move to a non-credits RS before the migration scripts are written. So then there's only one migration needed, which would be VDR tools to a non-credits RS. Yeah, technically, that's, yeah, that's also option. Actually, so we have a Bogdan author right now and he was, he started working on a migration tool. I don't think you get, you go down into like specifics. So probably the work you've done would be still like reusable. It's pretty, it looked pretty like a generic, but yeah, I would like to actually do like some further testing like from our side on the, on the credits implementation. That's why I'm doing all the stuff around the profiles and trying to integrate the module leaps profile into the VCX and V6 and PRS. And then once we have that like working and compare them actually, yeah, it would, it would make sense to actually like postpone the migration script and just, just finalize the, the VDR tools to a non-credits kind of migration first. That would be the only one, right? Yeah, yeah, just something to think about. Yeah, I'm sure Bogdan has thought about this and has opinions on it as well. Yeah, I'll definitely put here as a note. So considering prioritizing, try, try. It's difficult to write when my being was publicly on the call. I feel nervous, cannot type even the basic words now. Prioritization, that's, it's wrong, is it? Prioritize, migration, integration, all on credits, RS, prior to credits, migration. All right, we'll, we'll think about this, but I think it makes sense actually, yeah, why, why to make ourselves extra work with two migrations when if we can only do, if we only can find a way to only do one. Right. Okay, guys. Anything else? Well, it was exactly one hour and, and I think there's nothing else. So thank you all for joining in here. We have the RSVCX channel, you can reach out, reach us out there as well. Thank you for, for being here and have a great week. You too. Thanks guys. Bye.