 Folks, welcome to the last August of 2023 areas working group call for August 30th. Glad you're here. We have some cool topics today and some progression that we have made in our, in our, the process of, of resolving the, the unqualified did issue. Some good stuff. Also, peer notifications is a discussion on the horizon and so that stuff's going on. I will drop the. Chat to be enabled this thing so that people that can join can see back chat items yet. Do we know if we did that? Anyway, I'll continue to repace repost as people join. So the link to the agendas in the chat. You're welcome to add yourself the attendees list or anything. Any other useful changes to the community on the wiki. Meeting agenda. This is a hyper ledger call. And so the interest policy and the code of conduct are in effect. This helps us be excellent to each other and solves legal issues that may encumber our work. Is there anyone new today that would like to introduce themselves and say hello and tell us what you're doing. All right. Glad you're here. You're always welcome to do so in the future. Announcements, we have a collection here. So we're getting to the end of August here. And so I think that the vacation pauses for AFJ and bifold may be coming to a close. And then Steven, you have the the did web s did method link here. Any quick commentary on that. Just that we're continuing to make progress. The repo is getting merges activities going on as far as an implementation. And meetings are now happening Friday mornings. 25 hours from now. So an hour later than this call on Fridays. Set your clocks folks 25 hours starting now. Well, 10 minutes ago. Sorry, my joke was poorly timed. Also, we have an indie summit this week, Steven. Next week. Yeah, Thursday. The hour before this on Thursday. Actually, yeah, it's not 25 hours from now. It's 48 hours. Never mind. That's not even go there. The indie summit is September 7th. 7th. And that's a that's a Thursday. Right. Yes, Thursday at six Pacific, which is 3pm in central Europe. Okay. Do you have a link for that? I've got a registration link that I can add. Yeah. Perfect. So we have lots of crossover with this community and indie that's that is going on next week. Cool. Cool. Sounds good. Any other announcements we should have our analysts but don't. What's the next? Internet identity workshop. We're getting there. Load load load. October 10th is the next IW. We've heard this pitch a million times, but if you have not been to IW and you are able to make it is a is a pretty great experience for all sorts of related topics. And we'd love to have you there. That's in Mountain View, California. That's an in person. Great. Any other announcements? Any projects want to share a release status or a work update? Yeah, so Accapai 010-1 was released yesterday. A notice is to go out based on the change log entry that I've linked in the text there. We had some fun times with PyPy for some reason it thought one of the distribution files for 010-0 already existed. Presumably because it already existed somehow. We don't know how, but anyway, so we had to do a 010-1 to make sure that both of the artifacts got published properly on PyPy. So that was done yesterday. So 010-1 is the current version of Accapai. And as I say, the change log entry has got the updates on it. Some very good work done on did handling and making it so that it's much more flexible in establishing, for example, using different types of dits for didcom connections and things like that. Lots of good stuff in that one. Cool. We are also upgrading to poetry as of tomorrow in or as of now in Accapai versus PyP. So I don't know how that actually affects others, but that has happened the merge occurred. Excellent. Other work updates folks want to share. I don't see folks from VCX and framework JavaScript, but there is lots of work going on in both of those communities in those frameworks. So if you're not paying attention, take a look at what's happening because there's just lots of improvements and bringing all of the Aries implementations to sort of a common ground. So it's good to see. Excellent. Cool. All right. Discussion topics today. We will have a quick marketing update and then we have some discussion of did rotation for didcom v1. As well as did pier four, which might be the first time you're hearing about this, Daniel Bloom will talk about that. And then after we clean up the sort of those related family of discussions, we plan to start a push notification discussion that will likely carry over into next week as well. But that is going to be that that'll be a great discussion as well. Any adjustments to the agenda we want to make before we get going. All right. Helen or Alex. I see an Alex. Yes, hi. I'll give a short marketing update. First of all, we have the draft wiki page. It's now got to a near final version. So we're looking to make that live in the coming week. And we'll let you know when that's in place. We're also taking a slightly longer description from that wiki page and the liais with hyper ledger to add that to the Aries landing page on the hyper ledger website. So that's just a small text decision to make that page a bit more substantial. If you look at the actually out of that link there, the hyper ledger.org link, it will go below the the the calls to action at the bottom of the page. There's some some support information. If you scroll down a bit from there, I think I'll be above or below that that blue panel there with the download the code. I'm not exactly sure the positioning I think will be above. So we leave the calls to action at the bottom. So below those three stats. Yeah. So that's something we're going to get in place as well. That's already text that's been shared and gathered feedback on. So we're going to beef up this page to add to the improved description. You can see that already. And then if you could flip back to the two meeting agenda, thank you. And then we're going to explore resource for, as you mentioned before, a short Aries introductory animated video. We have. And I'm talking, you know, we can I can bring the. The script raising and we got the voice itself part of the video, but we need to see if we can get some resource to use one of the many animated video tools available on. Available internet for making a short like less than two minutes. Introduction to areas that suitable both for an exact audience and new devs coming in just conceptually what's going on in the key moving parts and why and why we're different. So kind of taking the key things you put in that text and turning into a video form for easy consumption. And there's enough tools out there that we can do this really affordably. I think in in low dollars from somewhere, we could just get somebody who's got those skills rather than, you know, even though they're quite easy to use. I know that I tried myself somewhat crazy trying to learn that from scratch. So we're going to look into getting that. I think high pleasure may be able to help us out with that. So watch this space on that. And then finally, this is all based on some discussion we had yesterday, which is the last Tuesday of the month has been marketing working group. Everyone's welcome to join last year every month and and bring any if you want to, you know, advance the great the cause of the great ship Aries or you want to contribute in some way. Or you have a suggestion as to how we could be improving how we talk about Aries to the to the world then of course we chat in the meantime to handle myself but also welcome to come to that meeting and there's the link. That's the fourth point there. Absolutely. And that's useful for not just marketing folks but for like business folks or sales folks that are talking with lots of customers and would like, you know, input or have feedback on how Aries is perceived. Absolutely. All welcome in the meantime as well my email address is in the in the notes top of this page as well. So yeah, reach at any time and to myself well. Excellent. Thank you for your work there. Okay, next up we have did rotation for did come be one. This is a this is a topic that we I brought up last week. But now I've actually turned this into a to a PR to the Aries RFC repo. But wait, Sam, aren't we supposed to put these things on did come.org now and the answer is, well, yes, but did rotate one is of particular interest to the areas community because we are the largest implementers of did come be one while we'll link it from did come. From did come.org actually having that the protocol here makes lots of sort of community organization sense, since we're going to be the ones most actively working on that. And of course did come protocols can be created anywhere, which is why we have the feature on did come.org that allows linking to to occur. So, so that's why this is done in an Aries RFC. This is pretty This is pretty straightforward. There's only a couple of messages here. Messages here are discussion last week prompted some some additions which I'll get to in a second. The idea is that there is a did rotate message, which informs the other party that the rotating party the one sending this particular message is, you know, plans to switch to a new did. And then, and this is the notification of it. There's some notes about about did come be one and did come be two and the lack of a signature as well. There's a there's an issue that we can talk about the kind of relates to the did exchange protocol as well but let's, but we'll get through here. So here's the original message you send. So Alice wants to use a new did with her in her relationship with Bob. I'll send this message with the new did she plans to use. And it's worth noting given the context of this larger discussion that the did maybe in fact just a reformulation of using the same keys that are already did already exist in the relationship. That's okay, but there should not, there should not be an assumption that that is actually the case. So, if you do that that's fine. But the receiving party that the observing party here should not assume that the same keys are actually in play and should do whatever work is necessary to about to resolve and evaluate the did that's being passed in order to make that occur. And so that there's a there's a note here in the text about that. The there's two outcomes of this one is an act. If the if the receiving of the observing party receives this message and says. And everything's everything's good and groovy. They can send an act back that says yep got it. Thanks for the note. And then and then further messages, you know, will from either party will then use the new did that that has been discussed in this. That's the happy path. We discussed some unhappy paths last time and so this did not render well at least in this preview, but there are two types of problems that can occur when you're doing this. It's possible, for example, that the that Alice sends Bob notifications she intends to rotate to a did that Bob is not capable of supporting the did method is not supported. And and that would be a problem in the relationship because now now Bob is unable to to use the new the new did that Alice has requested. And so sending a problem report back. This is adopted into the did rotate protocol here with with the did subject and then the the appropriate description here is good. And this didn't get updated as well, but this. Oh yeah, this is just a regular message ID, but we're using the parent thread to link it back to the rotate message as well. The other method is that you in theory support the did method, but something else was unresolvable about the did. So in the processing or attempting to resolve the did some other error occurred and you're unable to have that information and so that that's another another one that could of course cause a problem in both of those can be indicated here. If a problem report is sent, then the rotation does not complete at all and a future rotation managed in its own thread would need to be attempted again in order to let that occur. And so and so there's a little bit of discussion about the differences between between how it works and did come and be one and V2 did come V2 is a post rotate, meaning that it is rotated and then and then messages are sent that is more efficient. But but requires a little bit of a different processing model that seemed unwise to inject back into did come V1, which is why we have a post rotate operation, meaning, or sorry, rather a pre rotate where you are having a discussion about the rotation prior to it actually occurring. And so, and so the planning there's a little bit different but the goal is to make the implementation of this is as simple as possible. This does solve the problem nicely of having to as a community all rotate to a single did method off of the unqualified dids. It also, and this is some wisdom of Daniel bloom I'll blame him for this. It nicely solves the process of actually rotating to did come V2. The best way to know to rotate or to begin using did come V2 is simply to inspect the did documents of the dids that you communicate with. And you can detect via the difference in in service endpoint types, whether they support did come V1 or did come V2, and then you can of course automatically, you know, begin using those when you're communicating with the other party. But this is a problem if you're using a did that is not updatable because because you have that problem. And this allows so the rotate method also is used in this case where if you begin supporting did come V2, then you can of course just rotate to an updated did that includes that whether it's a whole mother did method or whether it's simply a different. You know, still like a peer did, but then, but that also includes that endpoint information. So that's a brief overview of did rotation. There was before open up for for a note here, Ariel out of comment and said is it is it really necessary to include the to did in the act, or, you know, we're already referencing the thread. Should we just do that and so this is kind of an open question I have for the group here. It is redundant to include in the act. The, the to did as well in theory this wouldn't show an example but we could, you know, show this referring to the thread ID here. And so, I'm curious what folks think about that level of redundancy do we include the thread and the two did. Do we leave it just with to did or just with thread. Thoughts and opinions, please. About this message design. Just a question. How does this work with mediation? Like, if the mediator only supports did come V1 versus did come V2. It's the responsibility of the party when you're rotating to make sure that the mediator you're referencing is capable of of routing the message types that you are. Indicating in the did document but incidentally you could also use this this did rotation to actually move mediators. If you're using a mediator and you want to move that you can send them an updated to document that contains the new mediator information. Does that make sense Colton was that a complete enough answer. Yep. Yep, that's a complete enough answer that makes a lot of sense. It was just a concern that I thought of. Excellent. Other thoughts or questions or opinions about the act message and what we can contain in them. So to just think out loud for a moment, a moment about the implication of including the two did in the act. That presents a new air condition where you say, if the two did in the act didn't actually match the two did that you sent out in the rotate message that we would also need to account for the ability to send a problem report back and say hey that wasn't the did that I gave you. I'm totally other random did wait, wait, wait, wait. Yeah, exactly. Yeah, so it like, if that's something that we want to consider just categorically impossible. Then if we expressed it by an acknowledgement by just including the thread of the original rotate message, then that's maybe an air condition that we don't need to consider. I think that's wise. So that's a vote for not including the two did, but simply just referencing the thread ID in order to avoid that particular air condition. Yep. Other thoughts. Yeah, and also for the first implementation, I think it will be easier because in other protocols we are usually just using the thread and probably the status, but not including custom fields on the messages. Sounds like modifying this to only include the thread ID and not the two did is is the right answer anyone have any final comments. Sam, what happens if the peer doesn't support the data rotate protocol. That can be discovered with well so it'll be ignored. First of all, because because that's the standard behaviors that if you don't understand a message you can return a problem report or ignore it. Which means that if Alice wants to rotate there did send it to Bob and Bob doesn't respond at all because it doesn't support the protocol then then Alice is still stuck using the same, the same did that can be discovered in advance with the discover features. Protocol to verify that the party does and what we would do as a community is, you know, set a goal to to have this done so that we can all leverage this feature. So in the in the long term this problem still exists in the short term, the community, you know, will be a little bit more organized than how it gets there. Does that make sense. Yeah. Yeah. Okay, thanks. Stephen your hands up. Yeah, you're missing a period on the rotating parties expected to receive messages. What about the other party what's their expectation on on saving. How long they should keep the other and existing messages is there any requirement there or should there be any statement made about that. So this is the reasonable period of discussion that we had last week to. We adjusted the language so that it must extend at least until the following act message has been received so there's a minimum amount for that reasonable period. And that makes sense for the rotating party. I'm thinking of, yeah. But but for the observing party. Yeah, I think that I think the employee, I think this means you just switch immediately. I've been using the new one and don't use the old one anymore. As soon as you receive the rotate message and you act it back, then you go into full. Yeah, I meant for, shouldn't there a possibility of receiving messages. That's the only thing I wanted to vote. Out of order receiving messages. Yeah, if there's anything that needs to be done to set about that. And basically what I'm wondering is does that mean a receiving party has to figure out oh I've got to make sure I have synonyms for all of these keys to match. Or do they just ignore that that was the only thing I was thinking about was does the does the observing party have to do anything other than just say oh I'm never going to get another one from them. It depends a little bit on how row. This is this is a sufficiency of robustness question. Yeah, right where in theory, you, you, you, there definitely needs to be sort of a double commit type of a thing here to make sure that you know nothing ever falls on the floor, because and so it's like how much is good enough type of a situation. My inclination is, is that these these types of rotations that are actually happening are going to happen when people are using software but not necessarily engaged. It was like smack in the middle of an interaction new interactions, for example, can of course use new did methods, which means it doesn't really have an impact on those. It's the it's the existing connections, and lots of those are going to be updated as software you know a new mobile app for example is released. It loads recognizing existing relationships using unqualified did and then sort of proactively sends these things out which means that they're not going to be happening really very close in proximity to a lot of other interactions. And so, also given the fact that message delivery is, is mostly reliable in our experience in the sense that most messages tend to get to where they need to be in out of order is a little bit rare. I'm inclined to say that we don't need to specifically handle that at this point. And if someone thinks I'm, I'm, you know, dumb, like my opinion is poor there. I'd sure love to hear that and certainly this allows for robust implementations to to preserve and manage that. I could add a note, similar to this timing to the act message as well, that would kind of indicate the behavior that that behavior is possible by the observing party. And that could highlight the fact that if someone does have a situation where they have high enough message volume that it's likely to be an issue that they could be aware of that. Think of what definitive guidance there would be for a, you know, someone receiving this message. You know you're going to receive the message you're going to process it and it's going to go away. You don't want to write a bunch of extra code to go clean up all the ones you saved but if you've got to wait for the act is, I don't know, it's just, I'm not sure quite what the guidance should be but anyway. I don't know exactly what the guys should be either. I'm going to add myself a note here. And it's, and it's not so much about a reasonable time as to what as to what they should implement. It's more guidance for what they should implement, like the implications of moving from one to another and any stored messages. Like if you save. If you don't, if you don't, if you immediately forget about anything that ever, you know, the keys that went before. Are you likely to run into any sort of issue. Right. Let me try to add some guidance that at least calls attention to the issue and then implementers make their own decisions. Yeah, okay. Sounds good. Yeah. Is there anyone we've talked about a handful of pending changes. There was consensus around using the thread ID here as suggested by Ariel, which is really good. And then some additional notes about sort of handling. Is there anyone that is opposed to this being merged after those changes are made. Do we do, you know, is there anyone that would like to to make sure that they see this before the, this protocol is, is, you know, committed into the repository. So I'm about to say here in the commit so please object if you do object, either in chat or everything else about merging this. Okay, I'll go ahead and make those updates then. And then and then we can go ahead and merge this this protocol and just for the sake of moving things along. Okay, the next topic on our list. I'm going to pass over to you Daniel. Do you want a screen share or would you rather I did. I can screen share to talk about peer here did peer for. Okay, how's that look. I will go ahead and drop link to this in the zoom chat again. Okay, screen share looking good. Okay, thank you. Okay, so I'll give some introduction to the method. And then hopefully we can spark some discussion from that. So this is the docker put together outlining our proposed did peer namago for this method is roughly equivalent I would say to did peer to. Address to peer three. So two plus three equals four in this case. And it's kind of an evolution of all the ideas that went into did peer two and three. But as we've implemented and tried to use those methods we've kind of discovered some shortcomings that we are attempting to address in this did peer namago for specifically for did peer to for instance. There were some parsing rules and encoding rules that resulted in an inability to keep like identifiers in verification methods for example. And that was limiting and confusing in a lot of cases for how we express like what should the identifier be for the result document for those verification methods. And that was solved in various numbers of ways, but it wasn't consistent. So that was an issue and the did peer three itself sought to solve the problem of did peer to being kind of long to include in every message and it can be to after you only need to really communicate the document component of it once. So, did peer three was intended to solve that problem but we think it's cleaner to just kind of combine that all into a single method, which is did peer for here, which is, it contains a short form and a long form, where the long form contains the full document and the short form is a hash over that document that you can use as an alias to the long form version of did after it has been communicated at least once. So the key differences and how did peer for does this as opposed to did peer to is rather than attempting to shorten the contents of the document at all. We just completely avoid that problem altogether. And we just encode directly the document, which resembles very closely a did document, but has some key differences that I outlined here. But that document itself is just encoded and just put into the long form of the did. This encoded omits an ID since we're in the process of creating the did that is supposed to go into that field. All references within the document referring to other elements within the same document must be relative. And then the controller value for verification methods is omitted. If the intended controller is our did that we're creating. We'll express controllers or verification verification methods controlled by other dids by including it and the the algorithm will leave those values in in the result document. So to get a did peer for did from our input document, we just json stringify the object without white space. The language here isn't strong enough it should actually require that it be without white space, I think, just for the sake of consistency. So I'll remove that text there. And then we encode that that string into utf 8 bytes. Then we do a multi codec json encoding and then multi base base 58 BTC encoding of that value, and that is the encoded document. And we take the hash of that value over the final encoded document, not the bytes of it or anything like that. We render the string itself as utf 8 bytes. And then we take the multi hash shot to 256 and encode it as base 58 as well. We end up with a hash in an encoded document and we can connect that concatenate those values together using this template here, or it's just did peer for then the hash and then a colon, and then the encoded document and an example. Here for did can be found here. So we have the four we have the multi base 58 and see we have the QM which indicates that this is a shot to 256 encoded hash or digest. And that is the the hash portion of the did and then this long portion on the end is the encoded document in base 58. The long form of did peer for is just omitting the encoded document off of the end. So, then the process for taking that to peer for did and resolving it is a matter of extracting the encoded document from the long form. And then, which is basically just the inverse of the steps that were presented for encoding the document. And then we contextualize the document by inserting values relevant to the did that's resolving the document. So we take the did and inserted at the ID of the root of the document. We also append to the also known as list the short form of the did. And then for each of the verification methods that don't already have a controller, we insert the did as the controller value. We can also turn relative references into absolute. That's not a requirement. Since relative references are valid within the context of a did document and are understood to refer to the current document. So the input document that we took above when it's resolved into the fully contextualized did document will look something like this with the ID being populated with the folded peer for also known as being populated with the short form. And then the IDs. In this case, I made the relative references absolute. So the full did peer for is in here followed by a fragment all the way at the end I'm not going to scroll all the way over to it but it's there. Additionally, resolving the short form is also possible only if you've seen the long form of the did peer for so if you've seen if you've resolved this document before. The also known as value is then resolvable if you store the document, the decoded document or the long form of the did itself and you can. It's up to the implementation how it wants to store those values and then determine what the what values it's pulling from in order to do the short form resolution. But we to resolve the short form we take the long form, we do the decoding steps as described above. And then we contextualize the did document with the short form instead of the long form did so that the short form ends up in the ID, the long form ends up in the also known as, and if you make the references absolute. Those will be included in the IDs with the fragments on on the end. But again, the absolute or relative to absolute is an optional step here. So that is the gist of did peer for hopefully it was clear that the the provenance I suppose of the method it shares a lot in common with the peer to and to peer three, but we think it's just a little bit better a little bit cleaner. A little bit easier and more straightforward to implement. I've got a couple of frequently asked questions that I'll address here briefly. So why base 58 encoding for the document. That is mostly to avoid questions of base 64 URL safe across languages. If you're not consistent in Python you include padding on the end in JavaScript, the padding is not included on the end. So it's just avoid that all together we're just doing base 58. Another question you might ask is that long form is really long. Can we do something about that can we shorten it short answer is, we don't think that's necessary because you'll just rotate to the short form anyways, or not rotate necessarily but you'll you'll use the short form as an alias to the long form. So rather than implementing some picky parsing rules for shortening values or anything like that. We think it's better to just keep it simple straightforward and easy to implement. What's wrong with it peer two and three that's something I think we can discuss here and why use multi base and multi hash multi codec. I think this just keeps our options open if we want to switch out for using a different hash over the long form for the short form. We have that option and the identifier itself is self descriptive. So there's pretty minimal changes there to to the handling of those values. So I think it's just a good baseline self descriptive identifiers won't hurt us. So I think it's fair to use them. So in the issue that I raised on to peer for proposing it, there are some good questions. I think, such as why not just make this to peer three. Instead of having to peer for since nobody's actually implemented to peer three yet. But yeah, so there's, there's, I guess the kicking off point for discussion at this point. Steven hands up. Hey, a couple of questions. I think I know the answer to this but I would like to ask it explicitly. Why not swap the ID and also known as so that the ID is the short form the also known as is the long form. Did you think about that and Yes, Sam and I had a long discussion about this and what it comes down to is, I think it is cleaner for the ID of the resolve document to match the value that you put into the black box resolution interface. If that makes sense. And so I, I attempted to resolve the short form so I got back a document with an ID in the short form. I resolve the long form I get back a document with an ID. That is the long form. And so this, there's a bidirectional mapping between these two values, assuming you've stored the long form and can resolve the short form. And so by expressing also known as for the long form document to be the short form and then the inverse for the short form resolve document. We say that there's a strong relationship between these two. They represent the same did subject. But they are technically independent separate documents. Okay. Second question. Wouldn't it be better just to encourage in the spec. Using the fragment fragments in the various sections of the dock rather than using the absolute. Absolute. Or is that. So when we resolve the document, not going to using absolute references. Yeah. I'll just leave that off and say, you know, explicitly just don't do it. But I mean, I guess it's, it's purely an internal question, but yeah, just makes logs. Log files really long and harder to, to use so just makes everything harder to use in my opinion, even even though it is just internal. Yep. That's a fair question same and I also discussed that. And I think you've basically come to the same conclusion that we did was that this is probably more an implementation detail by. Or which is, you know, maybe we could change the language here to be a little bit more explicit or rather just omit it all together. An implementation might require that the did URL reference might be absolute before it attempts to dereference the value. It might not. But that wouldn't be spec compliant did spec compliant so. It's better to say don't do it because it's just going to cause yourself grief. But what about it would be non did spec compliant. The did spec allows for relative references. Right. So, if you don't support that if your implementation of this doesn't support that would be non compliant so. My thought was that we changed the language to prefer relative and then change the examples as well. But, but, you know, of course, allow it to be, you know, fully. De-relativized if necessary. It really is an implementation detail, but I think that that angling the spec to sort of prefer or recommend the relative references is better. I would say something like well not recommended an implementation could that might be sufficiently pushing against it. I think the biggest thing would be in logs and things like that you're just making it harder for developers. Yeah, that's fair. Yeah, that that doesn't substantially change the way most of the spec works. I think that's a pretty simple change. Yeah, that one's just yeah. And then, and then just the last thing was it might be worth putting a little note by the Genesis document to say that by note that the ID is not included in the Genesis document that is addressed later or something like that just so people don't look at that and say that's not a proper did doc. Right. I do have some discussion here in terms of what is different. Yeah, there it is. Okay. Yeah, I was I had gone back to it to look for it. I was looking as an a follow up note, but good. Okay. Sorry about that. No, no problem. Awesome. Nice work. Thanks. I'll quickly offer that as the author of did peer to and three, although lots of three was like community discussion things. I'm wholesale a fan of this and deprecating the other ones I think this is a much more straightforward approach. And, you know, down in the discussion of what's better about this than two and three, I think it's accurate. And sometimes it takes a little while to come to the right idea about how to make things like this work. I should also mentioned that the concept of having a short form and long form is not an original idea. It's just that was borrowed from or inspired by did I on, which does a similar thing but not using the same method that we are. And so this is a this is I believe the most straightforward way of doing peer dids that I can currently imagine. So, to voice the question once again for Timo on his behalf. You implemented did peer three. Should we just drop did peer three and turn what is did peer for into did peer three. I will know that. Yeah, because it would be confusing for everybody. You would have a useless method because nobody would implement it so I don't know why, why we cannot just The plan is to update the spec to deprecate 012 and three once this is in place. So it shouldn't be confusing in that we're saying don't ever don't use these other ones. It's not good to be an option to use the or a, you know, any sort of recommendation to use any of the other ones except this. It's not officially deprecated to expand that just a little Daniel Hardman who wrote did peer one is in favor of it being deprecated. And in method zero has never really been used and kind of existed as a weird compatibility layer with did key. So, the, the recommendation is that we actually deprecate still include the documentation, but move it to like an appendix and in reference it is deprecated the implementation details of 012 and three, which means that for would be the only remaining did peer now Malgo in current use. And I would add we just did emerge today that removes a lot of the extra text that was aspirational when Daniel wrote it but never implemented things like updates and CRD T and and all of those things. Those have all been removed from the spec already in anticipation of, well, I mean that stands alone that you know we're not going to implement that we're going to use did rotation as Sam talked about earlier. Updating is not ever going to happen based on our practical experience, and then same idea did did zero has never been done it did key is perfectly good so no need for did zero and one, one, two and three are replaced by this yeah. Well, and to Kim's point in the chat, where did you find v3. Had I not committed v3 into the repo itself this could be called three and that would have been better. But we're just moving along and you know figuring things out at the time and so the fact that it's for is a little bit of an accident of the timeline, but but it's definitely the cleanest thing to do. I don't really have anything else to say. Sorry, I yield screen share here. Yeah. Just just a question like so so we're currently implementing v3 should stop and go to v4 or was the idea. That's what I think, but we definitely care whatever one thinks. Because we had this, I'm not so involved in the development of AFJ right now but I think we had this discussion about v3 and should be implemented and how and when and yeah now I was a bit confused like if we should then finish it or throw it away or how to how to proceed. But yeah, I guess that that's I would expect to go directly to v4. Actually what we what we were we're implementing is the dp2 into the exchange. And I think the same was for every vcx. So yeah, maybe the answer is the same right. I mean, we have to drop this to support and just go to the before probably. Okay. I feel like I have to apologize for the thrashing a little bit on this as we're been trying to figure this out. You know, we've gotten smarter and I believe that the solution of did peer for plus did rotation and did conv one is substantially better solution than what we've discussed before but it does feel like things have moved around a lot. I totally acknowledge that. If I had a time machine I'd fix it, but mine broke. But I do, I do acknowledge that it feels like a lot of stuff has moved as we've had this under discussion, but I, but I feel like our efforts together as a community have gotten us to some place that's substantially better than where we started. We're at the end of the hour any, any comment. Any other comments, questions, thoughts. Thank you everyone for coming. Appreciate the discussion today. And Daniel Daniels work and all the all the discussions and that the people have had that have helped make things better. We didn't get to push notifications even and so we'll we'll be able to follow up on that next week. But thank you all for coming and keep up the good work. We'll we'll keep moving things forward. Thanks folks.