 Good morning, Lance. Roto, how are you? Good, good. Good. I'm going to grab some coffee. Okay. I need some. How was the weekend? Yeah, it was good. Just lots of relaxing. I was exhausted after last week. Yeah, just complete relaxation. How about you? Yeah, same. But I had to... my kids and to go to the house of a friend in the beach. So we traveled to that. It's like three hours. Spend the day and go back. Just lots of driving back. But it was on the beach, yeah. Yeah, good. Alex, how are you? Hi guys. My wife off to her new residence. Oh, nice. Great. How was your good weekend? It's good. Sounds like Roto drove to the beach with force kids for the day. So busy for him. And then for me, I was exhausted after last week. Yeah, all the making videos and stuff like that. So I did nothing all weekend. I was a little bit kind of sick on Saturday. So I slept a lot. But then, yeah, I'm feeling better now. And it's good. How's the winter? I miss summer. It's zero Celsius outside right here. Yes, you? What about you, Lance? Yeah, just above that. Yeah, maybe one, two. It's cool. Awesome. Okay. Let's see. It might just be us. So we can choose if we want to. Spend much time. Well, just to be official. Welcome to the Aries. The comfy to working group. January 23rd 2023. Remind. You about the antitrust policy. Or Aries for hyper ledger and the hyper ledger code of conduct. Feel free to add yourself to the attendees list. And. Let me put the link in the chat just for. Posterity and for you guys. Hello, Bruce. Good morning, everyone. Or evening or wherever, whatever time it is, wherever you are. Morning for me. Yeah. Yeah, morning. Good. I'll post the link again just in case I posted it before Bruce. Arrived. Okay. So, yes, feel free to add yourself to the attendees list. And we can get started. Let's just do any updates before I go through the. The different groups. For discussion topics today. I'm starting to do Aries agent test harness stuff. So there's, you know, an easy command you can do to list certain tests. So I've just posted that here that the, if you list all the tests for did come v2 currently in the test harness. You get these three essentially for wacky issuance. Establishing a connection via the. V2. Out of band V2. And it present proof v3. Test. So that's kind of the stuff that I'm focusing on. Right now. Anybody else want to give any updates related to. Did come. V2. A IP three. Any of that stuff. That we might add to the discussion topics. I don't think I have anything to report. Okay. Good. Okay. So then we can go ahead and. Just do a quick review of kind of the past week. Aries agent test harness. They actually did have their monthly meeting. And I did jump into it for maybe the first 25 minutes. And then I had to head to a meeting, but they were just showing some updates more related to. M labs. So I think M labs does a lot of the. Maintenance for. Or a lot of the contributions for the Aries agent test harness. And they kind of have a whole suite of. Like web based dashboard stuff for, for doing Aries agent test harness. And you can sign up for an account and. They're essentially, it's a bunch of. You know, basically software as a service that you can like sign up for an account. And it would allow you to like spin up an Aries agent test harness and. Things like that, which is especially useful for like mobile development type things. All that to say. You know, there's a bunch of new features that they added to that. I wasn't as focused on that stuff. Mostly I'm running the Aries agent test harness stuff locally. But if anybody's interested in kind of having professional. Support for Aries agent test harness, then M labs is. They're the group. So they're a nonprofit in Canada. So that was good. I didn't have time to talk to them. About the AI P 3.0 stuff. You know, if they're more focused on. Or I would say the meeting was more focused on just like. You know, the surrounding ecosystem for Aries agent test harness. But I'm sure they would have been somewhat interested in learning about the rise of AI P3. But yeah, I was, wasn't there for enough time and didn't want to jump in on their conversation. So at some point I'll let them know that we're, we're focusing on AI P 3.0 stuff. Oh, hey, Lance. I opened an issue. I'm a repository. Okay. Did peer and walkie-packs support to their newcomer calls. Just as an affair. Wacky pecs to their agent as well as did peer. Okay. Yeah. Yeah, right now, the only things I have support for deep key. And yeah, right now, pretty much the US did web for. For the did come into purple. Okay. Gotcha. Very good. And so you're basically trying to help them walk towards kind of an AI P 3.0. As well. Yeah. The idea is to like have them like areas compatible. So you can have the bramo agent talk to like an area agent. Yeah. From like a standards perspective, like, at least. Okay. Yeah, because I joined their, the community group call last week on Thursday. And they kind of like just brought those as well as like, you know, the credits spec is becoming like your agnostic. I raised that to them as well. And they were, they were excited about it. Yeah. Very good. Okay. So let's see how shall we do this? I guess we can put that under frameworks. I mean, it's not an Aries. Framework per se, but. Yeah, why not, right? Like you support. And did peer. Cool. Okay. Good stuff. All right. And then. Do we, I guess, do we have any. Thing to talk about for areas ascar secure storage. I think. Maybe part of the reason we mentioned that is because aerial. Is adding support for that. To AFJ. And so, yeah, I mean, there's some, and we had discussed last week, I believe some of the. Kind of cryptographic issues with that. I can't remember if I have this listed somewhere on here, but. Anyways, yeah, good, good to be aware of. Okay. And then in terms of frameworks, let's see. We know how gun and no Judith. Any, any updates on. Okay. Okay. So, yeah, we'll go into the aca pie. Oh, right here we go. This is where we talked about as car portion encryption envelope, not fully developed yet. Yeah. Basically they said they're. They're going to stick with sick. Yeah. No near term support for ASCAR. And they're, they, you know, And if anybody else does any work for that, yeah, they'll, they'll leverage that for sure. Okay, so the AIP 1 and 2, that's the kind of two big supports within the test harness. And so, yeah, that's did come the one related with updates to the envelope as well, but yeah, not did come the two focused. And so, yeah, that's that's why the need for AIP 3.0 is rapidly growing here. Yeah. Okay. And let's see, Aries Framework JavaScript, I did attend that meeting. I did tell them that we've been spreading the word about the need for help for the pull requests that are currently ongoing. No one is necessarily, you know, jumping to take that on yet. So we'll just have to see how that goes. All right, Pico's, Bruce, any, any updates? Not much new. On Tuesday, we met with the students and they're pleased that they have working for PAC and unpack of messages and they're hoping to begin sending messages. So again, I'll probably, I'll meet with them either tomorrow or a week from tomorrow. Good. Okay. So it spice on the language that they use on the on the Pico's or Java? Pico's run are supported at runtime by a Pico engine, which is a Node.js process. And it interprets, well, it compiles to JavaScript a language called KRL, which is an event, an event-based language. So it's its own language. Okay. So they didn't incorporate the SikPy Rust libraries. Oh, okay. Okay. Good. Yeah. That's what I meant. So they use the Rust to compile, like, you know, Wasam or something that that isn't. Something like that. I'm not sure of the details. I'll find out in our next meeting. Cool. There's one just for reference. I think Brian from Avery Tech, he's working on a, I think a TypeScript library. Interesting. Yeah. Do you know, Alex, how far is Brian doing that? It's working, right? So I haven't tested it. So like, as far as I know, like he is running like he's also like crypto libraries as well. So it's like tightly coupled to his crypto library, as far as I guess I saw the code. But I can like add a link in the, in the, in the chat for the repo. Tested it. And the problem with that is like, it's packaged for like his belt app. It's not really like packaged properly with MPM. So we'd have to talk to Brian about making it like an actual like Bitcoin library, per se. Yeah. Yeah, that would be very useful. Is there a, is that repo available somewhere? Yeah, I'm going to show you the link. Yeah, let me find it. It's this. It did come. So I went into the chat there. Great. All right, very good. And I think he also did beer. Yeah, he's there also. Let's do it. Yeah, Alex already. Yeah, if you look at the code, like you will see his product, his belt, his package, his belt application. It's not really like package as a package. Oh, it seems like, so you said it's TypeScript, right? Yeah, TypeScript seems like he and Barron should be collaborating, right? Isn't Barron also doing a TypeScript implementation of Didcom as well? I think he mentioned he's going to start something, I think. Okay. All right. Well, good. Okay. So, yeah, if, okay. So essentially, if the tests that currently exist in the Aries agent test harness include wacky issuance. So, you know, I'll be looking through that. But that's one of our base things from the Silver. If we look at the Aries interop profile, obviously wacky issuance and, sorry, present proof. So, it looks like those two have support as well as for out of band 2.0. So, that's a pretty good start for tests, I think. I will need to go through and look to see what these actually do, you know, and become more familiar without the test run. And, you know, is it complete in terms of all the wacky steps and things like that? I'll have to look in to see if there's tests for revocation notification from like did come one v1. And then, yeah, what did methods are being used? I'll also have to look into that. But I still think it's nice to have some tests to start from. And especially, you know, these are more complex tests, surely. So, that's, I think, good. Do we think that we would want tests covering kind of all of these things, like a trust ping test and, yeah, discover features? I do think that eventually we would want tests for all of these. Yeah, I think so. This is just, this is going to be too compliant. Yeah. Because they are part of the spec itself. Yeah. Yeah, fair enough. And that's what was, those protocols was already on AIP2 as independent as RFCs. So, I think what we did is grouped that in the outcome to spec. Okay, interesting. I wonder, let me just check real quick. I'm going to put in, I'm just checking to see if maybe there is a trust ping already implemented. Well, tough to say. But yeah, I'll look into that as well. Looks like there might be. Okay. And so possibly those aren't, yeah, I'll look through because possibly some of these are not listed as did convi2. So, yeah, I guess I'm a little confused. Do you think that trust ping, for instance, 2.0 existed before it was? Not the 2.0, but one. Ah, okay. Right. An earlier version of trust ping. Okay. Fair enough. All right. So essentially we would need the 2.0 version of that, although for something like trust ping, I would imagine that's not, yeah, it's probably fairly simple, right? Yeah. Yeah. Okay. Well, cool. So, yeah, I'm excited about that work. I think one thing is that we had in the Wednesday meeting for the Aries working group, we were on the schedule at the end to talk about AIP3 because from our last meeting, this last weekly meeting, one thing we want to know is, okay, well, you know, what do we need to do to move forward? I think we've all agreed at this point that we're going to keep it fairly much fair. This seems like a nice list of base requirements and we like having broken it out into these other parts. And so what do we need to do to move forward? Since we haven't developed an AIP before, you know, we kind of need guidance there, but yeah, we never made it because the talks about OCA and things like that took too long. They apologized and, you know, no need to apologize. But yeah, I think it's worth kind of moving forward, you know, with the testing stuff, especially since I'm going to be doing test harness work anyway. So maybe that will help to establish this, I don't know, momentum is something. And then we had also talked about kind of having this new tag for maybe a simpler set of didcom related things. For instance, if you didn't care about wacky, and that's good too. So yeah, in terms of adding a tag, I think it's literally as simple as me making a contribution to the Aries agent test harness, where I add a test that happens to have that tag and it'll just get picked up. I think I showed it before. I'm not sure how much everybody cares. But yeah, go ahead. One question I had is, how is this AIP3 going to be different than the didcom v2 interrupt profile? They're like, they already have defined because they already have working text in there and it's probably too compliant. Because what if somebody brings it up and they're going to say it's maybe like too similar? Or like any thoughts on that? Yeah, I think that the specifying a did method that someone should support is in addition in terms of is revocation notification? Yeah, well, also did come, I'm sorry, Alex, did you say wacky or did you just say did come? Well, I think I said both. Okay, right, you watched it did come profile, it's like a did come v2 profile that doesn't seem like walking defines like two signature suites, I think. Yeah, it doesn't define like any like, did methods and that kind of stuff. Like, I think it limits it to like two signature suites. And yeah, just the one thing. Yeah, yeah, but this one is a little more. And this is on different. This is on Aries. That's one of the main and this one, Aries includes the revocation and all the other optional stuff like the mediator and all that kind of stuff. But it's actually that is good because this one there is have the did come, the wacky did come included, right? Yes, yes, yes. Okay, yeah, that makes sense. Yeah, I think it's actually a strength, Alex, that it is at the base requirement. It is very close to essentially just wacky did come. Yeah, I see it as an extension, almost. Yeah, it's just, I think a little more real world practical, right? Yeah, more specific, like wacky did come is like way too broad to actually be applicable. So yeah, it's like defines more constraint on the connection. Yeah, it's also always confusing this because some work is on hyper lecture, some of thief and where we put all the stuff and it's happening. We did it come with your right, the protocols, for example. Anyway, we are all the same people. So we can keep it in sync. Yeah, just politics. Yeah. And we already see with some of our other customers that want to engage with the Aries ecosystem over did come V2 that specifying this specifically this set specifically will be very helpful for Yeah, I guess wider interop. So I think it's actually interrupt. Yeah, right. Yeah, there you go. Real world interop. Real world interop and just some specification around here and there. Yeah. And there may be, I'm sure there will be additional notes. You know, that original spreadsheet that I started to fill in the idea there is, you know, are there, what are the gotchas, right, that maybe even this list doesn't necessarily you know, fix for you. You know, again, like interpretation of certain parts of the protocol and, you know, we see discussion still on like the diff did come. You know, discussion boards about, okay, the spec says this, you know, what does that really mean, you know, what do I put in the the this particular field, you know, you know, which did do I put in there or, you know, which, I don't know, we see those discussions, right. So I think, you know, maybe hopefully, more of those details we could add over time as well, where as real interop happens and as we hit real brick walls. Yeah. Okay. Good. Any other thoughts in terms of Aries agent test harness or AIP three. I mean, I do, do we all agree we just want at this point for, you know, Sam and friends to say, yeah, this looks good. Let's start, you know, solidifying this and, you know, having tests added to Aries agent test harness would be a good thing. I mean, I don't want to jump the gun too much on that, but I also feel like starting to push on that will cause, I guess, real discussion of how much more we need to do, but I think this is pretty good. Okay. And so, yep, basically this tag, honestly, did have we captured the best names for this? I feel like there was other names suggested. Or do people care very much? I guess we basically want a tag that that's saying, yeah, it's did come. But right now, for instance, if you were to tell the Aries agent test harness, okay, run did come tests, it would run the wacky tests, right? So if you don't want that, then we kind of need this alternate thing that's, you know, maybe something like did come v2 simple, or maybe we just call it did come v2 messaging, or something like that, that basically is saying, you know, I don't care about credentials, okay, did come v2 base, Alex is suggesting, well, so base, like mediation, base, I don't like because in our AIP 3.0, our ideal base at that point is does include wacky. But of course, maybe, maybe one thing that we do is change the tags that currently exist. Because maybe what the one that has wacky in it, maybe what that should be tagged is AIP 3. Although it is also a did come v2 tests. So I'm not sure the best way to organize that, thinking out loud. Or maybe the idea is to just, yeah, I do like the idea of basically saying, can you, can you communicate via did come v2 and possibly discover features or something like that? And then that's it. Right? That's, and do a trust ping. Maybe some, the like simplest stuff. So yeah, base or simple or something like that, I guess we don't have to be, we don't have to decide now. But if anybody had strong sense, sometimes names can be really important. So and if we go back really quickly to Thomas's list here, essentially the list that I'm showing is is is like what he's done here where he's sorry, I'm scrolling a lot. I know. Yeah, AIP 1.0 status and AIP 2.0 status is essentially he's showing all the all the tests that exist with it. And by RFC, we'd want to be able to do the same for AIP 3.0, I think, but eventually also including the complexity of, sorry, the complexity of maybe these, I don't know what to call them subcategories or additional categories. So, yeah, hopefully that just gives you an idea of how kind of the test harness looks at these things in terms of tags. And yet, it would be nice to be able to say, yeah, yeah, I do did come messaging, but I don't support, you know, credential flows and things like that. Okay. Anything else from Grand Unified Theory talk? I'm trying to think if I can remember any of the other meetings mentioning it, I do feel like it keeps coming up, but okay, Bruce had said did come the two layer one as possibilities. I'm going to put both of these suggestions on here just so we don't forget. And that was kind of a nod to Daniel's Grand Unified Theory in that it brings together something from Diff and something from Trust Over IP. Okay. Yeah. Like that. Right. And we had kind of talked about maybe visualizing AIP 3.0 in terms of the Trust Over IP, layers as well. So maybe this goes well with that. Right. Layer one being we know what did method to use. Now, layer two is messaging. I'm sorry. I meant layer two. Okay. Gotcha. Yeah. Fair enough. Yeah. As opposed to layer three, which AIP 3.0 and others just include. Yeah. Yeah. Interesting. Right. Bringing it down by the Trust Over IP layers. Yeah. I like thinking in terms of that as well. Good. Okay. Right. So we had talked last week that yeah, essentially the Grand Unified Theory, if we can keep calling it that. And also, well, yeah, one thing that did happen is Daniel posted it on Medium, a new post talking about the difference between DidCom v2, DWN, Chappy, and OIDC. So maybe putting that. That would be very interesting. I missed that one. Yeah. Yeah. It's a really good post. I got that in here. Okay. Yeah. No, why not? Yeah. If somebody can post it there in the chat, I'll put it in the video. Okay. Yeah. And so at the same time, right, it's coming back now. I think that the DidCarry spec might have been posted. I don't know if I've seen that, but it does seem like there is a rush to get DidCarry out there. And possibly because they want it to be a part of ARP3. So that would be an interesting discussion. I did some, a proof of concept DidCarry that I need to show first in the Carry meeting with them and discuss if that's suitable for like being what Daniel was expecting at the unified theory. Right. Still I'm not sure that we should include that in ARP3, but it's okay. There's gonna be something. Yeah. And also, Alex noted that there's a warning now on the DidCarry spec. He had seen that and sent that to us. And so that's worth showing. Let's see. DidCarry spec. DidCarry. Let's see if I can, yeah. Oh. This time when I went to it, maybe let me go to the latest. Hmm. It's almost like, I'm gonna, let's see. So this is Daniel's post. I'll put that up there. So really good post for somebody like me, especially who is not as familiar with the other, those other OIDC and CHAPI. And I'm kind of familiar with DWNs, but only at a very, very high level. And it would be nice to see some of the overlap that exists for some of these things. I'm very interested in the centralized web nodes, kind of how the messaging between them works. And does DidCom, where does DidCom sit with DWNs and things like that? But hmm. Okay. So Alex, when I went to the peer did method specification, I saw for a second that red, red lettering. Oh, and it did it just then too. I don't know if you guys could see that, but yeah, it's almost like it showed the red lettering stuff and then redirected quickly here. I'm wondering if there, how can I get back to? If you scroll a little down, it says the warning a little bit down. Oh, there you go. Okay. Yeah, very good. Yeah, I think they fixed the page, but otherwise we showed just the warning. Gotcha. Okay. Yes. So essentially, the wheels are in motion here. And it's the wheels are in motion of deprecating DidPeer in a way. And now mentioning DidCarry. Yeah. So interesting. Does this give us enough that we want to mention these as part of AIP 3.0? I guess for one thing, do we think DidKey should be mentioned no matter what? Or also Alex has mentioned DidWin. I don't think you'd ever use DidKey because you need service endpoint for DidCom v2. So DidKey is not a support for DidCom v2? Yeah, did. Correct. Yeah, DidKey is. We cannot use DidKey, right? Is it not useful at any part? Did it come v2? No. Okay. We can make a hack, but it's not, yeah. Okay, fair enough. So yeah, then we have to decide if DidCarry is worth mentioning. Also, DidWeb, Alex, you've mentioned multiple times. Is that something worth bringing up for AIP 3.0 support? I mean, right now, I just think we're DidPeer at first. I'm sorry. Say again, you think Did, just mentioning DidPeer is sufficient? Did we lose Alex? I see green. Am I not hearing? I don't hear Alex either. Okay. Well, maybe he's caught up, but okay. So something to consider, at least. Did I put this on? Alex said in the chat that he thinks sticking with DidPeer is the best for now. Okay, there is a warning about DidPeer on the spec now. Okay. Yeah. So there is certainly some movement still happening because of Daniel's stuff and Daniel's grand unified theory. And that's good. It's good. Yeah, the warning was posed by Daniel on, I think, on September. And what I remember, he's gonna maybe not be so strong on the warning because he was really saying that the last phrase, say, I just won't get a lot of attention now. So I think he says he's gonna change that for some better wording, not so too dangerous to read. But I don't know what happened last week with the rendering because that appeared in red, I think. Okay. I hadn't realized this was, even though it says it right there, I hadn't realized this was from September, I guess because, right, the last week was the way it rendered seemed like a new thing. So maybe I'm overreacting too. That's one of the things that, why we start this, I think, these meetings. You remember with Brian talking about DidPeer, how we can do interoperability, and we make Daniel's talk about that, explain why he's saying these words and so forth. Well, I think also, DidPeer libraries, the SIGPA head, they are not like the WP sequence line, like the de-document and in-pature and stuff like that. It was also one issue that we had. Interesting. Those have improved now or not? As far as I know, no. It's like the SIGPA is not supporting really the DidCom V2 or the DidPeer library. You just have to either fix your DidPeer library match with the DidCom library. I think that was one of the main issues. If you look at the DidPeer that Brian had, he's trying to make it SIGPA compatible in the code. That was one of the main problems. If you follow directly the specification, with all the DidPeer, you won the keys one minute. Interesting. Okay. All right. Some good updates there. I don't know the best way to approach the DidCarey stuff other than keeping it up and getting people's thoughts. Certainly, I guess this, let's see, go back to it. Well, let's see. When did we get updates? Okay. Is there new activity happening on this, Roto? Or you sent the DidCarey? No, I think that we need to talk about that. Yeah. Feel and see how it's going to progress. I feel like it's incoming. Daniel was requesting something in Simpia for the first DidCarey light. Maybe not the full DidCarey method. That's why we need to see how it can have something that works both ways. Something complex for a full DidCarey or something simpler for a Cadillac than Daniel mentioned. I think that's a really good point. If we're moving towards unifying, as Daniel suggests, then we have some work to do on our end, and the Carey folks have the work of giving us a smaller and easier to implement subset of DidCarey that Daniel called DidCarey light. Yeah. Right. Okay. Very good. All right. Well, okay. To keep it simple, yeah, we'll just keep pushing DidPeer, and yeah, we'll see where it goes in terms of DidCarey. Okay. Let's see. We might have to create a new JS package for DidCarey light just to do basic signing and did generation. Okay. So, Alex, you're saying that in terms of... Yeah. I was looking at the Carey JS package, and they have a lot of encoding built in there, like generating pictographies and all that kind of stuff. So, maybe just simply tying a subset of the functions that they have. I think something like signify.ps can be used, like the signify client can be used, like expected properly. So, maybe we can leverage that. Okay. And is that a TypeScript JavaScript library? Yeah. It's a TypeScript implementation of client function for Carey that can run locally. Yeah. Okay. Good. All right. That's pretty good. All right. Anything else? We have about 13 minutes, but I don't think we've seen Thomas. So, nothing about Apache Camel. I haven't done much with the spreadsheet. I've been more focused on the HackMD plus looking into Aries agent test harness. And yeah. Okay. Just looking through our old notes, making sure we're not missing anything. I think... Let's see. We did list Daniel's notes. I think that's what this is, right? Those are the slides, yeah. Okay. And so, that has kind of that narrow waste of you. Can I open this? This way? No. It's a widget. Let's see here. We can always update. Oh, I probably could have edited it. Yeah. Here we go. I just wanted to go to the diagram. Yeah. We're here. Oh, that doesn't look great, does it? Those are mine. How do I go full screen or something here? Autoplay, open speaker notes. Here we go. Oh, except I don't think that's showing to you. How does that look to you? See, the ZCOM Delta slide full screen. Okay. Is it clear then? Yeah. Okay. So, I should be able to go backwards. No. All the controls are... Oh, here we go. Okay. There we go. Is that kind of clear? So, I guess what I'm trying to do is say, if we look at AIP3 in terms of the trust spanning diagram, which, by the way, the first meeting, I believe it was the first meeting was last week of the trust spanning task force. And so, I attended that. And that was mostly intros and stuff like that. And then just encouraging everybody to read up on the different layers, the kind of classic layers for trust over IP and then reading up on what they are defining as this trust spanning layer. So, I think that stuff, obviously, because DidCom v2 is going to be kind of discussed a lot in this space, it would be good to be aware of that stuff as well. So, I'm going to go through and read up on that because I don't have it sharp in my mind exactly what these things entail in terms of DidCom v2. There was, I think, a better chart somewhere. But certainly, we understand trust applications as being built on top of application protocols, which I think they call trust tasks. So, in DidCom v2, we talk about application protocols, but I think that falls here in layer three as trust tasks. And then some amount of DidCom v2 is this layer two trust spanning layer. Thoughts on that? Anything to say? I mean, I do think at some point, we need to be able to talk to this very strongly as well. I mean, to me, it seems obvious that Cary is going to be the underlying layer for everything since it was purposely built for that. It's like a matter of way for people to understand what it can do as well as the system encoding. So, that's kind of like my thoughts on it. I'm not sure exactly how DidCom v2 will fit in there. Maybe it can be like the CLF type of thing that can do hand shakes. But since everything is end verifiable in Cary, I'm not sure like you need like a messaging, like an enveloping protocol since you can verify what's happening in the envelope. So, you're doing the envelope to be necessarily secure because you don't trust the envelope. You trust the data that's within the envelope because you can verify it since Cary is end verifiable. So, I'm not sure like I personally have an understanding of how Cary and other DidMethods are going to interact because I see Cary as competing with like DidMethods entirely, not like DidCom like in my mind. Because I can write another way to reference identifiers and I think Cary is what the DIDs were meant to be originally. Like a key that can identify which you can rotate keys, but it identifies this constant. Like in an actual cryptographic way. So, I'm not sure like I have my thoughts ever really formulated on this whole thing. I probably need to attend more meetings and see how people feel about things. Yeah, guys, any thoughts? Yeah, actually, well, I don't know. You're challenging my assumptions here. I mean, I agree that AIDs and Dids are somewhat competing and certainly, you know, a DidCary is essentially just leveraging the AID concept and kind of marrying the two concepts of AID and a DID. I had in thought about enveloping in terms of, I had thought of DidCom v2 and Cary as a complementary, but it sounds like you feel like it's, they're like, I don't know, redundant. Yeah, I would say like using DidCom v2 and DWMs, right? Like you could if you wanted to, but like they kind of accomplish similar things in terms of like messaging. Messages aren't encrypted, right? Like you can do with the AIDs. So like the key core functionality is the same, just like the implementation is like done differently. But the underlying properties that you get out of that protocol would be the same. Like at least to me. Interesting. Okay, so maybe this is something that would be good for us to kind of unpack in these meetings over time. Because I do think that we should be able to talk to this. I think that'll be important. If AIP 3.0 is DidCom v2 focused, but possibly introducing, you know, Cary things, then I think we should have a strong message in terms of where the overlap is and yeah, is there too much redundancy or things like this? Yeah, but I think once this is different timing. So AIP 3.0 is now. This trust spanning layer is future. Yeah, just start the meeting last week and that's going to last half an year, one year. Yeah, we're going to be nine maybe. Yeah. Yeah, I think it's going to be one before people come to consensus over which trust spanning layer. Yeah, I guess I, so it's really good to, yes, keep that in mind. And certainly I do would not want AIP 3.0 to get bogged down. Yeah, by this kind of new larger discussion. I guess I mean, you know, for me personally, I would like to be able to talk to these layers in terms of AIP 3.0 and so that I can express and understand, you know, what is it mean to empower up here and, you know, what overlap is there between Cary, which we know fairly well and then did conv2, which we also know fairly well, but then, you know, I think what Alex just mentioned, it just a challenge is some of my understanding and assumptions. So I think it'd be worth, you know, just having some discussions on it over time to kind of unpack what that means not to overuse the word unpack. Yeah, for all of us to kind of grow, I guess I should say in terms of understanding of what's meant by these things. Yeah, anyways, I'm kind of giving myself homework, I guess. So yeah, good. All right. So how do I, there we go. Good. All right, two minutes left. Any last words? What would we like to come back with next week? Hopefully I can give much more updates on the Aries agent test harness, specifically kind of these tests that already exist, kind of give a review of what I found there in terms of what's in the test and how they even work, right, in terms of, you know, what did methods are being used and so on and so forth. So I think that'll be good just to continue to dive into that. Hopefully we get to talk about AIP3 at the Aries working group on Wednesday. I think it's worth, you know, thinking about these names and I'll kind of, this would be the first time that I'm really thinking about how the different tags in the Aries agent test harness are layered on top of each other. And if a hierarchy does exist at all, so that whatever name we come up with here is very meaningful. I like thinking of it in terms of possibly layers related to trust over IP. Anything else? Thank you very much Lance for the meeting today. Yeah. Yeah, I'm enjoying this thoroughly. Thank you. Hopefully everybody else is. I think it was a really good conversation today. Yeah. Yeah, good. That's good. Yeah. And I appreciate what you brought up, Alex, in terms of Kerry and Didcom. That's going to make me think. So yeah, I was trying to do research like the Kerry video, like with the AIDs and stuff like that. So I really listened to all of the Sam's presentation over the weekend. And like I tried to like remake myself with a mental model and all that. So that's why I agree. All right. I had that one. Good. Okay. Great. Okay. See you all. Goodbye.