 All right, welcome to the June 28th areas working group call 2023. A number of things on the agenda slightly out of order but I'll get that in when we get into the topics. We'll start with the marketing group update and then I've got a pile of RFCs PR so that I'd like to merge if we can get to that and then we'll see what else we can get to. This is a Linux Foundation meeting and a hyper leisure meeting so the antitrust policy of the Linux Foundation is in effect, as is the hyper leisure code of conduct. It is not the 21st of June so we've got to edit that. Here we go. Please add your name to the list of attendees I put it the link to this in chat, so feel free to add your name. If anyone would like to introduce themselves or make announcements the mic is now open for anyone to take that. Feel free to step up for introductions for those new to the community that want to introduce themselves and talk about what you're doing in this space we welcome that. All right. This announcement we're going to talk about in a bit I believe so I'll defer that until the discussion topics. If that's okay. Release statuses. In Python RC one of release 082 has been released. There is probably one more PR to merge into that so we're holding off on a final 082 release. We do have an issue with GitHub actions related to a move to Python 3.9. Basically we're in a situation where we've got a couple of integration tests that were fine on 3637. And we're fine on 38 and 39 locally but but hang on GitHub actions 3.8 and 3.9 without any feedback at this point so we're a couple of people that have been looking at are at a loss we're stuck. Anyone can help out on that we really really appreciate it so let me know if you're able to help out or willing to help out. We really need to get that one resolved. We'll take some other actions but we need some new eyes on that one which is just a weird one and very very frustrating. Any other announcements about frameworks or any other releases release updates and so on. A couple of things to note Aries Asian test harness failed last night to run I don't think any of the tests ran or very few so I'll be investigating that in a bit this morning. So heads up on that. Aries mediator service. We'll talk a bit about this but we really would be super useful to have this updated with socket doc so that would be a nice project if people are interested in and are looking for something to do. We have something noteworthy Steven. What's that. We, when you were asking about framework releases we did integrate if J040. By fold last week so that's a huge win. Thanks to all the hard work from our friends at animal. It seems to be working great. We've got one thing that we forgot to fix ourselves but yeah it's working great. This of course got all the new shared components in it with we're not using in the SDK anymore. We're using all the rest libraries like ask so they ask car to interact with the ledgers and the wallet and non creds RS and all those other shared components were using as well, which worked great. That's awesome. Yeah, that was the fact that it ran, you know, even with small issues that it ran on a first go was amazing so nice work on that. Thanks Jason. All right. Discussion topics. Helen Alex, do you guys want to take over the screen and talk about what you're doing or just talk about what you're doing. We can just talk about what we're doing that'd be fine. So the first official meeting of the Aries marketing committee took place yesterday. This is, I think we're going to meet just once monthly to talk about updating all things Aries branding messaging, etc. So please, you know, starting off please encourage anybody on your team who might be interested in this effort to join us. The, it is on the groups IO like calendar reminders or whatever so folks should should get them all the information's there. We also have a wiki page. Just if you click backwards a couple times you'll see it so anyways it's, it's in the Aries, you know, a branch of the Aries wiki. So all the information's there to join please, folks. We will be inviting some speakers to come and clarify a few topics for us. We're looking at sort of how to explain Aries externally to non people that are like not really familiar with the project or self sovereign identity or what a credential is like kind of you know how to, how to explain things at a very kind of, you know, basic fundamental based way, and then also how to explain to those developers kind of who are in the open source community who are more familiar with it and that kind of thing so kind of both sides because I think that there's some you know we've sort of decided that there's some some things that one side would want and not the other and vice versa. So Alex, I'll turn over to Alex here in a minute to talk about the questionnaire but we would love to get some feedback from the community on this it shouldn't just be coming from Alex and myself and but so we're hoping to get some some feedback in a simple questionnaire so Alex do you want to explain what that process is and what the goals are with that effort. Thank you. I think you said most of it very well so we're going to put the questionnaire out if you see anything resembling a questionnaire or survey come your way. Please take the hopefully two and a half minutes it'll take to complete right there and then be much appreciated. What we've achieved is to is to flesh out understanding of the things that you guys know in your daily interaction by areas. So when a person needs areas comes along where do you point them. And what are the most important things to be telling other people about areas right now. And maybe what are the challenges people are facing when they hear about it or what's the resistance you're facing you're hearing about it. Sounds like a lot of things we're going to sit down some great targeted questions probably a ranking question but a free text space you can just give us your thoughts and get the core proposition of areas together because it's still very clear that there's clarity about the lack of clarity that we that we need to get a solid core understanding of what the areas proposition is right now. I know that's quite broad, and then we can specialize it in depending on the target audience for someone looking at this it's this if it's for exact as this if it's for a developer on board into to leverage it or it's this. So yeah, short version is, I think he'll, he'll think it'll be next week timescale sub the chain maybe see a questionnaire survey across your path please. He'll be very quick to complete and we'd really appreciate your input. And I would just say one of those questions that will be on there. I sort of alluded to it is any links to videos, meetups recordings blogs papers pages on your company's websites like anything that you that has been created to explain areas specifically that you links that you send to people maybe new developers come on your team and you send them, you know, a handful of links, we're hoping to create kind of a, like a dashboard of sorts a community bulletin board of like helpful resources. So start or start getting those together organizing those, because I think those will be really valuable that just as an ongoing effort to always kind of be updating hey we just had this cool event I spoke it. And this is the record whatever like, you know, we just just keep kind of ongoing. Yeah, bulletin board of sorts with resources, public facing resources so start getting those links together but we'll be organizing and collecting those in that as well so if you want to be featured on kind of the main areas page with that with your information. That's another kind of added benefit to filling out the questionnaire. Excellent. So one of those in the community that's for sure, having them organized would be very useful. Yeah, like, there we realize there's so much content that's already made by everybody on this call that let's you know let's maximize it and maximize visibility on it. Absolutely. Excellent. All right. Any questions comments for Alex or Helen. All right. Okay, next topic is areas are FC PRs. This is something we do regularly that haven't done in a while so there's a long list of PRs in the in the community to be reviewed. Have I got it right okay you people can see when I scan back and forth across my screens. Yes, between the tickets and the PowerPoint yep. Yeah, good. Thank you. Sorry about that. I just wanted to make sure zoom was working the way I thought. Let me do one thing before I can share this and change anything to an editor copy link. And I'll put this in chat, as well in case anyone wants to go through it, and I'll add it to the really quickly should done this before sorry about that but I want to get it into the notes. So we don't lose it. Okay. All right, so we're going to play let's merge I'm going to keep in this view because I've got links and things to show 789 at clarify so I'm going to what I'm going to do is just list these off and then go through them. What I'd like to do is get to some sort of resolution on these. And ideally we either merge them close them or identify questions to go back. So definitely need your feedback and and input as we do this. So looking forward to that is what I'm looking for so 789 is adding a clarification to a to the thread RFC about the handling of an empty thread decorator so basically this is a clarification. As noted, some frameworks may send over a till the thread empty, which causes other frameworks possibly to crash to to throw an exception, or even to reject a message when a when an empty thread decorator comes in. So simple messages don't do that don't send those over if you're going to have an empty one just don't even send it but if, if someone does happen to send one over. The framework should be defensive and they're handling of it shouldn't reject the message simply ignore the decorator. So that's the advice in that. So if I come over here to look at the change. Simple clarification saying it's not recommended may send an empty thread areas agents receiving a message with an empty thread must gracefully handle such a message so that's the clarification. Any comments or any questions about merging this. We've had some conversation on this couple of suggestions of maybe to make if you're going to put a thread in and you have to put the did the thread ID in. But we don't want to make that a require as noted so we think all of the three of the frameworks now handle this at least a VCX and go we're not sure of their status. We're not going to be merging this one right I'm going to go ahead and merge this one I think this is probably the only one will do on the fly because the rest will require updates, but we have at least accomplish that. Probably should have put in the notes that we what we did. Oops. Okay. I'll try to keep track of the status as we go. Each five is another one that I put in based on activities in the in in the day to day work going on in this case with bifold the bifold team. Why is the well known goal codes Aries rel and Aries rel build again a clarification. Relation rel is a relationship in this case to the Aries rel and Aries rel build indicate that the goal code is to build a relationship. I think in the, in the item to say these should not be used when just establishing a did calm relationship but that actually happens to be exactly what we needed for. The change is just to remove that restriction and since sometimes that is all you need so let me get to that change 785. Let me see the where I've got things placed I can't see it so I'll just tweak that to say 785 so I stay on the oh I wasn't even helpful to do that but anyway. Basically a minor change that says this should not be confused with building a did calm channel. And, and in fact, it could be used for a did calm connection itself is not the relationship but would be used to carry out interactions to facilitate their relationship. And so, basically this is saying this may be accomplished by establishing updating or deleting a dead calm message connection that provides a secure communication channel, basically saying it's okay to use this goal code for that purpose. It's not specifically banned. Any questions or concerns with that. Right. No comments. Are we okay to merge that one. Any objections, no objections. Okay, I'll mark that as to merge. Then I wanted to throw this. Basically these the goal codes is and and other events are needed to deal with user experiences user experience. So the this one came about because of activities on the BC wallet. The goal codes to fine tune the UX so that an event, an event occurs that triggers some behavior. In this case, lacking a goal code on the connections mechanism. The BC wallet is now assuming that after a connection is established something else will happen, either an offer of a credential or perhaps a presentation request. So this this issue came up because there was no other action other than we just wanted to create a connection, but there was no events no logic in there for the wallet to use in in making that user experience distinction. A we need goal codes to help out in the user experience so we need to define new goal codes and use them in places where they're enabled. Also brings especially the concept of done in an action so that we know when we're done this is one sticking point that we've seen and we asked people to think about as they are developing wallets and things which is, once you get to an interaction with another party, and you get to the end of it how do you know you're at the end of it or, or that the other party is going to continue on with some other staff. And so coming up with the concept of done is something that the BC wallet team has been thinking about and trying to figure out how to accomplish, particularly with goal codes. Any feedback on that would be of interest and any other experience in developing and tuning user experiences would be good. Okay, leave a moment for anyone to comment and we'll jump to 784 to show that one while we go. This is an interesting one. Basically, as you can see what it does is there's a table in the revocation notification v2 that says hey here's the type of revocation notification it is that the type of credential and examples of the format. It adds in addition to Indian on credits adds just plain and on credits, and uses an example of a did as the, as the mechanism, the identifier for the credential held by the, by the holder to say, oh this credential this specific credential has been, has been deleted, or has been revoked. Sorry. So that's the purpose of RFC 721. It's hard to tell whether this is a clarification or a minor update I would lean towards this being a clarification. I hope that this is still in the proposed this 721 is still in the proposed status and the actual current revocation notification is 0183 which is a bit problematic but that's for another day. This kind of implies if you're adding another revocation format, it implies that you're going to have a different handler for it, you're going to, you're going to get this message and it's going to say a revocation format and you're going to handle it with one way with an indie and on credits and another way with an on credits. A bit of a clarification, I think it's mainly a clarification that those will will not appear since it's still in proposed. It doesn't really matter if this is a clarification or a minor update. Any comments on this one. Anyone run into this or, or have an issue. Any concerns about merging this I think this is a pretty straightforward one it's a doesn't really matter since it's still in the proposed state whether it's a clarification or minor update any concerns with merging this. No concerns with merging this but a comment on the subject at least that I think we should basically just treat this like the did spec has did method registries when there's a change to the method registry it doesn't change the did course. I think this is a similar change. So I think we're, I think we should be good with making these sorts of modifications without needing to grab the specification for the protocol. Thank you. Thanks. Okay. All right. On to the next one, which is 780. Let me jump to that one. So that I'm ready. Okay, we have an entire brand new. RFC. With this one. I think this one is pretty straightforward we have had a few people review it basically this says. When you are issuing a credential and particularly for images and perhaps other data types in those attributes that you're issuing the recommendation is to use a data URL. Those unfamiliar. That's a, that's an image. That's not what I wanted to do. Just trying to click that button. So a data URL looks like this, which is you've got an attribute called a photo and then the data URL looks like this. So that is a hard coded. You've got the the mind type, an optional semi colon and base 64 to say that the data is base 64 encoded a comma and then the actual data. And so this particular data URL is that image that I you saw slightly earlier on the screen so this is a itf RFC 2397. And I think that the, there's been a few people read through the RFC others are welcome but I think it's ready to merge. Interestingly, another use of it is JSON can actually just put in as the data type is JSON and either base 64 or not. But that would help in places where for example, in a non credits where you want to have an array. You cannot have an array in an on credits. So, not, not a valid. Not you can't do that because of how the non credits signature works so you can't have an array of data elements but you could have a single attribute that is the array. So it would give an indicator for a holder to say oh by the way this is is JSON data and they might have a chance at being able to display it in a reasonable way rather than just dumping a bunch of JSON on the screen. So lots of flexibility in there. There was a discussion about whether this is an Aries level or should be a credential formats issue at the at the specification level of credential formats like a non credits or the W3 CVC format. So those looks like I had it. Since those do not deal with pretty much don't deal with the data I don't think it's appropriate personally that that those go in the non credits you can put whatever you want. Those an on credit W3C doesn't care what kind of data or the format of the data you put in the attribute. It's really up to you. It just makes things a whole lot more flexible and easier to use easier for things like holders to be able to display data if a data URL is used, particularly for that photo use case I think that's one that's going to come up a lot and needs to be there. Any comments other than Colton's comments in the chat about this one. Anyone want to say anything about it. Any objections to this being merged. And that could be you just want to be able to read it before it gets merged to make sure that the RFC is complete. I have to put these in capitals. Okay, we're going to go with that. 768 is the proposed legacy peer did method. So I'll jump over to here. I'm not going to be as easy to do this one but let's see if I can just get rid of that and 768 and see what the changes are so this is was proposed as a way to deal with unqualified. Unqualified dids using, sorry. Yeah, unqualified dids that are being used in peer to peer relationships basically in did calm. We since have updated and should this should not emerge the latest solution is we would adopt in peer to and did peer three. And transform unqualified dids which is what is talked about in this method into did peer to and then subsequently into did peer three so encode the did doc that was shared in the end as the unqualified did and then transition encode that as it did peer to and then subsequently encode that into into did peer three. Since we already have the did doc so I think this one is to be canceled. Any objections to canceling this one. Somebody make a comment just for the fun of it. Not even that comment. Perfect. This is 55. This is a very large one, one that I think is now ready to merge one that I created. So, and I've done a few presentations on this one. So, the background for people who have not heard but I've talked about it lots is OCA is a mech OCA for areas uses and the overlays capture architecture specification OCA in a way that allows us to make credentials beautiful by adding multilingual support and issue or branding to the display of credentials, which is particularly useful in holders in wallets and things so this has been incubating for a very long time and we've been making minor adjustments as we've gone along. I've given updates presentations on what updates have been made as for things we've learned while implementing it now I'll talk down the bottom here. Since the last time I presented this, and we talked about it only two changes have been made the addition of a display of a stacked view in the style guide itself so that was assumed but not actually displayed in the style guide so that is now there. And we've added a data element called watermark to the meta overlay and that is used in particular for when showing a non production credential, which for developers happens a lot. Putting a watermark on so the difference can a difference can be seen between a, a production and non production credential in a wallet. Excuse me that's gone on is areas by full now has an MPM model that is published on on. Published on the MPM repo called hyper ledger slash areas OCA that implements the pulling in of a. OCA bundle for giving credential and, and grabbing the data and using that data for the display. And there's also a repository created in BC gov called areas OCA bundles, which implements a way to publish OCA bundles anyone can submit a PR of an OCA bundle with appropriate data associated with it that data gets humanly verified gets checked out and as long as the, you know, the rules are followed that it is actually an OCA bundle, and the bundle points to existing identifiers. It will get merged and anyone can use this as they wish. So, with all that, are we able to merge this, any objections to merging the OCA for areas and the seven, and it comes along with a RFC 756 OCA for areas style guide. So both RFCs are included in this PR. I'm not hearing objections. Anyone want to comment on this whole idea, the lunacy of it. I'm going to mark it. Great. And I think we're we're also thinking about trying to make this work for the web. So we had a conversation at our last by full user group meeting, because we want to make like this this will this package will work in in bifold so react native but we also want to see about adding support for the web so that if you're making something like traction or your own thing. You can have the same look and feel that you would get in the wallet so you can I understand how it's going to look when you release your credential. If you've got any interest in that feel free to find us in the bifold channel a Keith would be champion championing that endeavor. I'm just going to show off the OCA Explorer but I don't have it handy, but but it is an example in this repository. We have a published get have pages that displays it. Okay. That is to be merged which makes for an easy next one. That is 740. I did. So 740 is an update of the read me of the overlays capture architecture RFC 013. Basically, on that one, let me jump to that one. Well, that doesn't look right. Or is it sorry about this. There it is. This. So, there is a RFC overlays. RFC 13 is called overlays. And basically what this RFP or RFC was is a definition, an early specification of OCA. Since then the specification has been moved into the human classes foundation has its own spec has its own repository has its own working group. So the fact that we've got an early version of the OCA spec in areas does not make a whole lot of sense. So as part of the previous one. So this is 755 and with agreement of Paul is that I basically have updated RFC 13 to say retire. And so I, there's no need to merge this PR. And we can just close it since since the update does not make sense the specification is published elsewhere. Any objections to merging this and retiring this. I believe that is the last one of the easy ones for me. Hey, I got a question on that last one Steven, what does it mean to be moving it into the human classes foundation. So OCA this one was written in 2019 this RFC 13 as you can tell it's very, very new. Since then, although this was there as a as a as an RFC that was proposed it basically was merged as a proposed but never updated or never moved to a higher status. Paul Knowles and collaborators then took the entire specification and just opened a new specification at human classes foundation. And that's where the, the OCA spec resides and we've got pointers to that in the OCA for areas. We are in this one and we've got in the, in the where we retire 13, we also point to this work has been moved to that organization in that repository. That makes sense. Cool. The next one is a new RFC that adds push notifications as Expo protocol. So there is, this is mobile specific push notifications between a mediator and mobile wall say hey I've got a message for you. There's some administrative work if we do want to merge this one. And there was a question raised by by Sam that has not been answered. This is 745. Other than that, I am not qualified to comment on this one and and so would suggest anyone with that expertise take a look at this and add a comment on this. And this does supplement 699 and 734 which are other forms of push notification. FCM and APN S again I'm not don't know enough about it so I can't comment on this can anyone has anyone looked at this. This is ready to merge. It looks complete to me. And so I'd be happy to merge it as a proposed. I haven't actually read this but just a thought that jumps to my head and probably maybe not correct but for an RFC like this is technology specific like oh yeah. Expo versus Azure versus Firebase versus yeah I just wonder if there should be a not I don't know if it can be but more more agnostic or it's okay to have this technology specific RFC so it's really open. Yep. Has has anyone implemented notifications, sort of but not in this, not using this protocol. What, what do you do. We were just adding a metadata property to the did calm messages that would say if it was read or not and then checking that was kind of it was not a very good. Oh, I see to me yeah. This is more specifically for push notifications for a mobile app. As opposed to the messaging. So, for instance when the mobile app is not connected to the mediator directly and the mediator can push some form of notification to the mobile app. Yeah, while the app is offline. Yeah. Okay. I think the recommendation here would be to see if we can get a session at an upcoming meeting to to discuss notifications and where we are with this and have somebody who knows what they're talking about lead that discussion so we'll see what we can do about that. Yeah, and the comment about the different types of protocols with like Firebase etc makes me wonder if I don't know if there is but if there should be a more generalized method for, or like RFC for push notifications that allows for the different mechanisms out there to be implemented. So this is a matter of interest how come there's four, or there's three. I would have expected to see. So there's Expo, FCM and, and that other one. APNS. How come three, when there's only two mobile operating systems. Well expose their own. That's not. Okay. That's what I'm saying that's part of, that's probably react native that's an Expo native solution. Okay, it does it cover both OSes. I believe so as does as does Firebase and maybe Expo calls it all the ones I'm not sure I mean Firebase people are so Azure is universal. And there's others out there but those, those are the most popular. I've never really looked at Expo implementation. Most of the world uses Firebase. You can also use the, you can also use the natives like if you just wanted to push notifications rather than you could just do that as well. Yeah. Okay. Okay, thank you. Yeah, let's do this one as well I want to get to the end of this we've done almost enough. We're almost to the end. 744 is adding a timing capability to the mediator anyone with mediator experience that's dug into this basically this is saying how long and recipient is willing to wait to receive messages as they are arriving so the generic protocol says give me M messages that are Q, you know whatever messages are queued up to a maximum of M. And then the mediator would say oh I've got some so I'll send those across what this adds is, if there's less than M then I'm willing to wait and milliseconds for more messages before, before sending. So if you've got none in the queue, I'm still going to wait, you know, 3000 milliseconds to see if more arrive, because as a holder I'm expecting more to be coming, or if there's 10 in the queue, and I request 20, then wait some seconds to see if more messages arrive. I don't know the utility of this. Since it's an optional one and there is an implementation and it was found to be useful. Does anyone else know if this is a useful feature. Just from my perspective this seems more applicable to when the agent is connected over HTTP rather than say web sockets. Yeah, basically informing the mediator. How long is my connection time out. Yeah, so it's a more graceful way of doing it rather than just having it cut. Okay, and the client's basically saying please give me a bigger batch if possible. Yeah, yeah, might help at minimum to have have that. Okay, I'm going to skip past a couple of these. The rest of these so we've got a few more to do. Perhaps next week just to finalize these other PR is a very old I'm going to try to get them just closed because I just think they're too old to look at. And last thing I want to do is a pitch for a proper RFC website so this is something that could go into the marketing. So, Alex might be useful here. I spent some time doing the acupy.org website, basically using M docs material as a default. My process was just to create a new repo add welcome content for the repo and then a script that copies all the content in the acupy was every and defile into an appropriate structure on the new static website. And then just a manual process to update that website nice to have with GitHub actions. So, repositories would be something like welcome and administrative page to say you know the life cycle of RFCs and how to submit an RFC and what the process is. But then this is the really important a IP one would actually have a list on a clickable website not a GitHub repository with a bunch of read me's but you could actually go through and see all of the IP one and in a nice published form, as well as, you know a column of other RFCs that are, you know, indifferent in proposed states. So I think this would be a much better way for people to be greeted by areas RFC and be a much more comfortable way for them to read them so I throw that out there I've got it on my to do list if anyone wants to help out or work on that with me. Let me know I'm more likely to get it done if someone's pushing me on it so I'll throw that out there. And with that will end this part of the discussion with just a couple of minutes left because I wanted to hit a couple of other things. Any final comments from anyone on that section. Awesome. Okay, mediators. We did have the presentation last week lots of good stuff in there in DCO has open source socket doc awesome work on that which I think this is a total game changer and how to construct scalable mediators. So I think this is really great work. So mediator basically turns it from being the meat, the mediator from having to worry about WebSock it's to simply having to worry about sending and receiving HTTP messages so much easier to make completely scalable so the next will be, as I mentioned Aries mediator service AMS be updated to use socket doc I think that's the way to go. So, we'll see how that goes if people are doing that work or or just what becomes available for that but I did want to highlight that in DCO has open source that repository that we talked about last week. I wanted to address it or to use it. Last topic I wanted to go over and Alex, Andrea, I'm glad you're here. There's like to highlight two things that have been commented in the deep peer spec. Issues were raised. So one of them was area errors in the example so a clarification is needed. The specification is about hex and code of shot 256. And attempting to do that in implementing did peer three in areas BCX this issue was raised. So really good if we could take a look at that. As well. Daniel Bloom posted notice of a couple of inconsistencies in did peer three that I think should be resolved. Daniel merged this a little quickly. We explained why but I didn't think we had quite enough review so it's not surprising to me and I think it's not a problem for us to do that but basically the simple is removing the dots because the other methods don't have a dot in in between the three of the method number and the rest of the did and then use multi base multi Kodak hash. So we know exactly what hash algorithm is being used and hash algorithm and base encoding of the data. So again I think those are two wise changes to put in. Alex you're here or Daniel Bloom you're here. If one of you could put those in I was going to do it but I really don't know enough about the multi base and multi Kodak hash to explain it. I did notice that there are multiple shot 256 algorithms and so I think we have to be more specific of which one and I wonder if that's related to the other issue that was raised. I'm going to throw that out to others. I see Daniel is not on the call anymore. He was on earlier but so he raised at it Alex thank you for taking a look at that that'd be awesome. I'd really like to get that as clean as possible and keep that updated. I would note that one of the PRs that was recently merged in the did peer spec was to add was to remove the big red text warning text. So that has been removed from the specification. There used to be some warning text saying yeah should you really be using this and we really think this has the did peer spec and the did peer method has a lot of valid use. And so we did not like the fact that there was this kind of ugly red text where no replacement was particularly available at the time so really good to see this that update made. And with that, that covers all I wanted to go over. I'm exciting one once more I went through this added a couple of issues Timo posted a migration doc for unqualified dids, moving them to qualify dids. Again strongly encourage people to read through that. Take a look at it at comments via issues into about the document. I found it a very useful one and and thank you. And with that I will stop sharing and give anyone a last second to respond. Make any comments, and then we'll wrap the meeting up. Excellent. Have a great day. Great rest of your day depending on where you are. Take care folks back. Thanks everybody.