 How are you? Very good. How are you doing? Good. Let's see if I can take host here. Can I give you host? No, I'm not host. I'm also guest. Let's see here. Usually I can click more. Alex, how are you? Good. Good. Good. I'm still trying to figure out that it come React Native Library. Maybe we can try to do some building today. Hey guys. Hi. Cool. Hey, Judith. Hello. Usually I can go to participants, click on my own name and take... Oh, here we go, claim host. They've just changed it a little bit. That's all. Sweet. I think I'm host now. Unlimited power. Okay. And it looks like we're already recording. So that's great too. Hey, Roto. Lance. Hi there. Good. Good to see you. Okay. Judith, do you... So last meeting we had Hakan and Alex and Roto and myself. Yeah. I think you want to introduce yourself and maybe let us... Yeah, go ahead. Yeah, I'm writing my master thesis in the area of software identity and the ideas to implement it can be too for ACAPI. And Hakan is actually my supervisor. Oh, good. Great. Awesome. Yeah, great to have you. Are you on Discord with us? Yes, I'm also on the Discord channel. Okay. Let me... Do I know your Discord handle? Do you know what it is? Maybe I've seen you on there or have you posted there? And not yet. Okay. Yeah, no worries. No worries. Baron, how are you? I called him out. No worries. Maybe he's not ready. Or he just muted. Trying. Okay. No worries. Take your time. Cool. Okay. And let's see. I'll bring up our page as well for today. And hold on. Let me publish it so I can post the link to you guys. Okay. Got that. That's our link for today. And I can share my screen. Sure. Okay. Don't judge all my tabs. Probably should have closed those before this, but that's all right. Okay. So feel also welcome to the Aries did conv2 working group for November 28, the 2022. Happy to see everybody here. We are now on zoom. So you guys have made it here. I guess I'll double check. Make sure no one's asking. Because we met on Google meet last time just because I didn't know if they were going to get everything set up, but they did Aries is great. Great community. Please feel free to add yourself to the attendees list for today if you like. We just have to remember the antitrust policy for hyper ledger. Also the code of conduct for hyper ledger, which maybe I don't have a link to, but you should be able to find it on confluence. And maybe I'll link to it on our future meetings. And essentially, yeah, this group. This is our second meeting. I think our second meeting, maybe third. And our goal is to see did conv2 adoption within Aries accelerating. So for some that is a focus on did conv1 transitioning to did conv2 and then for others that is just adding a did come implementation to their areas agent or let's say a mediator or Yeah, some component within the Aries ecosystem. So we think if did conv2 can be successful here. Then, you know, it can be successful out outside of here, you know, roots ID, which I'm associated with for instance has customers outside of Aries that are very interested in did conv2. But then they're also very aware of Aries and they want to interrupt with Aries agents. So if we can all get did conv2 going within the Aries ecosystem then we think adoption outside will will be rapid and well satisfying for us. So let's go through any. Well, welcomes. So Judith introduced herself that's great. Baron, most of us already know if he wants to say anything go for Baron but no pressure. Oh, yeah, yeah, it works. Awesome. So I'm a bit and I mainly work on a J as a maintainer, and I've also been working on my own did conv2 library in your typescript. So that's also basically why I joined because I thought maybe there were some questions or something that I can help with. Yeah, that's great. Where are you joining from by the way parents from which country which continent. And the most solutions continent Europe country cool. Yeah, very good. Yeah, Baron to right he has his implementation that he's been building up in typescript I think Alex from roots ID is also looking at that. But you can correct me if I'm wrong Alex. Yeah, I am and I do have a couple questions actually I was trying to implement it on our wallet and some of the imports with the native libraries were failing. So, yeah, but yeah I've been playing around with your library as well as the sick body. So, yeah, thank you for coming. Yeah, that's super exciting. So yeah we'll cover that for sure today let me put that on our discussion topics. Yeah, type script. Talk about that. Okay, and I also see snore on the on the call. If you want to say anything snore, you know go for it. He's, if I can do a quick introduction just from my point of view him and Alex did a bunch of work on the JFF challenge, leading up to IW which we all just attended or a bunch of us just attended. That was really cool and I've gotten to sit in some of the meetings with with them and just see them working through some of the interop issues for did come be to and that's been really useful. Just watching, you know, separate teams, basically all the collaboration that they have to do. Admittedly, it's more than maybe we'd like, you know, a team to have to do but, you know, these are the growing pains of this and so, in a lot of ways, their efforts have been in the creation of this group and this meeting. So that we can kind of capture some of these elements to help people to be able to navigate the did come be to implementations and some of the pain points and, you know, finding the quickest path basically. So that's good stuff you want to say anything snore. I think you covered most of it. But yeah, I'm from the wall. We're using did come be to self made. So we had to adopt sigma library for primarily encryption decryption. And yeah, that's where we are. So I just wanted to jump in and see what's going on over here. That's, that's great. I'm just trying to pull up our spreadsheet that I've been doing that's a bit of a did come. Yeah, areas did come v2 support. Yeah, go ahead. Edwin quick question. You are not using an areas framework but you are using did come if I understood you correctly in your software solution. That's true. Okay, cool. No, that's that's also super interesting. So yeah, it's going to be an interesting conversation to see how we can connect these two words because this was one of the topics that we were talking about last week. Due to the fact that areas as a framework is all using connections as a concept. And there came the question or like, yeah, a question mark basically how we can make sure that we can create like areas. Sorry, did come v2 communication relationship whatever you want to call it with an areas agent and a non areas based software. Yeah, awesome. That's, we're not done with the JFF yet but that's where we do see we had to break off very early. The three people who did not use areas. Or the people who did use areas did not were not comfortable enough in trying to adjust what's needed to adjust it to meet. Meet each other. So we had to kind of separate each other between two groups. So yeah, it's, it's a tricky one. Yeah. Yeah, great. So, to just kind of show how I'm trying to connect some of these dots. If I go to the references section here. I put the JFF did come v2 notes in here and if I bring those up. Hopefully you guys are okay with me sharing this with the group. It's just really interesting to kind of walk through the kind of questions and the information that's been captured here in terms of what parts of did come are important you know where where where do we find conflicts or difficulty. Things like that so I thought this document was really helpful. I guess I should be. Yeah, posting posting links to these things. Let me do let me do my job. Let's see here. My interface has changed because I'm sharing and so then I go back to the chat. Yep. Here we go. So this is the survey document which has a link to the JFF in the references section. And yeah, so the point is, okay, I captured this as a reference that we can look at. There's tab for crypto for some of the crypto that we've seen supported within the did come implementations obviously crypto is something that. Well, it can be it can be an issue. Also, capturing the different protocols. I haven't put much in here yet. But point being, you know, on did come.org you can go see a bunch of the protocols for did come v2 areas agent test harness I'd like to talk about a bit today. If we have time. That's something that I've been going through and looking at in terms of being able to demonstrate support across the agents. We have did methods on here. Obviously if you don't, if your agent for instance doesn't support did peer, well, you know, if someone's expecting to make a did peer connection with you, and that's going to be an issue. So, this, this survey, if we'll call it that is super young. Right. So it can change in any way. I appreciate any suggestions. I would say maybe this tab is one of the most important right now, which is the implementations tab. Obviously, Sikpa has donated a bunch of open source implementations. And so some of the, I guess, more success that we've seen between agents is when they use the same implementation of did come right so if they both are using Sikpa. Maybe it's a little easier. And so yeah, that's obviously intuitive. But the goal is for, you know, implementations. And maybe at some point have like a test harness that allows implementations to connect and figure out if how they interrupt with with the other implementations. So I listed Barron's did com type script here with animal and he had posted that to get so we have that GitHub link now. And then occupy has its internal work that that Hakan and Judith have been doing. And it looked to me that that's related to ask our and. Yeah, so I've linked to that as well. So. Any. So that the veramo and the Brian from the Alviari implementations. Yeah, I'm finding for that. Okay. Maybe I will not put it on there yet. Let's put it. Here. Let me change this to. Yeah. Look over and document. Document Baramo. It can be too simple. And then maybe this is a good time to talk about the type script. We'll call it the animal. Baron, do you want it to be the animal type script and pull or the Baron. It's in your repository, right? Yeah, I don't do the work under animals just my, my own projects you can just call it. It's fine. There we go. Okay. Yeah. Maybe Alex is a good time to ask some of the questions that you have for that. For the implementation like the implementation from animal. Yep. Yeah. Well, Barron's. Yeah, he's he works for animal, but he's doing the work under his own repository. So. Yeah, I mean, I'm trying to reproduce the error right now. So give me a second because it's like a dependency issue. Okay. On our end. Yeah, no rush. Let's let's do updates on the, since we have Judith and Hakan, let's do some status updates. For the occupy work. Yep. Okay. You guys want to give us any updates on. Just what you're doing and yeah, what's in from the implementation side. And yeah, maybe I can start because I already did that request for some work that we did together with a group of university students. And was basically changing or like making a new folder B3 for the message structure of B2 of that can be too. Okay. So, what now has not been done yet is actually to adapt the encryption because right now it's not sure where it gets the information from which type of encryption should be used. And that's also connected to the problem of how the connection should be implemented because if you know from the beginning which connection is implemented or if it's for example, if we also should update the version of out of band protocol for B2, then it would be known that okay, we're using that can be too now and then we can also adapt the encryption to it can be too and then use like the message factor that can be too. So what has been done so far is just adapting the master structure or like enabling the message structure for it can be too. But the missing is encryption and probably it's already implemented inside the escalate. So the encryption so it just has to be used at some point so just at some point it has to say okay pack the the envelope in with this encryption type, but the necessary information must come from somewhere and this is probably would be the easiest way to have a connection for it can be too. And then knowing from like which type of encryption should be used for the further communication also. Yeah, a little bit about the kind of connection. Yeah, it, how can from last week. Yeah, we were talking about like a v1 connection with v2. Is there anything come of that, you know, over the last week. So let's make a bit of progress there and I can add a couple of things. So first I shared the pull request right now on the chat and the chat so you can put it here officially as well if you want. One area that I was looking into was basically to understand like, okay, so we have the connection connection IDs connection protocols. So the first change we have out of band and actually occurred to me that all these problems that occurred to me basically with the connection has been actually talked about in the areas in top of the profile 2.0. And in a way that we are actually phasing out of the connection protocol so it's not a part of the IP 2.0. We are using two protocols, one of them being the did exchange protocol. So if we know the public did, if there's a public did the did exchange protocol helps to just establish a connection between two parties. And if it's supposed to be like a broadcast kind of information again where the public that is not known in that case, the inviter basically can post a out of band message using the out of band protocol 2.0. And the way it seems like to me is that in order to, so we will continue using the connection ID as a concept because it's been used in every framework that I've taken a look into I assume it's the same in the JavaScript framework. So that net is using them. Python is using them. Go is using them. And what what did exchange is already there as well. And out of band is already there as well. So I think what we will just need is to fix the message structures and create additional end points either to the existing. Yeah, API cluster so to speak or create like the 2.0 versions of them. But yeah, I think this is more about the question, maybe to the ACA pack group as well because it's really more in the internal area for how how Python implementation should happen. But yeah, I mean if this was also like a question for you guys like I think it's. Yeah, it's it's been already thought about what are my next points or like not problems with the same questions that actually occur to me is basically I think we will need a new into a probability profile for areas. So we have a IP 1.0 which was about in the IP 2.0, which was in the direction of this conv2 but it's not completely right and I think we will need another into a probability profile revolving around the did conv2, which is missing right now. It's not there. I think there was Vaki as an idea this wallet and what's it called again. Vaki. Yeah, Vaki packs. Exactly. Yeah, that's stuff but it is out of hyper ledger I think it's it's not a part of the hyper ledger it is the essential as identity foundation. No problem but we might still need an interoperability profile for areas basically to so that we can actually get along with the areas implementations first of all using this conv2. But also include things that will help us to be able to create relationship with the software that are using this conv2 but not using areas framework, like what Edwin was implementing. Yeah, so basically the first issue you're going to stumble upon is potentially message protocols. I can share a link here which is open. We had a lot of discussions on this little repo right here. I posted now where we started with trying first and foremost trying to figure out what are the messages going back and forth, because the only way we now see it that this software will talk to each other is that you basically have a way to tackle multiple messages. So is it how is your flow you can look at that last the first one there. I mean, then how number seven or number two sorry. Oh, here. Gotcha. So you see that we had an flow that was almost similar to what wacky has proposed, but also Brian and everyone else if you scroll further down. I have the wacky flow message and if we what we figured out is that since the areas people came in and was not able to change up their messages, we basically had to land on more profile reviews. And we decided to then split the groups into a group that can support this message flow. And then that's where the first four happened, basically. So the question is then what is issuance of credential in did come into our areas like it, this is, it happens quite fast before you see that things are not starting to collaborate unless both software support both mess expected structures. Yeah. So what do we want people to do do want them to say hey implement all these messages they mean the same more. Do we need to find basically say hey guys, a really good profile is the wacky one, because the next step of this journey was okay now we need to deliver the detail what's inside each message, then we saw that hey, Brian suggestions he had too much. Do we want to use presentation exchange. That was like the first hinder because then you need to do that. And if you don't, but you can basically probably identify what's what this particular protocol will use of data attributes inside of it, like will I use presentation exchange message or what will I use doesn't matter but I think that there are these protocols are the first hinder that has to be clarified to be making sure that it's not necessarily and that's probably where it did come up or comes in. But yeah, just quick question, aren't the message structures of the messages which which messages are to be sent specified in the protocols themselves like issue credential or present proof protocol for instance. That's a good question maybe, but if it is then wacky is not necessary anymore I believe wacky also specifies a lot what's inside of its messages. Oh yeah, this is connected to Vaki so. Right. Yeah, well what is issue credential v3 and present proof v3. So, yeah that that was because I think the messages that are supposed to be supported are written here. Well, I think three of them are required and one of them is optional the one that is for negotiating. Yeah, then then the question comes against it when like, is this. Yeah, it would it would it still be a problem in terms of what needs to be implemented if it's like already in the spec inside. And no not really but then it's just then it comes down to how willing is everyone wanting to implement all different versions and the different actions that's going to happen when a certain message comes in. And if you're able to packet that inside some simple libraries that basically consume some action helpers then you have kind of extracted that at least for the next developer in line. But yeah, I'm not sure how to solve it it just it's quite big when we started to discuss. So, first of all, you just need to decide on what profile to use that name might be easier. But we kind of, we crashed there at the first meeting so we had to fork to groups. Okay. Interesting. We said that the walkie-packs or if you credential version three and present through version three is a nice target so we can all align to that right and that that would be a nice goal because it's kind of similar to version two. And it's actually the same right the same flow on the body on the format of the messages the only difference how you put everything inside the body right. So, maybe as a next work item, I could maybe make sure that take a look into which protocols are needs necessary for the did conv2 profile, because we will need to create a new internal profile. I don't see any other way around like whether call it vacuum profile or not it doesn't matter we will need to specify the protocols that areas is supposed to support, basically. We've been talking last time in the user group of diff is a group of did come. It was also the guys from the drama. So we are looking to have, I think what he packs should be one. Well, just the, the goal, but also we are thinking of having like a nation that start with like a regular trust being protocol to check that the trust being is working and provide, provide that all the envelopes and encryption is working. So trust being should be one of those protocols that have to be on the on the profile. What he picks for me is just the, the goal, yeah, the main the initial goal. Excuse my ignorance just a little bit. But I feel like this is important to cover so the in the did come current did come spec we have these defined profiles. So how can it's basically saying, well, the probably occupy is up to this, possibly this point with did come a IP to envelope RFC 587 it probably has both of these right. Yeah, but we're still using RFC 19 mostly. So that would be the productive state. There are several RFCs tied to these profiles, but I'm fuzzy on what it will mean for this profile to be supported. Exactly. So, yeah, let's can we discuss that a little bit as a group. I get to play the guy who just is super fuzzy on this maybe you guys are sharper on it but if I can get it then then I think, you know, the documentation will be better. Because I'll try to, you know, dumb it down for for people like me who I understand that that we need these. We supposedly interoperability will occur. If someone implements this particular profile, I just, I'm not clear on what what does that mean for for Aries here. Exactly. So this is why I was suggesting that we come up with the profile but is the very, very, yeah, basic of it like that would cover what you did was implementing in the past couple of months with the message structure of issue credential and present for v3 protocols. Those would belong to for example this profile. Basic messaging 2.0 that would belong to this profile. But for the rest I would need to take a look into it as well it's not in my, I don't know them by memory but this is what we're trying to achieve right like so when we're using the digital v2 profile, we're going to use certain protocols that we can interact with each other. And I mean the profile defines which protocols we align with, basically, and, yeah, two of them would be issue credential and present for v3 protocols. Okay, to how I'm not even sure exactly what to ask here. Yeah, but I think the profile that is written in the spec that it can be to is just that is telling that you just support this specification. Only that, I think that the other ones that we call the 80s. The other profile includes more protocols. Okay, we should have an 80s. AIP, whatever. Okay. That has the digital v2, but so saying you support this specification plus these other protocols like the walkie packs. Okay. Do we think it would that literally be AIP three then or do our people familiar with kind of how this is growing as a, as a scheme do we know if there's an AIP three already in the works that possibly lists. Not to my knowledge, we do not have it yet but I think this is going to be a task for us as well. Okay. So that's the topic to the 80s code. Okay, when I have like a profile for the con v2. Yeah. Right. Okay. All right. Fair enough. Let's see raise. Good. Is there anything else we want to say on that or. I just feel so uneasy with it, but you know, I'll catch up over time, hopefully. I guess, yeah, there's just we, there's work that we need to do to make this more concrete. I, I sense that the wacky pecs conversation that we just had. I feel like it's getting the heart at the heart of what this group is meant to do, which is to help everyone to know the path of least resistance for for these interrupts so Yeah, I'm we have we have this guidebook. This guidebook is really what we want to improve. So like the spreadsheet that I showed, even though it's focused on like Aries interop, the real hope is that this will lead to a guidebook that just makes it much easier for a bunch of, you know, did come v2 implementers like for the JFF challenge that they can just come through and read through this and literally not have to go through all those pain points that that they experienced. So, yeah, I guess, I think I obviously these discussions revolving around this profile and what the Aries interop profile, I think, I think will will be the key so sorry, sorry as I'm stumbling through that and processing but I am just not as grounded on the implementations as most of you are. No worries. Yeah. So maybe one information I will also meet with Steven current tomorrow for the Aries cloud Asian Python user group meeting. Yeah, at that point I can also ask if there are any profiles that have been in the conceptualization for the did come v2 basically if there's anything I would update this page basically. Yeah. Yeah, that sounds good. Yeah, we definitely want to kind of spread awareness through all these I'm sure Steven. This is one of those things where we're partly trying to catch up on where everybody is and their mental model because obviously Stevens spent quite a bit of time thinking about these kinds of things but a lot of times what happens is there's a lot of thought a lot of talk. And then, but now you know you guys are doing the real important work which is doing the implementations and actually trying to make connections across each other or make did come communications across each other so we're just yeah let's continue to try to tie this together I don't know how that will necessarily affect the spreadsheet and you know hopefully improve it but yeah, I will also try to attend this meeting I've been in at least some of the acapella meetings so good. Okay. Alex how are you doing on. Do we have anything else that we wanted to say about the occupy. Do stuff. No. Okay. All right, let's talk about the Baron typescript in pool. Maybe Baron, if you want to give us just a little update of, you know, kind of where you're at, what your kind of short term goals are. Yeah, yeah, sure. Yeah, I've been trying to create my own this concrete to library based on the sigma one, but with some small changes. So, the idea is is that it will be in short typescripts without a secrets that's resolver or crypto provider. So the secret library ships its own crypto, which is fine but it doesn't mean that you have to have a different implementation for your native and for the web and for another environment. So I chose to take out the crypto, take out the secrets resolver which they also did, take out the resolver. And it is really in a state where I don't even export anything from the main index so it doesn't do anything yet. But I've been trying to, when, when, where I have the time to basically very naively recreate the sitcom rust library from sick by like down to the variable names. So everything is basically the same. So once that is done. So once, you know, yeah, that did come rust library. Okay, thanks. So once that is done, when I have a matching interface, then I will see where I think they did something wrong and I'll try to resolve that. The idea is is that because they're of course with TypeScript you have so so many different environments that yeah you can implement your own crypto for every specific environment. So with web you can probably use web web crypto, although I'm not sure if the ED to 519 support is in there yet. And I will also probably provide some example crypto packages so you have one for note and you have one for the browser and one for reignitive. But the first version will probably ship without anything like that so you have to ship you or bring as yourself, which can be difficult but it does mean that the library will work in any platform. So you, you raised your hand, you have a question or. Yeah. So I would just warn you of kind of copying their variables down to the to exact what they're doing, because I raised this issue where a lot of their variables and data structure is not really following standards. Yeah, yeah, I picked that up as well I my document looks very different than theirs. And I think if you use a document where everything is just its own key and doesn't reference the verification methods then it doesn't work. Yeah, so I had to write my own, like, let's call it mapper and for and transpiler to kind of make sure the data I get from my standard types into theirs. And it basically doesn't match the, like, the variables are different than from the, the actual did doc variables. So I think it's a flaw that shouldn't be there. Yeah, yeah, like most of the, I think it did document I actually implemented myself because I also noticed that there were a couple things weird with it and that's would not be interoperable. But it's exactly stuff like that. And once like the library is completely copied copied that script and I will go through stuff like that and change all those implementations. And now I can see if I can create also a PR for the library from SIGPA. Because I stole almost all my structure and code from them so I can give something back I guess. All right, so this is kind of that classic situation where if we use something as an initial reference implementation, it's going to improve your work Baron but it's also going to improve their work. And then I've, you know, pretty much everybody's referencing this SIGPA stuff, because they were one of the first to market and, you know, they've shown shown some some good momentum so. Yeah, this is, it's encouraging. You know, bottom line, I think, have they been fairly responsive in the past we've seen them being very responsive so I'm hoping they're To me they respond to only one issue. And then they stopped and that's about 19 days ago. So I've the last like throughout the development I have raised a lot of issues and Brian has been Helping to populate some of those because he's experienced the same stuff. So I don't know if it's stopped or not. But they have not responded from 91 and up. Yeah, I pinged Daniel Hardman, but he's out of the company so he's not. Yeah, it's not in days since they responded to an issue. Okay. Yeah, generally, yeah, definitely Daniel Hardman's moved on. Generally, we see activity from Victor and from Artem. And at least on the AFJ side, I've seen a bunch of activity from them. Any other context maybe that we have with the sick but folks. I don't think that Daniel Hardman moved on. I think he switched companies but I think he's still quite involved with that gone. Yes, sorry, but I think it says I have no, no, let's say, no leverage to pull them to do focus on issues. Yeah, for sure. Daniel's been super active still in the did come spec and working group and things like that so. All right. Yeah, good. Alex you have your questions. Yeah, I messaged him privately but the problem was, I mean, I'm able to install the library but like he said that there are no functions that are explorable so whatever I try to import anything. It's saying that it cannot find any function that's trying to go for it. And yeah, there's like, nothing to be getting exported like this low index and all that stuff. So that was usually. Okay. Like, yeah, mostly just you guys will go back and forth that only help validate for Baron to, you know, an external user and then Baron's helping Sikpa to and snores helping Sikpa to and I saw Brian as well. Yeah, post a bunch of issues. So, yeah, hopefully a Sikpa library improves. And we'll keep Baron is is it good now for us to be working with you or is it too early. What's your preference. What do you mean with working with me using the library or yeah yeah using the library I mean you put it out there, which we really appreciate. And yeah I know that you're, you know, actively developing on it. I just didn't know how useful it is yet for us to be trying to use it and giving you feedback and things like that. So right now that it would be completely useless to to use it. But I think once once I have something some functions exposed, I'll create a message in the discord for the conflict to group and saying that it's ready to be experimented with. But yeah, it's still very very every a lot of to do is and small things. But yeah, it's it's getting there I think like a month or something like some weekends programming should be enough for some first uses. Okay, yeah, fair enough. Good. Okay. Anything else that we want to discuss. I'm happy to bring up the areas agent test harness stuff, but you know, I want to make sure that if you guys as implementers and an active users. You have something you want to discuss let's do it. I think Edvin's hand is raised. I'm not sure if it's old one or less as old one. Yeah, a stale hand bring my hand one day. Yeah, so regarding the test harness I think we will know more once we know which protocols will be used, like it's a bit hard to think about the test time is before we think about the interoperability profile. Yeah, so I guess all I wanted to bring up is that I went I'm going through the areas agent test harness and looking at what tests currently exist for did come be to and they have a tag. For for tests that are did comfy to related. And they have some scenarios built up for like out of band version two and things like that. Okay, what I, what I haven't been able to do is find an agent that is able to process those scenarios those did comfy to related scenarios. So, I'm fairly new to the areas agent test harness but I guess my first question out to them basically is how do I find the agents that are already supporting this, you know, this particular scenario or this particular test. Maybe that's obvious for people who, you know, have done it before but the best that I can see is okay I configure the, you know, the current tests that I run. I pick an agent, let's say occupy, and then I specify that that specific test, which I did. I ran it. It didn't work. And I don't know maybe I'm, there's multiple versions of occupy that I can specify. And then, for instance, we had talked about the areas go framework as well. And so I was interested to see if that if those tests would pass. I'm not sure I was able to get even the agent to to run. But yeah, I guess this is this is my initial exploration into it. Any thoughts on the test harnesses anybody use the areas agent test harness for did come v2 stuff. Yeah, yeah, yeah, yeah, fair enough. So, so I'll continue to dive in there. And I guess I'll just, you know, continue to report back. Basically, yeah, I mean, I could tell you guys, you know, what tests are out there but it's fairly easy to tell. You can just search the repository for the at did come v2 tag to get a flavor, but yeah, eventually maybe I okay so part of the reason that this is important is for us as a community to be able to quickly like plug in an implementation and be able to possibly, you know, make a determination of how well you interrupt, but also did come v3 that that I've heard from Daniel Harbin and others that one of the goals is to make that a like itf spec. So like, it's more rigor than than what it went through for for diff. And as part of that you need to have a test harness that people can plug into so maybe the areas agent test harness is to is a is a higher level. Maybe there needs to be like a more specific thing for did come v2, but I think it's a great place to start. Obviously, because even talking about the the profiles, the AIP one and AIP two profile variations. Those have tags within the areas agent test harness. And so you can get kind of a score of how well you're doing in that so I think I think that dovetails well with our new mission which is to kind of go out to the different user groups and talk about the did come v2 profile and what that means for the next or variations of areas agent Aries interrupt profiles. Last one, one question. How do you tell a kappa to run as we did come to flag something that you can tell now you use, you should use the computer or try this connection with the computer. No, so all, well, at least as best as I know all that I can do is I can specify what agent in the areas agent test harness that I want. And so I can specify the different roles as well but I generally just say, you know, minus D which basically just says default. All the roles are going to be run by that particular agent. And so if I specify occupy, I know that whatever scenarios that I specify to run, like, I don't run the entire, you know, stack of tests. I, you know, select some tests that I'm interested in, such as the out of band or I can specify all the did come v2 tests. So if I say, you know, run all the roles as occupy and, you know, run this. Run all tests that have the did come v2 tag. It just spins up the occupy agents, and then it tries to run those scenarios with those agents, right in each of their their roles so. And so that's not telling occupy, like, hey occupy this is a did come v2 test. It's just telling the test harness to run only the did come v2 related tests so it's possible actually that maybe Hakan and Judith would know better than me. Oh, sorry, we only have five minutes left but yeah, it's possible that they know maybe there's some configuration that I can do that. That that that would help there but yeah right now I'm just seeing that those tests are failing and yeah does that answer your question roto. Yeah, as best as I can tell I mean Hakan and Judith can can weigh in but as best as I can tell essentially the they're going to put as they're implementing this stuff there's code that's saying, oh this is a did come v2 message so I'm going to start processing it as such. Yeah, exactly so both of them will be supported like did come v1 and v2 and there's the difference is going to be in the connection entry within the internal database to either communicate with the other corresponding agent with did come v1 or did come v2. And regarding the, yeah, and this has not been implemented yet on akapi so the only outbound communication that is happening is like through the old did come v1 envelope rfc019 I think was called. However, it will change depending on the basically connection tag that that few it will support like multiple did come encryption envelopes v1 for basically a IP 1.0 2.0 and yeah did come v2 encryption envelope for the other into our profile that is not defined yet. And the endpoints is the same I think they will be all there like issue credential v1 is there for example issue credential v2 and issue credential v3 for example all endpoints will be visible on the. And the back end basic on the API. So there is no start parameter where you say start. Well, I guess it would be possible to say like I have a flag of like start akapi did come v2 where you only see the endpoints related to did come v2 but. In a general sense, it's not a necessity but like it would be an additional addition basically but we have to make things a bit maybe simpler for people who wants to use the akapi only with this conv2 and just don't even see what happened in the v1 work basically. But yeah, there will be basically an addition that's not a requirement. Yeah, fair enough. We have just maybe two minutes left, because I'll need to jump into another meeting any any final things what can we do. Also, you know just to make this time more useful. I mean certainly I think if we're reaching out to the other user groups and talking about the did come v2 profile and how that will map into a IP. I think that'll be super helpful. What else. So, yeah, I think this is what I would like to work on with, at least to come up with a draft of what could be a part of the interoperability profile for did come v2. And we can talk about it maybe next meeting to see whether we are missing anything or. But it's like plausible or yeah just to have a starting point basically. Okay. Yeah, I think it would be useful to talk about in a group. Anything else that we will want to done or update for by next week. I think that's a good that's a good goal to have. I will also be wanting to update you all in terms of the areas agent test harness. Yeah, just as I discover more, maybe I'll just learn that yeah, there's just no support for that and maybe I guess the big thing for me right now is to learn how to discover quickly, which tests are supported by each agent like I have seen the page. I don't know if everybody's seen this but we have the areas interoperability information page that gives kind of scores and even scores between agents. But yeah, I don't see any of the did come v2 stuff listed and maybe in some way they are tagged so that they are not run as part of this or maybe I'm just missing it. But anyways, I'll have more information as we go. Anything else. Okay. Yeah, great group today. Good to see everybody. Thanks for all the work that you're doing and feel free to post anything in the areas did come v2 channel. I think the more activity we can get going in there the better. That helps new people also to have a handle on things and yeah I'll probably see some of you at the diff did come meeting that's later today. My question is, do you guys have your own channel somewhere is it possible to bridge it between the did come discord group or what's you're talking about the diff one yeah I mean it's certain certainly being active in there is good too. We had kind of discussed if this should be a separate group. If you have like more general did come the two stuff I do think it's best to jump in the diff one. But if there's things related to airy specifically, then maybe maybe jumping into the hyper ledger foundation channel is maybe better. Yeah, thank you. Yeah, thank you all. Yes. Gotta go. Bye bye.