 Welcome to the August 15th, areas of the Asian Python maintainers meeting. PRs to finalizing 010-0 and on creds and then did peer work. Hoping that it's here. Jason, can you see if you can ping Syro to see if he's going to make it. It would be helpful to have him here because we're going to flow right into the on holidays this week. No, he's back today. Okay, I'll see if I can dig him up somewhere. Okay. You could just send him a note. Reminder this is a Linux foundation hyper ledger meeting anti trust policy is in effect. Conduct is in effect. Welcome all. Okay. We'll start with a PR review. And head to finalizing 010 after that. So we look at what's been merged lately. So this morning we did the legacy. Peer did resolver. So that is in. So that was added. Is that how you pronounce it. I think so. We'll go with that. Was added. Any thoughts last I checked there was, as I said, in the thing 236 issues, which terrifies me. Has anyone looked at the reports at all yet? I guess we're getting worried about that later. I did, I did briefly scan through them. I think a lot of them are, are pretty minor things. A lot of them would be addressed by some other things that we have pointed out as potentially doing already anyways. Like, like trimming down the Docker images to not include things like them or curl and those things. Okay. Yeah. Oh, that's interesting. Okay. We did remove the indie tests from the workflows. I don't know how much faster things are now, as anyone, I guess that legacy. Here would have run through the overall tests, but that's good. And this fixed insure request matches opera. What was that Daniel remind us. So in Jason, I'll be creds. For an exchange that was started with an offer it was possible for the request that the holder sent back to be different from the offer. And if you were on auto issue, it wouldn't check that it hadn't changed between the offer and the request and would just automatically issue whatever was in the request. Okay. Okay. We did the release. Rather suddenly. That was triggered by this, which was that Kim did a Kim Ebert did a fix to speed up multi use invitation handling once the load got higher. And that duplicated a web hook being emitted, which Emiliano suppressed in 8082. And what was not understood was that by suppressing that a follow on web book was not emitted. Which was rather weird. So anyway, that's been corrected. I'm not sure if that's the right thing happening. This got merged in. Just documentation and Docker related updates. Not sure quite. How Shangot did it without a review required, but I did look at it and it's all just documentation and Docker related. So that's okay. And then previous, we already discussed all of these things, I think. Yeah, I think we're caught up on what's been merged. Let's talk about what's coming. We've got nine left. So working, I believe this is, yeah, work in progress. So the nightly build just happened a few minutes ago. Yeah. This TA acceptance. Daniel put a comment, Andrew, for you to take a look at. And get your views on this one. Yeah, I'll look. Go ahead. There's another PR and ND VR, I think related to this. And worthwhile. It seems reasonable, but I'm not. This is showing up now unless something. Like it maybe depends on the Python version that's in use. Not sure. Interesting. Did he say why put issues in for each. I think the other issue he explains that it has to do with being incorrect clock on the system. I'm too precise error if container time zone is not UTC. So I mean, obviously he was getting an error. At some point in trying to run it. So this is and fixed it this way. I don't know when this changed in. Andy Plannum. But at one point it only had to be rounded off to like the nearest minute or something. So I think the privacy risk was when you were sending milliseconds, I think something like that, but. Nice. Now it has to be a mid name. It might be easiest to just treat it as an integer and round it off. Okay. Well, you've got that one for now. If you could. Let me go back to the pull request. I can assign this to you just so. You know. I think you have the wrong one selected there. Well, that's a bad thing. Thank you. I give up. Okay. Proof negotiation. So this was one that was opened by, I think, Percivis was the organization. I don't know how to pronounce the original author's name, but it seemed like a pretty reasonable change. So I decided to help resurrect it a bit. I think there's. There's some additional changes that I think are, are good to make here. But I think having the ability to do the proof negotiation. If you want to, I think make sense. And the code was relatively clean. So. Good. Okay. We'll leave that one to you. Jason. Progress on this one. Yeah. So I just have another comment this morning based on Daniel's, because I. Wasn't able to do the existing tests use schema name and schema. Version to do like restrictions on the proof requests. So I started with that and it didn't work. That I flipped it to the cred def ID, which was, was what Daniel used in the test script. And it worked. So the proof request work, but not the same as a previous one. And Daniel said that that's not. That's not the case. So I'm going to be today. I'm investigating why that's not. Working. It's quite possible. It's just something that I'm doing, but I need to get that squared away. So that existing proof requests would work. Yeah. That's very weird. Yeah. It could very well just be me finger fumbling or whatever. But yeah, let's. To be transparent. I think all I did tests in practice was the credit def ID. So it's also very clear. So anyway, it was good. Thanks for telling me that that's not. The expected behavior. So I'm going to look at that and see if I can figure that out. And then we can decide if I figure out what it is. If it's a big thing, then maybe we put this PR in and then do a separate PR for a fix. Or if it's something small included in here. So. Yeah. So the other issue I had was just, it was. I don't think it's a big deal because obviously running the actual run BDD. Scripts and how we're doing it work. I just been running it. The behave. From like just running behave. Right. I've got to try and figure out what configurations match up in. And I just get. So I'm just leaving it to. Using dev containers. So some things are in Docker. Some things are in dev container Docker. Some things are running the behave script from the command line. All the same. Kind of sense things weirdly. But as soon as I run the same exact code using the run BDD. Script at work. So I'm. Leaving that as a development box. Issue only, but the presentation presentation. Yeah, I'm going to spend today. Trying to figure that out. Okay. Yeah. All right. And then. Now in doing that. It looks like all. Is there, have you done co-changes for this? Or is this just activating tests? So. They're net new tests based exactly on the previous ones, but I have to explicitly say use the non-creds API. So as much of it's reusing the existing. BDD test code. Basically it's just like the kickoff part of it is to say, use a non-creds to create the screen and cred death. Use a non-creds to revoke. So. There's not actually a lot of new code in the, like there's some stuff in agent container and agent pie, but it's basically just. There's not a lot of new code. So. So I did have to do some stuff where you're at right now. So these bind providers. I need to. So these bind providers. I need them in place, whether though, I don't think those are going to stick around as we get to the next kind of things. As we. The ticket that's to kind of. Touch up all the actual API endpoints. Right. Convert those things. So, but for right now with those things in place, I need those because those are. The end points they're getting hit that are trying to do. The handle the issuance and whatnot are expecting those things in place. So some of, some of the code that I have put in there, I think is just very temporary. Okay. Like the code that's in. Yeah. That's it. Right. I just got the other profile. That's it. Everything else is test code. And again, it's basically reusing stuff and just having a couple of kickoff points. So there's not a lot of new code really. Okay. But the plan is to go next to making the existing endpoints work with these tests. Yeah. And then, and then we can start. So I've basically turned off a whole pile of existing tests. And I'm just going to go back to the endpoints. I'm just going to go back to the endpoints. So that was the only way to get to work because we know those endpoints aren't working. So, yeah. So once this is in with these tests work, then it's to start going back and re enabling. The. Old tests as we transition the endpoints that they're using to get out to date. So hopefully by the next one where we say, okay, these endpoints that aren't working. Get transitioned out. So that's kind of an all in on creds kind of underneath the covers. Got it. Excellent. Okay, good. This one, let's talk about this one at when we talk about peer bids. This is ready to go. Right, Daniel. Yeah, there's some unit tests that I need to sort out. And there's some quack caching questions that I'm considering in terms of where caching should be occurring, whether it's at the global resolver layer or at the global resolver layer. Yeah. So there's a couple more things that I'm. Working on here still. Okay. But we'll talk about this one. So 2404 is in. So this can now go. I've re based this and everything. It's just adding some additional work. Yeah. Okay. No progress on this yet. We'll talk about. Yeah. So we'll talk about. Ciro's work in a bit. Jason's work in a bit. No movement from me on this one either. Who's got this one? You've got this one as a reviewer. Yeah. Okay. And then we're going to leave this one for now because this will play into. What's happening with the tales file anyway and all that. So we're going to leave that one for now. Okay. Of these. Do we want to get 2409? Would you like that in zero 10? If we can, I think that would be great. Okay. Yeah. And if you could look at this one, we could also see about helping this guy out and whoever this is, this person out and getting it into. You know, this is not dangerous. If you think it is questionable and want to have conversations about it, we can defer it and make sure it stays till after. Zero 10. We have deployed zero 10 RC zero. Didn't have any issues with it. Do you think we would do us RC one. Daniel, before we. I think these are the ones we've merged 2404 and 09 are safe enough. I would probably feel more comfortable having a release candidate out to test against like plugins and things. Good. We're going to a final. Okay. So I will do. Wait for 2409. And then do an RC one, and then we'll go to final. Okay. Good. Okay. So the next topic is the next topic. So. 2409 first. RC one. And final. Okay. And on credits progress. This may be a shorter meeting than I thought. Okay, good. And I'm correct. Progress next steps. I think. Jason, you know what you've got. On that. Okay. So the next topic is the next topic. Which is getting the. Existing. Finish off PDD tasks. And then existing. Existing end points. Yeah. Can we coordinate. 2411 merge main into you and on credits RS first. Right. Well, yeah. Alright. I thought I might do a little bit of background. Yesterday, just to try it and see there's really not, most of the stuff is going to be pretty straightforward. Cause it's just like comments and read me's and blah, blah, blah, pretty straightforward. But. It's probably Andrew and Daniel. Tap. Take a look. It's ask our profile. Court conductor ledger based revocation manager, revocation models issue or Fred Rev. Has stuff in there that I think. I don't think too long, but I could be wrong. Are those all tied to that one update? Are that, is this all tied to the change Andrew made? Yes, yeah. As far as I can tell anyway, yeah, there was just kind of two things going on at the same time in exactly the same areas. So yeah, as far as I can tell, that's where the real impact is. Everything else is pretty much straightforward. Which is good, not a lot of merge conflicts considering how many things have been put in there. But, and I think between the two of them that know what the beyond factors are, it shouldn't take too long, but. Logistically, how does this work? How do you do this? I'm not a pro at all that kind of stuff. So I'm sure there's many different approaches. I just did it as a sample as I merged main into a non-creds RS just to see what the differences were. Yeah. I think, well, the other way, I don't know. I think you can do it kind of a bunch of different ways, but. I think the key thing is mapping changes that were made in the IndieCredEx stuff. Mapping those back onto the non-creds things and accounting for the slight differences between the non-creds RS and IndieCredEx library. Yeah, I think it will require just having a little bit more background with the changes. This has been something that I've been planning to do. I've intended to do this, just kind of been focused on the 2409 and 2404 stuff for the moment. So once I get those cleared up, I can take a look at these. Okay. I was more wondering what the get, what's the get process? Like how do you merge these into the branch? Do you just go PR by PR and merge them in? We would just merge main into a non-creds RS and just address any merge conflicts at that point. I don't think it'll be. The get process itself is straightforward since it's just the one action, but yeah. Yeah, I've just been cherry picking stuff as I needed to get to the BDD test stuff kind of working. So there's a few commits, but I don't think you'd want to cherry pick via like 60 or 70 commits that have been in. So yeah, it like I said, like just the, a lot of files change, but really there's only like those, those are the only ones that were in conflict that were like logical. Like as Daniel saying, there's some stuff that's changed everything else is pretty straightforward. So yeah, I'd like to see it get done before I start adapting the end points. Just because I think that one, I'll be trampling on some existing changes and stuff like that. So just easier for my little brain if it's clear that before, but. So Daniel, you get that one? I was intending to at least. I think the changes on 2409 I'm probably gonna take at least another day or so to wrap up things there, I think. So I don't, if it makes sense to, let somebody else handle that, then sure, I'm fine with that. But if I'm the first one to get to it, I'm happy to look at that. Andrew, do you think you have time to do this one? Not sure what's required for me on this one, just the merging, I mean. Yeah, so what'll happen is merging main into the non-credits branch, we have the two branches, but what's gonna come out of it is there's gonna be the non-credits RS branch. What's gonna come out of that is all of the changes that you made for getting after the CL signatures update that got pulled into credX, those same changes have to be resolved in the non-credits branch, because they're in the same place. Yeah, it wasn't a huge set of changes. Yeah, that's what we're seeing. I don't know if there's been a non-credits release, but it's mostly seemed to have put the same changes now as in credX. I thought there was a release of a non-credits. Checkmate. Shoot. Yeah, it was just a 010 release in a second. I think Keef did some work, but maybe it's not been released. Are you thinking that, Steven? Well, I know, yeah, so his release has been, or his PR has been merged. So we've updated to CL signatures 02, we just never done a release. Sorry, credX has a release with the CL signatures 02 stuff, but a non-credits doesn't yet. Okay, okay, so that's needed sooner than later. Can we just do a 02, or, well. Okay, so that's needed first. I noticed that the JavaScript wrapper, there's an open PR for that in the non-credits RS. I wonder if that's what's being weighted on, getting that in so they can have the changes updated in that wrapper. Yeah, I think that makes sense. Okay, and then there's the question of the master secret, link secret, formatting is a string right now. Okay, so at least if Andrew, if you could take on that one as a priority, I don't know how it fits with the other work you're doing, but add that to your list of getting this done. And then if you get to that before Daniel does, it gets to this one. If you're able to get to this one as well before Daniel do that one as well. But the main thing is for sure, I think your expertise is needed on getting a release of a non-credits RS done. Yeah, I can ask. Yeah, we'll work pending there. Okay. Yeah, I wasn't certain if the non-credits RS implementation is meant to replace the Indian credX one in Akapai or? Yes, yes it is. Okay, but like doesn't that create a problem for issuers that are doing the Delta-based revocation? So that's a topic we need to discuss because I don't understand where that comes into play. So when you say issuers that are doing Delta-based revocation at the level that most people are interacting with Akapai, they're not necessarily aware of the fact that they're doing Delta-based revocation, right? So the approach that we took in the non-credits RS stuff was that we would, in the generic a non-creds ledger agnostic interface, we would treat changes as if they were happening on full revocation status, whatever we're calling them. And then in the Indie and the legacy Indie and the future did Indie, a non-credits registry, that full status list would just be mapped to a set of Deltas. And then like each operation that is done to change the state like publishing revocations or revoking a credential and then subsequently publishing that interface, it looks more or less the same as it did with the Delta-based since that was kind of a detail that was hidden away from the controller layer anyways. So it translates from ledger agnostic to Indie specific idioms, I guess, in the process of using the Indie ledger. Okay, great, glad nothing needs to be added to a non-creds to support that then. I mean, I think there might be some things that we could potentially say could make our job easier in terms of like mapping back and forth, but I don't know that those necessarily are changes that are needed at the non-creds layer to support that or not. Yeah, I mean, it should be possible to translate those things in Python or just the accumulators already is not gonna change. It's just the issued in revoked indexes. Right. Versus the bitmap, I guess. Yeah, so I think the only thing that we had to do that was like maybe a little strange was we needed to keep around the previous accumulator since that's not something that's tracked inside of the non-creds RS object anymore when it was something we needed for the Delta's or something like that. It's been a while since I looked at it, but yeah, I think it was possible. Yeah, that makes sense. Yeah. In Akapai, so would we for each registry have to maintain the full state in Akapai? As it happens, Akapai basically already was keeping track of all the credentials that had been issued in revoked. Yeah, India SDK does that, but then it hides it from you. Yeah. Okay, that's what I was worried about was that the issuer wouldn't know the state, but obviously that could be a retreat from the ledger if we really have to, but you're saying it's already in Akapai. Yeah, that was information that was being stored and used for processing otherwise anyways. So yeah, it was already available. Does that alleviate your fears, Andrew? Yeah, yeah, I just wasn't sure if there was compatibility with the Deltas now that status list is being used. Okay. Sounds good. Okay, good. And to be clear, we're eliminating the endpoints that allow the controller to directly control registries that all the handling of the registries is within Akapai and the controller doesn't have any say over the actual handling of the registries, the creation, the update. Okay. The controller just says publish. The controller just says issue and when you run out of one, a new one gets created. The controller says revoke and that gets put into a pending queue. The controller says publish and by cred def, published by cred def and all of the registries that need to be published are published and the controller doesn't have any access to those. So that's the big change from a controller perspective. Okay, so this is a conversation that sort of came up yesterday with Andrew and I. So we're happy with that, which is good. So I'm not gonna create a new issue. We're just gonna assume it's covered. Should I document that at all? I think we're okay. Yeah. We're okay. Okay. It'll be covered by unit tests, I imagine. Yeah. Oh, we got a new one. 12 minutes ago. There is a. Ariel has a JS update. Okay. And these two are old and probably not gonna get put in. And on cred RS, I'll add some notes in here. Is this the right one? This should be credits. I'll document this after any other issues. This one came in. So there's a, should there be an endpoint that allows a connection alias to be updated? So that's, I think Lucas just wants to get his hands dirty a little bit in the code. So there's a plugin that I wrote for traction that does exactly that. Yeah. So. But it does make sense that in Acopi it'd be allowed. So this would be extending one of the existing endpoints. Yeah. Existing, I don't know. I think it's, there might be a whole new endpoint anyway. Oh yeah, there's no, yeah, I guess not. There's no endpoint for connections. Yeah, I don't think there's anything to update connection data. So this is basically putting it, I think I put in there and then it only allows to update the given field. And then what fields are you allowed to update? Alias. There's nothing else that makes sense. I don't think so, but if I remember correctly, I think we just kind of just changed the validation. If we decided to add in another field, we just changed the validation on that to say, cool, here's new field, whatever. We, in traction, they just needed to be able to do that because yeah, people can't decide on what they want to name their connections. Yeah. You may want to change the name of your contact in the list, that's kind of like the idea. And that's where it's derived from. Yeah. I mean, to me, it makes sense. So we'll see where this lands on a BCGov priority, but Daniel, Shar, Andrew, you don't have any objections to that being added? I don't think I have any objections. The connection alias feature is not one that I use frequently or have seen in use frequently. So it's not one that I generally pay a ton of attention to, I guess. So, but yeah. It's benign. Yeah. Okay. Yeah, I don't really see why you're updated after you created it, but it can hurt, I guess. Yeah, it becomes obvious when you're using traction itself because that's, you've got a whole list, you see visually your whole list of connections and that's the most important visually to an end user. And it becomes pretty apparent that, oh, this isn't exactly what I want to name it. So it's either, when we first did traction and it had its own database, all that stuff was done in its own database, but yeah, so yeah. I mean, it doesn't really impact the actual workings of Hacopai. Yeah. The pagination, I removed the Enoncreds on this just to move it into a later broader topic. Okay, I don't see anything else that we want to prioritize in these. At some point, I'm going to go through all 217 issues and kick a bunch. I took a look at the very, very old ones and I realized I've done a culling of them because the very, very old ones I still think are not, worth keeping around. So perhaps someday they'll be gotten to, but so some culling has been done, but it's time for another pass through a bunch of the more recent ones, last six months probably. Okay, that's all I had. Any other topics people wanted to discuss as far as open discussion issues? This open API, did that actually get resolved with? No, that kind of fell off my to-do list. I recall the Marshmallow updates came in from Moritz, I believe. Right, yeah, he raised a point that there are some inconsistencies with the open API and what was actually being expected. I basically told him, I looked at this, I didn't find a really super favorable answer to the issue that you're addressing. See if you can come up with something better, I guess. But yeah. Okay. Okay, we did resolve the IndieTest server, we got a new release of that out, it's been tested and merged into the, or being used by the new, by the new BDD test, so that worked and we've stopped running IndieTest, so there you go. Okay. Um, we had planned a meeting, Daniel, Jason, Sarah, Tuck and myself on did peer work, so people are welcome to drop off or stick around to listen to that as we progress into did peer discussions. Up to you. Woot. I'm gonna leave it on in the background so I can get some information in my brain, but I don't think I'll be contributing what you guys are talking about, but I kind of need to know what's going on, just fill in some gaps, so I'll be here, but probably not yapping. Yep. Yeah, I'll stay on as well. Okay, first let's start with, so what we're trying to do is align where Jason is on the peer did work. Make sure we're all in sync on what's left to do and try to sort that out. 2409 comes into play because this has to do with did resolvers and connections in peer dids, so we wanna look at that and then just nail down what we're gonna do with transitioning from unqualified to did peer two and three dids in the future. So Daniel, why don't you start with this one? At 24, Otters and 2409. Yeah. Okay, so to provide just a little bit of background of why I'm working on this, I'm working with Sikba, they're really interested in enabling did communication over did web, dids. So I've been pushing on that front. There are a bunch of recent changes that made it so did web could be used in more contexts within ACCPI and it was like really close to being possible to exchange those in a did exchange protocol. So I started filling the gap between where we were and having the opportunity to send when you're doing a did exchange request to just put a did web did in the request and then the response also being able to put a did web did and omitting the did document from the did exchange request. So that's ultimately the goal of these changes, but the fix ended up overlapping a little bit with the peer did work that's going on in parallel. Yeah, because when you said it did peer two, that's all you send is the did, you don't send the did doc. Right, exactly. So in order to support not expecting a did document to exist within a did exchange request or did exchange response, I adjusted, let me look at the changes here just to make sure I'm grounding myself. So I adjusted the way that we do resolution of inbound connections. No, sorry, I didn't do that yet. Did I do that? The more important part is the resolving of connection targets or how do we determine how we send a message to one of our connections? So if you scroll down just a little bit further in the base manager there, I added online 336, a resolve connection targets. Which will use the did resolver interface to resolve a did and then extract connection target information out of the did document that is resolved from the did. And then 2404, I added a legacy peer did resolver. So something that was looking in our own wallet to pull up the did doc that we stored for connection. And so that combined with this change makes it so our lookup of connection target information is consistent regardless of whether we are resolving the did or if we're doing like a wallet lookup for a did to determine that information. Okay, so let me make sure to figure out, I'm about to send a message to a connection. I go to the connection rep and grab their did and then I call this function to get the endpoint recipient keys and routing keys for the message that I'm gonna send. Right, okay. So in fact, I do use the did and then the other thing that that clarified for me and again, I'm really starting from nothing because I don't code. We have a set of connections but we do also have a set of did. So the connection does not contain the actual did doc information. The connection simply contains the did and we have another data model or data collection that is the set of dids we know about and the did doc. And the did doc. So that's how the two work together. Okay, yeah. Yeah, so let's see, scanning through kind of some of the rest of the changes that were made in here. Yeah, the other changes are more specific to the handling of the did exchange requests and responses. One of the interesting things is with didconv1 since we receive messages, two keys and the sender of the messages are identified by keys like the base 58 encoding of those keys. We need to map from key to did and then from did to connection in order to associate an inbound message with a specific connection. Right. So even when we're resolving dids and not parsing a did document that was received in the did exchange request, on receipt of the did exchange requester response, we still actually need to resolve the did to extract the keys and then to store a mapping from those keys to the did so we can later associate connections with those keys. Okay, and let me understand that by playing that back to you. When I receive a message, the message contains the key that was used to encrypt the message. Yeah. It doesn't contain the did or a reference to the did. It contains the key itself. Yeah. And what I've got to do is figure out what connection that's associated with. And I do that by, but the way that's done is there's a key to did mapping and then a did to connection mapping. Right. Okay. Yeah. Okay. So even when we're receiving dids there's a resolve stuff that needs to take place during did exchange to make sure that we can actually complete the connection at that point. What I was trying to figure out was I had sort of, when I was tied to Jason, I sort of put down, there's the did, the unqualified and peer did processing when you establish a connection when there's a request and a response but I was questioning whether it was ever used again and now I know it is used again. It's used when sending because you start with a connection and then on receipt you start with a key but you go not from the key to the connection but you go from the key to the did to the connection. Yeah. Okay. Thank you. Yeah. Yeah. So this PR just makes it so when we are receiving those dids we can determine the information required to send a message to it, the connection target in a way that is consistent regardless of whether that that did is a peer did or a legacy peer did in this case or a public did that's resolved off of by following a did method, whatever. Yeah. And then you're getting the caching comes into play because you've got to figure out how long before I go and grab the did doc again you're going to keep a copy of the did doc locally that did web did doc locally but you don't want that to become overly stale in case the did web has been rotated and you weren't notified of it. Right. There's no push notification that it did web has been changed. Right. Okay. And even in slightly shorter time frames in the process of completing an issue credential protocol there's several messages sent back and forth in that process. And if you're having to resolve the did web each time to determine how to send the next message that's of course less than optimal I guess. Yeah. Okay. Now of course if it's a did peer there's nowhere else to look for it. So that's a non. Yeah. Okay. Now one other question which is these collection of connections in these collection of dids have they existed all along? I think I gather that they kind of evolved over time. Is that the did mapping and then the did connection mapping have independently existed like from the beginning? Right. Pretty much. So yeah, they've been around a long time. Okay. And then the same idea of going from a connection to their did to find the did doc to send it that's all existed. Right. With the only change here being that rather than always looking in the wallet for their did doc information we can also resolve the did doc information. And we do that by looking at the did. Yes. Yeah. The did method basically. Okay. Yeah, the did is the key in the lookup of the did doc. Okay. Now the other thing, Jason I don't know if you looked at this but in here is a legacy did doc correct directions. Yeah. Which is something I think hang on. I don't know if you guys Yeah, that looks pretty simple. Simple, similar to what I've been doing with. Yeah. Yeah. Verification method, troller and then extracting out the authentication to reference the public key, which is no. Yeah. And that's pretty much the exact transformation that I wrote. Yeah. Okay. So that's now exists. No, is that limited? That's not limited to like what's it called legacy doc corrections. Yeah. The scope of this is what we discovered but what we realized is that yeah, the existing legacy did doc was only used in the connection context. So I was worried about a bunch of a wide variety of did docs that may have complications or may have things that we didn't foresee. But if they're all connections then there's a very simple transformation that gets done, which I've updated my branch to have but I think it's probably got a similar scope to what you've handled here and it's probably redundant. Okay. But I'd have to look closer at exactly what you're looking at. But in your input output example, that is the exact result that I was working towards as well. Okay. So now we're kind of covered. So what are the issues we've got? So what we want is that on receipt of a request or a response, we wanna be able to accept unqualified in deed peer two and deed peer, sorry, unqualified in deed peer two. And then- This is on receipt of a message from an existing connection or from a connection? On receipt of a, so the way I see it, there's the, where's my list? And I was gonna write this out, but I'll hang on for a few seconds. I think that's part of that. Just one sec. Apologize. Okay. So currently on, we've got basically with did exchange, we only handled unqualified dids. Daniel, you've now changed it so that we actually can handle any did. Presumably it still handles unqualified dids, correct? It does, yeah. So if you pass your did doc in the message, it will store it as it did previously as an unqualified value. Yeah, that whole thing, yeah. Okay. So what we now wanna be able to do is be able to receive a peer did two in the request or response. Right. Right. And that I don't think would be in the scope of your work, which is that the connections rely on this custom did doc class and a whole bunch of weird management, specifically the fact that the IDs of the documents themselves and the did themselves have no prefix, which throws off pited library and a couple of other things that has made the transformations. Yeah, have been rough spots that I've had to write around and build around. So I'm trying to figure out how... Well, but this... But hold on. It's not done. But hold on a second. The scope I'm talking to in this conversation is simply did exchange, receive a peer did and be able to store it. Yeah, that's easy. Yeah, yeah. That's the connection. Correct? Yeah, yeah, yeah. That's the simplest case, which is both sides are sending and expecting to peer dues. With the one conversation that Daniel and I were having a bit back and forth this morning, which is, do you call there did the did peer two or the did peer three? Do you ever reference did peer two again? Right. My thought... I was a developer, I would expect there did to be the very last thing that we received. So if the last thing received was a did peer two, but I think that's an error in the fact that, yeah, if you receive a did peer two, I think we should assign the did peer three as the there did property. Because the other thing is like, does the controller, does the admin ever need to investigate the did peer two? Should they even be able to see the did peer two, go resolve it themselves and then look at it? And it's like, and none of that information should matter to them. It's all encryption keys and the service, right? So no, I don't see any value and any reason to ever store a did peer three under the there did property of a connection. Did peer three or two? Sorry, did peer two, it should always be a did peer three because all it is is the shorthand of basically what's left about the encryption using and how do you prove that it's the same person you talked to last time. However, is that weird that that might change? I mean, I guess it's true of any case right now. When they go into key rotation happens, but that's true now. So that might always change, which is fine. So Daniel, what do you think of that? So what we're proposing is that on receipt of a did peer two, we would actually resolve it according to the rules, which is just a transformation. It's a text transformation. And store that with the did as the identifier being the did peer three and the did doc being the expanded did doc. Yeah, the resolution of the did peer two. That seems reasonable to me. I don't have strong opinions on whether that did peer two is what we store or not. And especially if we intend the did peer three to be what we identify them by in the long term. Yeah, I think it would make sense for that to be what's stored on the connection. Yeah, because the other option is right, like you receive the first message and it's a did peer two. And then when you receive a second message, it's a did peer three or it like stays as a did peer two forever, which seems weird. So yeah, I think transforming it and saving the did peer three right away makes the most sense. And then the question comes to has anybody written a did peer two to did peer three conversion? And that sounds like something we should probably add to the peer did library, potentially the pilot library or probably the peer did library, which I haven't looked into because I've been just taking the did peer two and running with it. I haven't listed that conversion there. So you calculated did peer three by just taking everything that comes after did colon peer colon two and then hashing it and then doing a multi base, multi hashing coding of that hash and that is your did peer three. Yeah, I figured it was a simple, a relatively simple operation given that's the whole point of it. But I have not looked into what that is. And I, yeah, I certainly, certainly can or I can look at proposing that peer did library. So I will, so as well, as long as it's well specified and I can figure it out, then yeah, it should be pretty simple to do. It's just that, yeah, the multi base encoding has been new to me. So I'm trying to figure that out. Okay. And then the only other, only other issue that I would see and it really doesn't come into effect in, okay, so let me keep going. Let me keep going with the steps we're going through. So we've got our current state, we've got did exchange, which is I receive a peer did two, I resolve peer three, I store that in the connection for their did. My did, I also store as the peer did three. When I create one, I store the resolve peer did two. I store it my did as a peer did three and so on. Okay. So that's good. Then after that, I'm still going to go by the key and the mapping. Yeah. I don't think we need to change that structure. You receive a key and you look up, then you work from there. That's the, then the next thing we do is we add a flag that says use peer did two, three. Yep. As a startup parameter and in that exchange, in that the only thing that changes is that the did exchange request and response sends a peer did two instead of sending an unqualified. Correct. Yeah. The, yes, that makes sense. Yeah. I think the complications, sorry, the complications arise from upgrading existing agents. I think starting with agents that both understand did peer two, did peer three, I think that's what I think we're, I think we're on the same page on that. And I think you, you described it well. So up to there and then the last step I had is the upgrading unqualified dids to did peer two or three, two or three. And that's- Yeah. So you have a connection that's long lived and then you upgrade your agents and now you decide you want to promote or like migrate to using these did peer two's and threes. How do we do that? And that's where most of the complications come from because you have an existing did doc that might have a different shape because it's using an old model. And that's where some of this did legacy doc correction comes in and things like that. So sorry. Okay. So first of all, my thought was if we, if we upgrade an unqualified did we would upgrade it to a peer did three. Yeah. You would. Yeah. The method has been what I've been trying to do and this doing this conversion in the way that I think you might have taken the same approach I did which is like, how do I actually move these objects around? And what I've now been doing and what I did the last day was just extract what you needed to generate the did peer two and just go generate the did peer two and throw out the old structure in the old document because you have the key and you have a service object just to pull those out and use the peer did library to create a did peer two and created a did peer three which we have nothing to do with that force but that's fine. That way you can actually remove a lot of the complications of the document you're trying to convert because we're only using it for connections which means you're only using it for did peers. And that was the code that I was writing as of the day I left was what if we just take what we need and throw out everything else in the old did doc because those are the only two things we need. So I have a question. What benefit do we actually gain from updating old connections to have a did peer representation? Because when we're actually messaging between the two parties we never actually talk about the dids again. Those are never actually visible except where perhaps when you're exchanging JSON all the credentials and you're trying to bind the credential to a specific did or something like that but usually they would derive a did key from their keys and provide that instead of using a connection did. Right, so I don't know the usages of that. You clearly do know more. However, the data class that's actually getting deserialized out of storage. I think we then have to sit around forever and handle two instances of that class that have different members and different accessors and then your codes that got conditionals everywhere rather than writing a conversion method that says if you see something that's weird just go up to either the new did peer and then we can use the pie did classes throughout and keeps the implementation I think much more much simpler. So I think there's an implementation on a maintainability advantage but I think you're right in the fact that yeah, if you could perfectly handle it all the old stuff is still valid and if we still know how to read from it then off we go. It's just that I wanted to avoid having, oh, let's use the pie did did doc here and let's use the old doc here and like have a whole bunch of conditionals everywhere. That was the main concern. That makes sense. So with the 2404 that PR that I put in the legacy peer did resolver will transform as we looked at will transform the input did doc. So the one that's retrieved from storage into something that is valid and pited but accept as a did document. I think those corrections are also non-destructive in the sense that like if it pulled out the document and it was already in the correct shape it's not gonna change it again. Correct. Yeah, that was a key thing as well in my writing of it. How are you, so the simplest example so how are you handling like pulling a did doc out that has an ID without a prefix? Because there's did docs that exist in storage that don't have that just are that their top level ID field is unqualified. Yeah, like that that number won't have did solve. Yeah, I think those I've been inserting did solve. And yeah, I'm sure it's not an issue but I think inserting did solve is not the right thing to do because did solve is an indie did resolver resolves to indies. Yeah, right. So what my approach was Daniel was to not try and convert the object to object just extract what I need and create a new did peer to using obviously basically from scratch using as though it's a net new thing. Yeah, it's basically a different process to me. Yeah, which I thought was going to give me more stability and less handling of the details because what we discovered Steven is that again this is only used for connections and connections only have two or three things we care about and let's just handpick those pull it out create and then use the standard creation process as though it's brand new and then just replace the old thing. So let me explain for a moment some of the reasoning behind adding a did solve here because I think it probably makes sense even though it's semantically incorrect for that to be a did solve did and the main reason is because that's how acopai has been treating these as a did solve whether it's been posted or not. So actually when I was implementing this resolver here the regular expression that matches this resolver against dense to resolve and the one used by the indie resolver are actually exactly the same except that in addition to checking if the regular expression matches this resolver will do a quick peek in the wallet or in the cash to see if it's a local did before saying no, I don't support this and then essentially delegating to the indie resolver like this is probably posted or a public did so you can handle it kind of a thing. So I think this already relatively well handles both qualified and unqualified dids of posted or not posted posture, if you will to use the language used here in acopai. So it's, so for these unqualified dids I guess what I'm feeling and I don't I'm not like super strongly opinionated on this front but what I'm thinking is it might be simpler just to leave these as is since we already have a mechanism here for translating these to more modern sensibilities of how we should handle and process the documents and how we should extract didcom information out of them. So I don't know that I see value in going through the effort of updating these. So Daniel, so you're doing this as an on the fly transformation. Yeah, it's taking the value out of the wallet and then transforming it as it's resolved, as it's needed. Which means, okay, so right now in the did collection the ID for these would be the unqualified name and call string and in the connection the there did would be the unqualified. Correct. It's only when we are actually presenting when we send a did doc that we add the didsoft prefix but it is being added at this point. And the only issue I see with that doesn't come into play until we go to didcom too. Right. Right, so my question with this approach is if we do continue, if we do convert the doc on the fly you're gonna end up with a, is it correct that you're gonna end up with a connection that has a did pure three as the identifier but when you actually go look up the document you've stored the ID in that document is gonna be a did solve a field unqualified one. No, what Daniel's saying is we're never gonna update the unqualified ones, we're just gonna leave them like this forever, right? Oh, okay. And that on both sides when you see an unqualified did do you stick a did solve in front of it and be done with it? And that did solve would live throughout the entire code base because that's the other issue is the like acupyze handling this like on the fly constantly and being like, oh, I'm saving it locally. I'm gonna take the did solve off. Oh, I've got to show it publicly. I'm gonna add the did solve. And I was hoping to polish all of that and the plan is just to add did solve and leave it there forever. Even though it again, like you said it's semantically incorrect. Yeah. So when we transition to using did pure the did doc class as it exists should be we should be able to just remove it since we're not needing it to take values that we're receiving in messages and then serializing it and all that stuff and storing it. Go number one. Yeah, I agree there. Yeah. So it's and I think that did doc class and its associates are the main perpetrators of the qualified versus unqualified adding prefixes and removing prefixes. I think they're the main culprit on that front. Yeah, I guess I'm also yeah, I guess I'm looking at it going we now have a rigorous transformation that we think will work to get every connection to have a did peer. Exactly. Yeah. Why leave and the skeleton in the closet that might confuse somebody later even though you're right it probably would work forever. And yeah, sorry. I just know. Yeah, the semicolon India is the delimiter. Yeah, you changed that. Okay, good. Cause that was the other thing that made no sense. Yeah, I think that's kind of my thought is yeah, we could leave this as did sob forever but in a year somebody's going to go, oh, did sob. I mean, we'll go look it up on the ledger. Wait, how is it? And nobody's going to remember that we had this weird quirk, right? And then it's just kind of out there forever. I guess it's my and I'm more worried about it that it's going to well, I'm worried about the comm to transition. Also, also what we end up in a situation where you have a resolver, right? And we see what's the ID and we're just going to pass that to a resolver and the resolver is going to go, oh, it's got the did sob prefix and it's going to handle it that way rather than giving it the proper prefix and the proper type. I'm not sure I followed there, but so I think leaving these as is is a bit of a closer reflection of what these were, what these are and that there's static connections that there's no mechanism for updating the values. And there's no need to update the value values associated with them on either end of the exchange because the connection information, the endpoints, the keys are still the same. It's just whether we've stopped using that structure in our wallet or not. That's the only change, right? Which I'm all for deprecating things and getting rid of the old and I'm not in favor of updating the structure of these did docs within our wallet, but I think they would still remain as unqualified dids and I don't think it would make sense for us to try to retroactively update these to be did peer resembling values. And on the didcom v2 transition question, because these are static, there's no way for us to update them. There's no way for us to communicate that we now accept didcom v2 to these existing connections anyways. So I think that would be- Sorry, there is one operation that would change, right? Is in key rotation something that? Key rotation for these legacy dates is not supported. Key rotation for these would be did rotation. Right, okay, be did rotation, okay. Okay, I'm not sure I understand that process, but it's the only thing I've been warned could change after establishing a connection is that one side decides to rotate the keys. But if that's in the fact that I've misunderstood, that's fine, I'm just going through anything I can- That theory is supported, but it's not supported by did peer or unqualified. Interesting, okay, I see, I see only for the publics. Right. Publicly published, I see, okay, makes sense. Yeah, of course that makes sense. Okay. We have like the crypto capability to do it as well, but we've never gone through- Yeah. Defining the protocol for sending those updates and changes, so. So, I mean, we debated a few months ago, prefacing these with did legacy peer, which is essentially what you're doing with did solve except using, well, essentially what is being done, not saying you did it, but you were following the pattern, which is essentially the same thing, but this is to me worse because now we're confusing it with the legacy. The actual meaning of did solve. Yeah, the actual meaning of did solve. Yeah, I guess it's not any worse in my opinion because that's exactly what was confused before, but I get your point now. Because you could change this process to be, so that we wind up with this being a did peer two, the output being a did peer two. Yeah, which is what my most recent after many attempts, my most recent implementation does is goes, oh, like this document's old, let me just reconstruct it with the key details starting brand new as those that did peer two. And using the libraries and using that to get consistency and predictability rather than holding on to edge cases. But yeah, this is almost identical to what I had a couple of weeks ago. And I haven't obviously haven't looked at this pull request, but in the attempt and in purpose, it's the same thing. Let me ask a different question. So, well, so you're suggesting Daniel that we just continuously do this on the fly as opposed to actually changing the stored data? I wouldn't be against doing a migration step, like in using our usual upgrade scripts, that's the word I was looking for. And just changing the stored did documents to be something that's a little bit closer to what the output would be from this. I'm not against doing that at all. Okay, so the other piece here that we kind of determined, Steven, and maybe I'd love to make sure that Daniel on the same page is the exact shape and structure in which the did doc is saved is only relevant to the person who's saving it, right? Like the entire like JSON structure, somebody could save in an entirely different method. And as long as they know how to read it, it doesn't really matter. So that was one reason why I was more comfortable with like a permanent conversion is knowing that there is no exact perfect shape that everybody uses. It's just as long as you're storing, it's more comfortable, obviously closer to better, but it's not guaranteed or not mandated to be the same. Okay, so let me test out something that I'm thinking through right now. So for a did come one perspective, it doesn't matter what we call it or where we store it or how we store it for the exact reason that we always start with a key and we go to a did to a connection. So as long as that path is there and when we send out, we start from a connection, we go to a did and we go to a did ID and then we get the did doc and then we get the key from that. So from a did come one perspective, it does not matter. Do we agree with that theory? Yeah. So if we were to migrate these, it would make no difference until we converted to, until we started using did come to agreed. And it did come to, I don't even know if on receipt of a message, it would make any difference, but I believe that we would put their did and our did in or to did and from did into the message itself. So we start to expose that in the messages themselves. Correct? Right, yeah. And if we did that, we don't want did sob in there. Right. So I guess the primary question I have in response to that is do we intend for existing connections to be able to all of a sudden start talking did come be to or will we have to establish new connections before we are ready to begin talking did come be to. I think we have to assume that it'd be interesting to know what they're doing in AFJ, but I would assume that we would have existing connections which would upgrade to did come be to. How do we indicate readiness to receive did come be to same way? We're going to go from unqualified to did here too. We're going to. And then we coordinate it. Really coordinated update. We begin by being able to accept did come to connections and then transition to using did come to by default. So there will be an upgrade day where before we go down, we're talking all did come be one. And then we can start it back up and then we're by default at least talking all did come be to to the same set of connections. Yeah, I guess where I'm getting to is less about how that happens, but more about the fact that since it doesn't matter, why don't we go to since it doesn't matter in did come one land. Yeah. And it did come to land. We don't want to be showing did solve for these things. Because that's definitely a occupy specific thing. Why don't we just when we do the migration? We in the upgrade script, we go from unqualified to did peer three. We upgrade the connection there did my dead and we upgrade the did to use did peer three. I think that makes more sense. That is the way that I've been leading is to try and convert everything to do peer two as we go. Yeah. And we just ignore it. And as I say, because it doesn't even matter in did peer one land or sorry, did come one land, the use of dids and the did doc is all internal to the occupy agent. It doesn't flow across. Yeah, I. I don't know that I I'm not a fan of the. The looseness, what I'm trying to articulate when I'm feeling here. I I'm not a fan of we just, you know, all of a sudden we magically are aware that our remote connection has this corresponding did peer three, so we should be able to identify them as a priority, existing connection. Like I it's a very like both sides just kind of have to know that that took place. So in my brain, it feels cleaner. It feels more in the spirit of the spec, I suppose, to establish a new connection with a new set of did peer dids that are clearly declared to be ready to communicate and it can be too based on, you know, the inclusion of accept parameters and did come service types and stuff like that. I'm not disputing that. I'm just. I'm not I'm not. Guessing how the transition from did come one to two will happen. I'm just saying that. Internally, it doesn't matter what we call these things. Yeah, and I definitely agree that that is the case. I guess I question the value of going through the effort to make that conversion if it's not going to do us any good, because even if we start just talking to come be two and we're like, hey, you're now this did peer three. But I never told you this previously. You just have to assume that you know who I'm talking about. Like that that transition just doesn't seem like it's one that we can feasibly make. So yeah. But what I'm saying is we want to transition into something we might as well do something that's fitting in a standard versus something that we're making up. That's that's the thing that's bugging me. It's bugging me. And so I'm saying that the only time it actually gets exposed externally is when we go to did come to. So as long as it's just internal, let's let's make it at least be a standards based thing rather than converting it on the fly and using the did soft. That's my thought. Okay, sure. I can. I think you've convinced me I would be. I am in agreement that. If we can have an upgrade script. That takes all of our locally stored did documents and translates them to be did peer three and, you know, adjusting all the prior math things and stuff to. Point to the correct connections. I would agree that that's better than having. Stuff that is. Like pseudo convention. Yeah. Yeah. So what I'm wondering is. Would this change this. This process. Change to being the. Take this input. Converted to a did peer true converted to a did peer three and resolve the did peer two to get this. In other words, this becomes. Did peer three. This becomes did peer three. Right. This is essentially the transformation that would be required for doing that upgrade. Yeah. And then that transformation you're describing Stephen as closer to what I have in my working branch, which is just extract what we need and create a did peer two as though it's brand new. Exactly. And then we can talk about two to three from there. I don't know if you would want the. The two. The two. I don't know. I think what we need for this is the IDs. So if that was. Keeps them as did peer twos, but I don't know. That was a sneaky introduction of a topic. I'll do that to me. Which is. I think these ideas should be deep here three. Because you're never going to see it did peer two after the initial creation. Yeah. So I think these and since. appear to string into this. These IDs can be whatever we want them to be. But by having IDs as did peer twos, you can always prove that the object has never been tampered or there's no errors in it because you could always be like, well, I think this is weird. Or I guess you could argue that's redundancy and you shouldn't do that. So, you can reverse the process. You can take the did peer to did doc, reverse it and verify that it comes out to the same did peer three. You can write, yeah, we talked about this. This is a triangle. It's not actually reversible. You take, you have the service and the keys, which creates you did peer two, which you can then convert to a did peer three. And you can always turn that document and extract the service and the keys and recreate that did peer two. But it's not, you can't take this object because we talked about this, right? Like you can't encrypt an object that has a hash of itself. You can't hash an object that has a hash of itself. Yeah, you can't. In this case, yes, you can because all you do is you extract this and you extract, you know, the... Public key 58, yeah. And you're done. Now you've got your did peer two and now you can verify that the did peer three that you get from that match is this one. Yes, you certainly can. And yeah, again, I would argue that's not a true reversal, but close enough. Yes, you were right. We could certainly do it that way. The benefit of that is that you guarantee that the ID or that your goal is that the ID of the did doc is the ID you're actually going to be checking it against. Exactly, exactly. Rather than having to keep something around that's like the did peer two is inside but look it up by the did peer three or something weird. I see the desire there. All right, I don't know if I've got a decision of what we need to do. I think so. I think I don't know how or who. I don't know what, because this comes merged, right? Yeah, but this could be replaced if you want it. Right, so I mean, is somebody looking to do that by itself or am I just going to continue with my branch? And so do it, so I definitely like, I don't know. It's not on my schedule at this point to do that conversion. I'll say that much at least. Right, and that's fair. Yeah, and now I guess I'm, it would certainly be easier to convert from this corrected document into a did peer two, which is if you look up a connection, did doc and it's not a did peer, just recreate it as though it's a did peer. That'd be the easiest way to look at that. Certainly easy to do. It would take, yeah, it's a very easy conversion because using it. I think what I would recommend is that we add a did peer three resolver, which just does a look up in the wallet for a did doc, right? And then once that's available to us, we can go through and do the upgrade script and that will change all of your locally stored unqualified dids to did peer three. Right, and then you can, this legacy period did stuff would be a brief bridge from now to that point, but then once it arrives at the did peer three, we don't have to do as much of the colluding stuff that I've had to do in this resolver because of the overlap between posted and unposted dids and their qualification or lack thereof. And so that would be a seamless migration to first do the did peer three, then translate from legacy to peer three and then. Okay, by upgrade script, do you mean a batch job or do you mean like a, just again, something that would upgrade on the fly as these things are going? Like an acupy upgrade script. So when you. Acupy has the content upgrade process. And you're talking like 0.9.2 to 0.9.3? Yeah. Gotcha, okay. Yes. Okay. I didn't know there was an opportunity for behavior injection at that level. Does that make sense? Yes. Okay. So what I'd like to propose is this. 2404 stays as it is. Your PR, the scope of your PR, Jason should include being able to receive both a, receive a PD2 and receive a unqualified did. If a deep PD2 is received, then send out a PD2 all to do with the exchange. Right. That the key processing and all that in receiving a message and sending a message works properly. Right. And that's as far as you go. Okay. So they did. So the conversion that we just discussed. I'm trying to think of that. And then the only big issue that I want to take to the community is what is the identifier that goes in the dead one? Did peer three. Which I think should be in peer three, but I believe in this back, it's did peer two. Come. So I don't know if you saw my last comment on that thread there. Didn't, I might have. I can, I can voice it to. Yeah. For brevity's sake, I guess, but I am at least personally of the opinion that if we resolve a did peer two, it should give us a did peer to did doc. And if we resolve a did peer three, it should give us a did peer three, did doc. And my claim is that, yeah, I don't think that's right. I did respond to it and I've thought about it. And I don't, I think that, I mean, we could put it also, also known as, but I think, I don't know, I get what you're saying. It just seems wrong to use the did peer two for anything other than the transmission of the did doc. Well, I'm not saying that we should necessarily use it for anything other than the transmission of the did doc. Yeah. But I think just purely from like correctness of resolving a did doc, I think it should always have the ID correspond to the did that was being resolved. But then from there, whether we use the also known as property or not, which for the record, I think is actually a pretty clean communication of, this is the same subject between these two dids kind of a thing. I think we can take that and say, okay, I've seen this did peer two. So I now know that this corresponding did peer three would resolve to this document that looks like this, which contains an ID that corresponds to did peer three. Yeah, I do agree with you, Daniel. I agree with both of you, which is that if I put in a did peer two, I should get the ID did three two out. How could anything else possibly make sense? But also in the fact that like did peer two is, is did peer two actually a unique thing? And Stevens arguing like, no, did peer two is just a shorthand for did peer three plus did doc, which I also see, but would not have agreed until Steven made that claim right now. I would not have gotten to the same conclusion. Yeah, I think we have to, because it's been written this way, at least to this point, I think we would have to treat it as a full on like did method and it wouldn't make sense for it to resolve to anything but its own did doc. Yeah. Because there will be implementations that continue to use did peer two in isolation as just the only did peer thing for a while at least, I guess, so. Yeah, to me, I would put, yeah. So the spec clearly would have to change. Yeah. Yeah, again. In which case, if we did have a spec change, I would push for us to change in the other direction that you proposed where it's just a did peer three with did URL, you know, fragments on it that or query parameters, whatever it is, that specifier that it corresponds to a doc. Really? That's interesting. I think there might be some quirks to iron out on that front, but like if we were going in the direction of changing the spec, that's probably, I would rather push in that direction than retroactively changing did peer two to behave differently. Okay. I don't know, Jason, if you saw that, but what I proposed was that instead of sending a did peer two ever, you do did peer three colon with the did peer short version and then a query parameter, question mark, you know, doc equals and then this identifier goes into that, the query parameter. Interesting. And then there's no question of what the purpose of did peer two is simply, you know, the purpose of that representation is simply to send the details, but the actual it is three. Sounds like it did peer four and that's a cruel joke. I'm joking. I'm joking. Interesting. Yeah, I guess I see the value, but is it worth changing? Yeah, exactly. But one way or another, if you get a did peer three, how do you resolve it then? Yeah, there has to be some. Look it up and if you don't have it, you throw it out, that's the only thing you know. Prior knowledge, yeah. Yeah, because you've got to have a way to receive a did peer three, look up and find the did peer two, did doc. Yeah, which is what you're saying is weird to you. That's why you want the results. Yeah, that's also. Which I understand is currently we're going to have to have two IDs for a did doc, two ways to look up a did doc by a did peer two and a did peer three. Which is where also known as would fit. Right, yeah. Which is also why I'm fond of that approach because like it, that you know, I am also known as this is really clean semantically, I guess. And not even necessarily exclusive to our usage in a did peer context as well. Okay. I would like Jason to be able to finish this. Yeah, that is on my list of things to do. So, if the scope, so we have to make a call one way or the other. What are we going to say the string is in here? My vote is down for it being a did peer two. Currently, what I think is the most expected and predictable based on the existing spec. I think if we, there's two things we could do, for example, we could just insert an acupy. We could just insert two references to the, to the doc, like double insert, but that would be weird. I don't know. I don't know the right way with the answers. We have to decide because we need to finish this. Yeah. We're going to make a call one way or another here. So here's the thing. We can receive the did peer two, resolve it to the did document and then not store it in the return state. We can store it as being a did peer three value. We don't necessarily need to, in perpetuity store the did peer two at any point and still have like all the benefits that we're looking for here and having the shorter form, right? Okay. So in the connection there did, what's it going to be? Did peer three. Did peer three. Okay. And when you, and when we do the feature did search, it's going to be did peer three. Right. Right. So when you query your wallet, when you query the database, you're going to give it a did peer three and it's going to give us a document back that is a did peer two as the ID member? No. What I'm saying is that we would actually transform that document into being one that represents a did peer three. And so the IDs and controller values would all correspond to the did peer three that we store. Oh, so we do, we do what Stephen says, but only in Acropyre and not as part of this back. Well, okay. So the did peer two in my mind still resolves to a did peer two document. But we know that this did peer two corresponds to this did peer three. And so we're just going to store the document that would correspond to the did peer three with the ID values being peer three. But it was derived from the document that we resolved through the did peer two. Okay. Let me try. If we ever receive a did, now the only time we're ever going to receive a did is in request and response. And we're saying we're going to convert those to did peer threes. Agreed? Right. We would never receive a did peer two any other time. Correct. Like unless, well, again, like the idea was like if you get a new did peer two on an existing connection you could like update the did doc. But that like, even that doesn't make any sense, right? It doesn't make any sense because we don't have a change. There's no method for it to change. Okay. So again, I come back to in the Acropyre did collection. The document's going to look like this with the only really question being, what is this string? And I think it has to be a peer did three because we might be, I might be splitting hairs in my attempt to distinguish between docs resolved from peer did two and doctors resolved from peer did three. But I agree that the stored value, the thing that we actually store as it did document within Acropyre should be did peer three. Did peer three with this value being peer three. Yes. Yeah. Okay. Okay. So if in Acropyre, we wanted to, we had a did and we wanted to know if we had a did doc for it. If you hand, if you ask for a did, if you ask for the did peer two or you ask for the did, if you use the did peer two or use the did peer three you're going to get the exact same storage object back. Daniel, is that what you want? No, if you gave it a did peer two I would expect it to do the exact same usual resolution. Oh, it wouldn't even look it up. It would just run the resolution from the left. Exactly. Okay. So the resolver goes did peer two while I don't even need to look in my storage. I just have to run this algorithm to process it. And if it's a did peer three, it goes, oh, that means it's in local storage and I have to go look it up. Yeah. Interesting. And the, yeah. And when we see a did peer two for the first time or actually in any time, you're going to say, do I have a did peer three stored with this? Oh, I don't. Then I'm going to go put it in my storage. If I already do, then great. I don't need to do anything else. Correct. Interesting. I think that's consistent. I think it gives us the simplistic advantages that we want with the implementation. It's a little bit redundant, but I don't think it's wrong. Yeah. I think it makes sense. Okay. And then we're going to punt on the migration for now until we get more of a community understanding of what the migration would be. Migration for handling legacy. Migrating unqualified dids to did peer three. We're just going to punt on that for now. Okay. You're not going to do anything in that area. Right. So what does that mean? Oh, right. Because this code exists. Exactly. The other code that's seen that Daniel and he wrote exists. Yeah. The actual class migration that I've been doing is not necessary because Daniel's already done it in his. And we're changing the scope of what it is supposed to do anyway. Because there's too many open questions in the model. All the things that you've raised as questions are still open because they're community questions, not questions we can answer. Okay. Okay. I will need to look at the code that I have. I'm probably will either refer to this recording or maybe I'll reach out once I've started to write this stuff. But yes, I think conceptually, I think we have an understanding of what we want to accomplish. The first thing we need to do. The scope of my work is right now. Right. Here is the scope of work you're going to do to finish off, which is in did exchange. Yeah. You're able to receive both. If you receive a PD2, you, in the request, you send out a PD2 in the response. Otherwise, you're always sending out unqualified in both. Right. In response. Then there's a flag you're going to add, use pd2, pd2, pd3. Yeah. And when that is set, then... Sending them by default. When you send a request, you're going to send a pd2. Yeah. That's the only behavior change that that flag does. And then that's as far as you're going to go. Wow. But also the storage thing we just talked about, which is that when you receive a didp2, you're going to save... Correct. You're going to save a didp2 version and you're also going to convert didp3 and save that version. No. No, I think the only thing you're going to do is save... Oh, right. Sorry. Yes, yes, yes. You're only going to save a didp3. Right, right, right. Resolve didp2 doc. And then you convert to... I'm going to put didp3 doc in quotes. If you're three, I need doc and store that. Do not store didp2 doc. Correct. You are going to write... Always, can always be reconstructed easily. You're going to add to our didresolver, a peer didp2 resolver and a peer didp3 resolver. Right. Peer didp2 will not look at local storage, but you're going to figure out where your fear didp3 will. Right. Correct. I've also got to figure out how that works real quick. I don't know if you can look at it quickly. The resolvers are expecting methods. And now we have details beneath methods. And I don't know whether in the didresolver is that a... To write that as a didp3 resolver and then a whole bunch of if statements. Or have a didp2 resolver and a didp3 resolver and just check a little bit after the prefix. Yeah, that's a good question. So the didresolver actually is just asking its set of registered resolvers, whether it supports a did. And it gives the did in full to the resolver to check and see if it supports it. The default behavior enables you to use... There's a shorthand for if you just want to do like a regex match to see if you support the did or not. You can define the supported did, pattern, or match whatever I call the method. So you can specify regex. And as part of that regex, you're matching against the full did, not just the method. So you should be able to write a separate didp2 resolver and a separate didp3 resolver without needing to worry about ifs and nelses and all that stuff. Okay, good. That's exactly the answer I wanted. I just wasn't sure how to get there. But yeah, that makes sense. So I can override that. Yeah, regex slightly. Because yeah, because that is the end result of what I've been trying to do. 24. The PR 24 that I added, which adds the legacy peer resolver, peer did resolver. You can see what the supports method looks like. But I think you should be able to accomplish what we need to by using the supported did regex pattern still. Right. Okay. One more question for to get expertise. Daniel, do you think we should do this for the connections protocol or just did exchange. Or defer that question till after this. That's a good question. I've been debating that myself. I don't think we could do that. I don't think we could. I don't think the implementation would be dramatically different between the two. So it'd be similar changes made in four locations instead of two for being request response. And did exchange and request response and connections. But I don't know. I'm a little. I'm conflicted. I'm not sure I have a. Strong opinion. One way or the other. Yeah. So. Jason, for the scope of this PR. Did exchange only. Yeah. Yeah. And I was what I had limited to do. So that is, that is consistent. We simply add another issue and another PR to do it to connections. Yeah. That should be all the answers, I think. The, the only thing. Right. And if, if, if, if while you're accepting the old stuff, don't use the redid resolver pattern at all. Just skip it and use the existing. In method. Code. That's been handling the unresolved stuff. Okay. I think that makes sense. That was a question for Daniel. Not me. Yeah. It's just that we can't centralize everything through this. Did resolver structure because we're still going to have to handle all these on this old unqualified did behavior that in the resolver structure. Yeah. If we get a did doc attachment, then the existing code will still be. Run. Yeah. Exactly. Yeah. That's what I was going for. Okay. Well. Yeah. Thanks for your time. This helps. And obviously I was away for a week. So this gets me back up to speed very fast, which is nice. Yeah. So I'll turn away at this and let you guys know, I've got a bunch of meetings this afternoon. It's a little weird. Usually my days pretty quiet, but. Yeah. Tomorrow. I'll definitely. Probably. I don't think there's any need for the. One o'clock meeting for you. So, you know, Oh, like the refinement. Yeah. Maybe just skip that and keep working. If you've got, if you know what you're working on and you do right now, let's just go with that. So don't worry about it. Maybe, maybe, maybe I'll take you up on that. Cause that would probably. Yeah, benefit. Good. Can I skip that meeting too, Steven? Yes. Okay. Thanks. Okay. Yeah. Sounds good for, for this one. Obviously with the timing of me just coming back. So that's good. Okay. Awesome. Thank you. All right. How was, how was refereeing last week? It was good. It was a, yeah. It was exciting games and. Meet some new people. Yeah. It was a, it was a really good, really good event for me. Not, not perfect, but never is. I may have a, another time off question for you in the end of September. If something comes through, but I'll hold off until I get a, until I get a request to get an email and invitation. Call it. Yeah. Jason. Yeah. Jason. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Jason is a lacrosse referee. And a hockey referee. That's right. Yeah. So doing an event in Vancouver. Last week. And. Yeah. So we'll see. I don't want to say anything until things happen. So I'll let you know if something comes, but yeah, I got another something potentially something on the radar for late September. So we're going to do a little sideline job by members of our team. Wade is going up to a driver race where he is an official. He and his family are officials. His wife used to be a drag race driver. Oh, he doesn't drive. He's an official for those events. That's cool. He's an official for the events and, and Tracy is the announcer these days, but she used to be a driver. Oh, that's interesting. Cool. Very unique. Yeah. All right. Thanks for your time guys. Appreciate it. Thanks. Yeah. Bye.