 Book folks to the 16th of August 2023 areas working group call. Good topics on stage today this is a happy ledger call and so the antitrust policy and code of conduct are in effect. Thanks to those in the meeting notes. You are welcome to add yourself the attendees list or make any other adjustments useful to the community in the agenda page. I think it's there and you'll just need a log into the hyper ledger wiki to do so. The is there anyone new that would like to introduce themselves. I, I'd like, I'd love to go. Good morning, my name is Rohan I'm calling in from Chicago. I'm working at Harvard Business School and I'm working with with a small team on a startup to essentially use hyper ledger solutions to build identity for business for business solutions to fight fraud. So we've been going through a lot of the docs and it's been very, very, very helpful all the content that the team here has put together so excited to join in see how it can contribute and be part of the community going forward. Thanks for joining us today. Anyone else. All right. Announcements by false pause for August. FJ is is doing biweekly during the summer. And here is the did come users group link that we referenced last time. So this is the second third and fourth Mondays does not meet on the first or if there is one a fifth Monday of the month. That's the schedule that has linked to the to the calls and other stuff as it relates. Yeah. Any other announcements we should have on our list. All right. Does any of our projects want to share some status or work updates. So our pie has a release 010 zero RC zero out. We're going to do an RC one as well. And probably by the end of this week, we'll have a 010 zero version available. So one breaking change in it. We'll have it covered in the change log. There's also a regression fix, which kind of triggered the need for this release. As well, lots going on in Akapai relating to period is which we'll talk about today and then also related to the use of the new and on credits RS library. What's going on there. Nice. Any other updates. All right. So today we have a first quick marketing updates from Alex. And then here's a have my name here. It's only partially me. Stephen has a presentation about the did peer three. Combined with the, the unqualified transition update, which I should retitle is something more intelligent. And so that's our main topic for today. And all of the things that surround that. Are there any, any adjustments to the agenda that we want to, we want to make before we get going. All right, Alex, you requested a minute. Less than a minute. Good morning. Good morning. Good evening. I've been specific this week that you want to areas marketing to summarize what is already in place. You can see the new changes live on the areas page. They went live last week on the hyperlegia sites. You're welcome to join our marketing working group meeting every last Tuesday of the month. Next one is a week on Tuesday. There's a draft of wiki page in progress there and of note, given the new introduction this morning, there's two links from there with getting started resources for areas that have been claded from the community. And just reminder on this corner that hyperlegia is looking out for anything identity related to promote such as blog pieces and resources from the community. So please reach out to them. If you've got something you wish to have them help you amplify. Yeah, on that with they'll not wiki if you go back to that wiki page a second there. This one. And scroll down. Right there. Please find a helpful list of links those two links there. I have a number of resources that the community gave us part of a recent survey out to them so I'm feel free to tap into those. Fantastic. That's that's good work. Appreciate that Alex. Cool. All right. Thank you, Alex. Any other marketing questions topics. All right, Steven, we're on to the topic here and I will pass this over to you. Good. Where did you go. There it is. Soon leaves full screen mode. All right, you can see my screen. Yes. Oh, we can. Wow. There we go. That's better now. I can see it. This is good. We've been working on this on acupy and and dealing with did peer two and three and sort of figuring it out. So we thought we try to take some learnings that we've sort of figured out and what exactly we're doing and and raise a couple of issues to the community to see if we can get some consensus on it. I actually created this a few weeks ago and we thought we'd have time on the call to talk about this, but we ran over on other topics. So I've evolved the presentation. So the title is kind of weird. For what I'm going to talk about, but anyway, we do have a community coordinated update portal quest seven nine three is there. I think it needs some revision still. To work on it. So we'll get there, but but a reminder about a community community coordinated update process is basically. We agree and update is needed. And basically it's a transition that the community wants to do from some old mechanism to some new mechanism where we can't detect automatically that we need to do the transition that someone's got to make a call and start sending out the new one. And just assume that the other party will be able to receive it and and so the way we do that is community coordinated update. Three steps. Basically we agree that by a certain date deployments will support receiving both formats but sending the old one on a future date soon after that. The deployments will switch will assume that everyone has completed step one and therefore everyone can can start switching to sending out the new format. On the assumption that everyone is set up to receive all the new. And then after a certain date we eliminate the old format. The key part here is the use of the term deployments. It isn't enough just to have it in the various, you know, ACAPI and AFJ and and so on. You actually have to get deployments using those out there doing it that want to interoperate and so that's the trick in pushing a community coordinated update. Okay. So changing from unqualified dids. So in this case the old format is an unqualified did, and they're associated did docs, and the new format is did peer two and did peer three. So, just again for anyone that doesn't know when we establish a peer to peer did calm connection. This approach has been for both sides to create a, a peer did a did that is appear intended not to be published onto any public ledger or not any ledger to be resolved by anybody but actually just transmitted to the other party. Along with the did doc so you give a did and a did doc to the other party, the other party does the same. And to you, and now you both have a did and a did doc to communicate with one another and all did calm communication uses that. In this case, we're transitioning from unqualified dids which are just don't have any did prefix because this was done before the did spec existed. And the new format is did peer to and did peer three. Again, I'm assuming people know what did peer two and three years but if not did peer two is a format where the elements of the did doc are encoded as the identifier of the peer itself so there's a to dot and then an identifier and that identifier encodes essentially that the entire did doc in it, and then did peer three is essentially did peer three dot identifier and that identifier is a hash of the identifier part of the did peer to so basically allows us to send to reference the same did peer to do but without having to have the entire long string involved. So, the unqualified transition is in did exchange. So we're talking to did exchange protocol we always send during the transition so step one did exchange we always send the request message, which is the first message of did exchange we always send that with an unqualified did, but we support receiving a request as either an unqualified or I did peer to. If we receive a did peer to inner request. We send, we, we recognize that we send a did peer to in the response message. So, you know, it allows us to get ready for this transition. Once the transition starts which is step two where people start sending out did peer to the way that is done in a deployment is we add a flag, such as, you know, occupy might have a send did peer to three to activate the start of step basically what that flag does is it says when, when I'm on the, when I'm sending the request message of did exchange, I'm going to send the message using a did peer to. So that's the transition that we're seeing this is what we're implementing in occupy and in other libraries I hope. So the first question I've got is should we enable this behavior on 0016 connection so this is the first question that comes up. Is anyone. Are we thinking we're going to do this for the connections protocol as well, or only did exchange. Anyone have a view comment opinion on that. I think that this would be important for anyone who does not yet support the did exchange protocol. And it needs to be involved in this transition. Now, in theory, we transition to the exchange or we try to, but it's the same. It is exactly the same sort of issue that the transition needed. Okay, so no particular view on that. Okay, this might be a good opportunity to eliminate the standard connection protocol and force everyone over to the new protocol. Yeah. In other words, combine the efforts. Yeah. Okay. So then we got. So, as we started working through this and occupy sort of figuring out what was needed one of the things we wondered about is where our dids used in areas and did com for you one. And it turns out, dids are actually only ever used internally after the connection is made they aren't ever used externally. And what I mean by that is, during connection establishment, the connections store the did identifiers there did in my did so they store them in a in a record that is used internally. And the did docs are stored in a collection of did so there's a collection I'm not sure exactly the data format so I use that term collection usually but basically a collection of dids and did docs that are searchable that are indexed essentially by keys by the, the, the very key the very, the verification key of the dead and did doc. So now I've got, I've created a connection record. I've stored there did and my did in it. I've created a did doc that is searchable by did retrieve returns a did doc but it's also searchable by the verification key within the did doc. And it turns out when a message is received from another party. So the other party uses the connection. The message actually contains the key it doesn't contain the did anywhere. It contains the verification key. The key is used to look up the did the did in turn is used to look up the connection so I get the key out of the message. I do a search for the in the, in the did doc, and then find my did based on that did. So that is how I actually use figure out what connection is involved. So that's kind of interesting that the did is not used correspondingly to send a message. I start with a connection ID that I want to send it to I find the connection I use their did to get the did, and I resolved their did to get the did doc the service endpoint and the keys needed. And, and again, when I send the message, all I send is the verification key I don't actually send the did itself. So the net of that is dids are only used internally and keys are actually used for interrupt in did com V1. The net of that is we really don't have to do anything other than that transition that we talked about in the previous from old to new in establishing a connection. It did calm one now did convie to I believe dids are used more. And, and those are used in messages and therefore there is visibility into what did people use and dids are actually sent back and forth, but this idea of in did calm one that you know for instance we're saving space and things like that in messages and so on is actually not reality it turns out, because the only thing that's transmitted related to the did is the key. Any comments by anyone on that is that clear. That was certainly not well understood, I didn't understand it clearly until recently so I thought for that in my head I was kind of considering the issues of did come be one and income be too simultaneously. Yeah. And so, and so that's that's one of the reasons there. So, practically speaking, because did peer three can only be used after did peer, did peer to his past, and the did peer to is actually passed during the during the initial connections protocol, then there isn't an immediate practical effect of did come be, or did peer three support I got to say the right words. There's not a practical effect of did peer three in did come v one, because of the lack of usage after establishing. Correct. Okay. So, so I don't that generates a question and maybe I'm skipping ahead in your presentation. Do we simplify the transition by not yet including did peer three. No, I don't think that's the right. So you're arguing that we keep it in there in preparation for efficient use and did come be to. Yes. Yes. Okay. Yeah, so I don't disagree with that I was just kind of wondering where it was going to be. That gets us to our next question, which we debated and we think we have an answer for but wanted to talk to people. What did to did to use when we get to did peer three and here we get into this weirdness of this idea of using the peer two and three. Obviously in v one it doesn't matter it might matter did come v two and again Sam are did are sent back and forth in messages and did in v two. They are the primary identifiers for messages change from keys to dids. Yeah. Okay. So, the suggestion is that we receive a did peer to we immediately on our side generated did peer three identifier. We resolve the did peer to string to be an actual did doc. So we inflate the did doc from the encoding that's in did peer to we store that index by did peer three and then we put the did peer three and their did connections. So this is what we're planning on doing in occupy right now. What question that raises basically what that means is that after the did peer to is sent we never, we never talk about it again. We just ignore it. We, we transition immediately to using did peer three and everything tied to it is is did peer three now if we ever did receive a did peer to we could have exception handling. And things to find the proper did peer three, but but the idea is that did peer to is is used in establishing the connection but once established we ignore it after that and we simply use did peer three going forward so that's what we're planning on implementing right now barring a change from the community or anything like that guidance on that but what gets interesting is what ID should be put in the did doc. Recall, I should have had a link in here to the did peer spec basically the did peer spec says to get from a did peer to string into an actual did doc you basically do a text transformation and stick in values. But one of the things you have is the ID of the did doc and in it it says, Oh, it should be a did peer to. But if we're going to index it by the did peer three, what we'd like to do is is make it the did peer three. And again, I emphasize this week, we shifted everything into being a did peer three we never talk of the did peer to again. The did peer spec doesn't talk about that. So I think we need to evolve the did peer spec. But there's other options we can do if we open up that can of worms. So any comments right there on on this particular issue does anyone care. We need to worry about it. So Stephen just to clarify that the in this case the did doc is only really ever used internally correct. Exactly. Yes. So to that extent it probably doesn't matter. Like from a spec or standards point of view, because it's not something that you're sending somewhere else it's something that you're only using internally. Exactly. Yes, that is true. So here's what I'm talking about sorry and jump to that but here's the ID string here. And it's this big long string that's in there. You are only using it internally so that's that's why we weren't overly concerned about it but but made our decision that we would oops. Basically replace this with the did peer three. All of these strings with the did peer three version from then on when we store it. Not the end of the world but it just it would be a slight update to this part of this. And it would. So extend out this to do that. So Stephen in my head. Three was always a synonym to two to being the basic format that would continue to exist. Now, I'm evaluating whether what's in my head is dumb. Or not. That is exactly where my mind went for a long time that's what I just assumed and then I started thinking about this and we started getting into okay how do we code this and Jason Syrotop who's doing the coding on our site started asking these questions and that's where my my thinking started to shift. So, I have a handful of one more thing Daniel and then I'll be quiet. I am imagining some future uses of did docs, or some some things that could happen that don't yet, but but I've had in my head as could happen in the future. And one of them is that if you are if you have a relationship where you shared periods between two parties and you add a third party. Then you would need to share dids anew with that party so that they can be aware of sort of the dids used in that in that, you know, in that relationship. And in that case, if the if the did peer to did kind of vanishes and becomes not a thing anymore, then that makes it a lot more difficult to share with a new participant in the relationship. Because you can't just pass them a did peer three. You may potentially be able to do so with a did document, but but I but I do know that if we did leave to as the dominant one that being able to share additionally did peer to as a way of doing that would be a I'm sure that would work in the sense that you'd be able to add someone to that to that piece of the relationship. The other thought that I had and this is even further out. I've been thinking about some offline potential things. And I think there are some, some potential cases pretty far out so I'm not sure how, like, much we need to worry about this yet but there are some potential cases of where we might want to pass did documents for other parties that we know in an offline sense. So, and maybe that's a peer did maybe it isn't a peer did did document but the ability to say, Hey, we're all kind of an offline stay here. I want to do an offline introduction between you and this other party and because I can't just pass you there did because you can't resolve it. I'm actually going to pass you my cash copy of their did document. And that has a case to that it that impacts this to some degree. That's the, that's the thoughts in my head. Do a quick answer on the first part. It is super easy to go from a did peer three to a did peer to deterministically. So, in that third party introduction you could still use it did here for two for the introduction but the, the did peer three would be the same. That's true so long as you have the, the, the resolved I'm air quoting resolve did document of did peer to. Yeah. So if you designed your system instead to basically keep a copy of the dead and in your in your resolved copy of the did document was simply cashed. Then, because you resolved it from somewhere else right that the theory is that you can always re resolve a did document which is true up until we go to did peer three and then you can't actually resolve a did peer three to a did document if you don't have a cash copy anymore. So our is we are storing the did doc. But now it's special behavior for this dead method. No, no. It's not really special behavior receive it did to, and then you store it. Anyway, I mean, the theory though is that every other did can be re resolved. The behavior that that if you go to did peer three, you cannot re resolve it if you don't already have the backing did document for it. Whereas you can re resolve and I realized that resolve is a weird word to use here because you're translating it from a did peer to into a did document but my point is that you can't do that again. If, if did peer three becomes the primary identifier that you use in the relationship. There. That was my thought, Daniel, you had your hand up and now it isn't anymore. Yeah, I'm wondering if I should just hold my thoughts because I think Steven's probably going to touch on some of what I'm thinking and coming up sites. So, this one. Yeah. So a couple of proposals so the end of this if we open up changing the peer specification. What should we change the spec to say. And the proposals that we've come out of our sort of three styles one is to set the ID to do peer three identifier and be done with it. So, what I proposed in the previous which is, as I say just. Here's the dot right here Daniel. Anyway, it is on to but not on three, not on three. I thought we fixed that. We did we fixed it on three, but not on to we didn't change to because he's been around for a minute. Oh, I thought we fixed three. Okay, anyway, no, we fixed three by removing it. The thing about the reason it was added and this is probably my fault is I was trying to make it as consistent as possible. So, so the processing of the elements of did peer to where pretty systematic, but that's not a concern for did peer three or any of the other did peer algorithms. Okay. Okay, so one idea is we simply replace this identifier in the resolved. Dock to be did peer three. And we go with that. So what we talked about already. Another is to use the also known as in the dead in the did doc that includes both the did peer two and three. Presumably, we put the peer three in the ID, but, but the also known as would be there to include both the two and the three. If we have to open up the did spears chip back how about we change the definition of did peer and so I came up with sort of two ideas. The first one was, and these are equivalent. I think the second one probably makes more sense because it this is copied actually from the side tree spec, which is basically the side tree has two forms of URIs of of identifiers, a short form, which is the, just this, which is did peer did peer three with the did peer three identifier, but a side tree also has a long form and the long form in, in this case, would have the did peer to identifier added as a colon after it. So, so, in other words, we deprecate did peer to entirely we get rid of it. And we redefine did peer three as being one of these two forms and most likely being this one. So, so use the same style as, as side tree uses. Does that make sense. So the initial identifier is larger because you're sort of including the peer three hash along, you know, in front of the of the peer to, but it then it follows a more standard pattern for its short form of doing so. And then yeah, and, and basically side tree uses this to get around to basically get around having to wait until Bitcoin resolves before the people that did can be used. Basically they pass a long form version of it that essentially contains the did doc element so that you can use the thing, but also reserve this short form version for ongoing use. So back to the previous question I think Steven before dive into this one which was, you know what to store in the did doc. Yeah, yeah. I think that if we're going to have both things in there and that kind of makes some sense to me that I think saving the original form of the did doc. So the ID would be the did peer to. And then the also known as would be the did peer three. And would be it like a, a truer representation of what was originally provided with just a single addition to it. And would, you know, be the most compatible if we needed to, you know, as had been suggested it need to be sent somewhere else. Okay, to extend. So I think that would be that that's that feels right to me I'm not sure that I have a really good justification for it but also. No, this is not digital this is not right or wrong. Yeah. So that would be. So the ID with your two. And the also known as the did peer three. Because then a receiver of that document if you were to share it, as had been indicated, they could re derive the did peer three if they wanted and not even look for the existence of that additional field. But they could, you know, use it if it's if it's there and it would work either way. And for your internal purposes, you'd have a field that you could rely on being there because you're generating and it's storing it that way, and be able to look it up that way, you know, in efficient fashion so that feels okay to me. That feels good to me war and I think that's wise. Okay. I'll add some additional thoughts. And clarity I think to my proposal of this also known as an into the did doc. So I think did resolvers when resolving a did should strictly resolve a did for a or resolve a document for a specific did, like we shouldn't resolve a did peer to and then see it did peer three within the ID, which was why I was pushing on the also known as. And in a similar vein I think when we air quote resolve a did peer three, I think that should resolve a did peer three document, not something that is a did peer to what we call it a did peer three. And so I think the document that we resolve from a did peer three I think it should be generated from the did peer to and it's resulting did document. It's technically a separate value from the did peer to that just happens to correspond to a did peer to that we proceed. And so when we resolve a did peer to it includes the also known as which specifies the did peer three that it relates to, and then we generate the did peer three document from that and then can store it. Like in the reverse direction as well when we resolve a did peer three, we can specify and also known as that maps it back to the original did peer to that generated it. And looking at the did core specification that bidirectional mapping that it is provided in the also known as field represents a strong. mapping between those two dids as referring to the same did subject, which I think is semantically quote unquote correct in terms of what is currently defined in the core spec, I would say personally, that's what it's been my feelings on it at least. Okay, so. So, to, to paraphrase what you said, basically, this is actually what we agreed to do yesterday you're right extending this out. In, when we receive a did peer to, we will generate the identifier, we will generate the did peer three doc. And the did peer three doc will be the did peer to doc with the ID switched and it also known as set to did peer to. And we'll store that. And then whenever did peer three is received we will always resolve to that did doc. When we resolve the did peer to will return. We'll simply look at the string we won't look in any caching or anything else we'll just look in the string, and we'll do the transformation. And but but we'll include the also known as. Okay, so I think I got that what you said so I think this is a more accurate description of what we're planning on doing right now what what Jason's been tasked with doing. The only thing left is there any sort of appetite for switching to this long and short version. Long you are I short you are I version of these things. And that eliminates any reference to peer to at all. The short form long form thing is such a better plan. It's such a cleaner idea to include the short form in the definition of the long form and then have sort of a one, you know, one, you know, one thing that does them both. The downside of that it's it's like yet another thing that we're doing. I mean, but but on the but on the plus side. It's just such a cleaner thing and it's not like the transformations we're talking about are wholesale different we have to throw everything out. We just get to refactor it a little into doing the the newer thing. Yeah, I really would. There needs to be some kind of mechanism in the protocol such that if you received a short form of the did peer three and you no longer had some cash copy of the did doc that you would be able to respond in a way that it could then send you the long form such that instead of sending you a did peer to for instance. Nope, and that way you would be able to get it back. You're on and that's the kind of the nature of did peer entirely is that like if you can you can only actually resolve it if you already. Well what I said is not entirely true but but generally speaking you can only resolve it did if you were actually provided to did did peer to is a little interesting because it includes the whole thing into the into the into the identity identifier itself did peer one, though now deprecated is is another is another one of these issues where like if you have a sort of a later form of the of the did or the did's been updated. There's not really a great way to do that. The problem is is that the did is the bootstrap by which you communicate with the other party. So if you if you don't if you cannot resolve it for some reason, you're kind of done like you can't really continue or pick up you you basically have to rebuild the conversation from scratch. Now, it could be rebuilt using the same did you be like oh yeah this is the this is the person I knew before. And now I now I have the long form of this. But that that is one of the differences say between the the side tree one where they passed the short and the long form is that the short form is actually resolvable later, because by that time theoretically it's it's resolvable on the ledger, as opposed to the to peer did's, which cannot be resolvable later in that particular case. Two things on that. Yeah. One is yeah you can't resolve who who you're connected with you have no key to send a did calm message to them so there's no way to send them a message so it's got to go out of band. Sam actually you're the way side tree works you can actually, you can't actually you can't necessarily resolve it. Because they actually use it in their peer did form, where they never intend to publish this, the short form. So you would actually possibly be in the same in the same situation. Oh so the actual inclusion of it inside tree is optional, like actually in a in a Merkel tree. Yeah they actually have the phrase, and arbitrary time where the short, the only valid version is the long form, potentially forever. Interesting. Yeah, yeah I thought that was interesting to read that. So you're doing period is without calling them peer did's. I must be understanding something misunderstanding something because you said that if I didn't have the key I couldn't send the the message. Am I not using the private key to send the message which is not in the did doc. They're two separate things are they not you're sending the public key to encrypt the message to the private key of the other side. So you're sending a message you use your private key in their public key. Yeah, yes. Right okay. Gotcha. I think that this this long form short form did peer three idea doesn't necessarily resolve the question of what goes in the ID field for the result document. Oh really like we'd still have to answer which one, do we put the long form or the short form into the document that we resolve. The way the side tree does that I believe 99% sure they only put the short form in. Okay, interesting. So the, the long form this is, this is, you know, I had, I had proposed basically a did URL but in looking at how side tree did I just I knew side tree did something so I looked up what they did and this is what they do. So basically you're saying the did is actually this. But there's this alternate long form that has this extra colon on it. But this is the actual identifier. So what I just said a minute ago about having strong opinions about the did resolving to a did document that the ID is the exact match to the did that was resolved doesn't hold true in the side tree case then pretty much. Okay, I like the idea that there's a real did, and then there's the short form and the short form goes in the also known as. Yeah. And what that means is that when we're developing software, we store that we store the long form did the real did air quote real did. And then we keep a subsequent index or some other way of indexing the also known as so that when, so that when that did is used we can we can relate it back to the to the to the air quote real did. So, but this applies in several different ways here. Yeah. So, I have thoughts, but I'm super curious about what you have on your remainder remaining slides. I don't know if I have anything this is that's the most interesting one. So, the question, the next question is, do we upgrade unqualified kids at all. Because in a did calm be one world, it doesn't matter. The usage is all internal. There's actually no reason to upgrade on existing unqualified kids. Because all of the searching is based on keys. It just doesn't matter. The question is, yeah, and then the next thing and credit Daniel for this thought that, you know, we don't even know how we're going to update existing connections from did calm one to be to I don't think I don't know what the plan is there. So, do we just punt on this problem of upgrading unqualified kids. Or should we take on this migration of unqualified kids to make them into fit into the did peer world. So, the way that manifests itself is, do we provide so in occupy we have these upgrade scripts basically, and on a given release we may add a script that says, oh, when upgrading from this version. We are upgrading from a previous version to this version, execute this script. And so the script could go through and update all of the connections and update all of the kids that are unqualified to make them qualified so we're upgrading our, our, our. Dids to be, yeah, to be transformed into a did peer three, for example, and then all of our my did and their did references and connections to be did peer threes. Should we go ahead and do that or should we wait till we figure out how a, how an existing did con view one connection might become a deep did comfy to. This is where Sam jumps in, because he knows more than anyone else. So, I will confess that I have not worked out a full proof plan. And it's not that I've run into roadblocks it's just that I haven't yet spent time there, working out how we actually do that transition. My, my guess is that via some interrupt interrupt profile internal or external or something we as a community kind of say like okay like we're ready to actually talk did conv two now. And then we either have a way, ideally of self discovering that so that so that we don't have to do a community or coordinated update, or we, or we've, or we do a community coordinated update and then we have a target date to do so. That's the idea that we can fully deprecate did come v one. And so under that condition, and with with peer did etc I think we're good to like move forward. And I would like to have a good answer to this coming, you know, as we go. One of the reasons for that one is that I think that this issue is a huge sticking point for people that arrive at the areas community. Thinking that, you know, as advertised we're doing stuff with dids and did calm. Yet we're not actually, you know, because of the and I don't. And some of them are going to hit me right in the sense that a lot of the stuff we figured out and got going a long time ago and we've made a heck of a lot of progress since then this isn't something that we've like brought up and made current with the with the rest of our current practices. And so, I think that having this answered so that as a community it's just done and gone, I think is a better idea. Similarly, a long years and years ago, we additionally had a different idea for how to reference protocol names, and we transitioned away from that and that's gone. And that was similarly like a weird thing that we did it didn't make that much sense. And we fixed, and this falls into the same category for me. The good news is, is that I think the actual processing is simply restricted meaning the update that we're going to run is simply in what we passed in the did exchange and everything else is actually handled internally. So we are encouraging our community to do the internal stuff now, so that when we do that did come transition did come be to transition, it's a solved issue. But, but realistically speaking, you know, you could get by doing just the most minor amount of work to to to demonstrate compatibility now. And then that would eliminate the fact that we're not, you know, using deads regardless of how you handle it elsewhere. And then the, you know, when did come be to shows up that's when the rest of this would apply. So I do think that we should do this. And I think that there's value there, despite the fact that we have not actually demonstrated how to make how to make this transition happen. And anticipating that the software we have is going to be written such that you could the same endpoint will receive it did come be one message and it did come be to message, which means that the only thing required to really upgrade that connection is to have the confidence that the party on the other side is capable of receiving the message you're sending, which involves processing the envelope, and being able to deal with the fact that it's it's did oriented instead of key oriented. So that's the did oriented versus key oriented problem by pre coordinating a solution to the to the to the unqualified peer dids. And then I believe that when we get to the fact that we're all going to transition over to did come be to, or at least add support for did come be to, then that's the issue that's what we, that's what we figure out. And the example one of the ideas, for example that we could use in order to not do a community coordinated update is to is at least in the initial phases is to run a feature, discover features request, and be able to indicate that you support did come be to, and then the future messages then could be sent between you know between those two parties and did come be to format. And that would be one of the ways of making that happen. And so I actually think that that that coordination is going to require a little bit of. And we already have provision with the sort of accepted types of stuff, we already have provision in did exchange, and are out of band messages specifically to indicate which types of things that you support. So I actually think that even from the very beginning that will be a fairly natural transition that we move to. And we won't have to do a proper community coordinated update for that well, obviously I think we should sort of encourage the community in their adoption of it so that we can deprecate did come be one. But yeah, sorry that was really wordy, but but I do think we should do this, and I'm not terrifically concerned that the transition between v1 and v2 is an unsolvable problem. Or, or that it's not worth solving I think it will be worth solving and I think it will be solvable. No. So, I'm going to, since we're right out of time I'm going to sort of say what I think we're going to do. I think we're going to continue with this, and we, I mean, acupy. So we're going to do specific things. So, nothing today that we've talked about suggests to me that we should change off this plan so basically we're adding support in acupy for also known as so that when we, you know, when we index it did, we have to take into account also known as so I don't think there's anything in acupy that does anything with also known as before but I think we need to do it. And that I think the also known as is the answer here, and we'll go with this as the answer and in the end put a PR into the period it's back to simply add this as, as the approach. I don't think we'll go down this unless unless somebody really thinks this is a good idea I don't think we'll go down this path. I don't propose on on pushing any further. But instead that we go with stronger support for also known as I need to think about it. I actually I really like the idea I just have to decide if it's worth the effort given what we already have. I wish I wish I had had this thought far earlier. I wish that this had been built into peer to like did peer to at the time right that would have been ideal. So one conversation that I would love to have Steven sorry to just add just a second in here did methods don't have versions. Oh, and we've done a lot with the did peer method, and now there's deprecated things and it's a little bit nuanced and complicated to say whether you support it or not. I would love to have a discussion at some point and maybe given that the most of the interest and did peer to I think is within the areas community that this isn't an horribly inappropriate place to have that conversation. But I would love to have a conversation about what we do about that, and maybe explore some of the options to see what people think. Totally everything. For now we're going to punch on upgrading, but totally open to that one as a follow on we don't we feel we don't need to do it right now so we're going to. We're going to hold off right now. So I'm less concerned about the legacy did transformation and stuff like that, because we're probably not going to worry about it. And then I'm just wondering about about where we are with the other other libraries I actually didn't update these two slides after I kind of left them as is from my previous couple of weeks ago. And hopefully that summarizes, we're at time so I better stop but that's what we're going to do is sort of stick to this plan, but raise up this concept of also known as to be a real thing. We think that as I say that now I think that can help with other did methods, because I think we're going to get also known as in other did methods in the near future so And that takes us to time Steven this is a super good conversation and I feel like there's lots more conversations we need to have related to this. So I really appreciate you putting that together and sharing that we are at a time. We, if you have thoughts about this. I think that sharing them in the community channel would be a good idea I'll try to do the same. And that way we can sort of advance our thinking before the next meeting. Thanks everyone. I hope your week is a great one and thank you for attending and contributing your thoughts and we will see you next time.