 Perfect. All right. For the for the second attempt, this is the second of August. We started in a month. Welcome the areas working group call for this week. We have great agenda. Some great topics today. And so we are glad you're here. This is an anti this is an anti. This is a hyper ledger meeting. And so the antitrust policy and the code of conduct are in effect. Meaning notes. Those links are in the meeting notes. Please reach out if you have any concerns there at all. You're welcome to add yourself to the attendees list with the link in the chat. Or make any other adjustments to the agenda that would be useful for the community. And we're glad you're here is anyone new today that would like to introduce themselves. I'm glad you're all here. Are there any announcements that should be on our list, but are not. All right, do any of our projects want to share release status or work updates. I don't believe there's been an AFJ or bifold call since the last meeting. So there's not likely anything there. Is that just a scheduled thing or is there. An AFJ has decided to move bi weekly, like every two weeks for the time being, and the call for bifold didn't happen yesterday. Okay. All right. Any other updates that folks want to share. Everyone was just really eager to get to our topics today, which is just fine. Yes, please. Jason from bifold in our last meeting we discussed pausing for August because we went down from about 14 people down to three and they were all from BC so rather than just have an echo chamber of a meeting we're just going to pause while people enjoy their summer and pick up bifold again in September. Okay, that is worth knowing. I'm going to add that to the actually the announcements probably since I don't. And AFJ went bi weekly. That's correct. Some just for the duration of summer. bi weekly for summer. Yeah, I guess for the duration August now. I hear that. Well, I highly support the ability of folks to take vacations. That's a fantastic thing to do. All right. So here's what we have on our agenda. Today, a marketing update from Helen and Alex Steven Kern with with a early, the areas project quarterly update a quick review that that's due tomorrow. Some update on did peer three as well some related issues there. And that kind of bleeds it a little bit into the unqualified did stuff that we have down below. And so we have we that that's what we have on deck for today. Is there any additions or changes or anything that we want to make to the agenda before we get going. Just wondering about in dvdr, and perhaps every Oscar artists components, you know, suitable for discussion on these calls. Yes, they can be they can be discussed elsewhere but they're certainly, you know, acceptable topics here. Okay. Yeah, I don't know we just started. I'm not sure if I have a specific topic. But I've been wondering about in dvdr we just started recently like kind of further playing with integration to every VC X and testing it out in production and whatnot. And I know I noticed like it's actually a bit. Compared to the Liby in the implementation I was wondering why, but I don't really have any inputs more of a wondering about other people's experiences with in dvdr and transition from Liby in the so perhaps you can put it in the node and if anyone has any comments on that and we can perhaps exchange it out. We will definitely list it there and it probably could be useful to have to look at what is coming in the in the next meetings but it might be useful to have an update on those projects, just generally speaking and some discussion on what's next there so Patrick, did you say in dvdr was slower or the combination. So in dvdr seems to so we are using. I'm not sure if it's fine if I go like the deeper right now, but basically in nutshell, vdr tools from our observation are fork of in the fdk was faster in fetching transaction from the ledger than in dvdr, like multiple times basically. Okay. Not so much has been spent on in dvdr optimizations ask our, we found the use of the combination to be way more stable and faster. So surprised you're finding that on in dvdr specifically. So might be worth looking at. But we definitely have found the combination of using all three to be way way faster like significantly faster like we had a deployment of the areas media mediator service for example that was unstable and almost could not could not hand a load and the transition to ask our was significant and much much better. Oh yeah so just to be clear, in this case, I, we haven't actually tried as career, we were, I was testing in isolation in dvdr and like, you know, the implementation ledger client. Yeah, definitely put things you find out there. And let's take a look at the code in there. So the issues on the dvdr repo. There hasn't been much feedback on that one it's basically been done and and and working. So it's working, but nobody's really done a whole lot to improve to, to look at specifically on speed for that so. Yeah. I was going to steal more, more, more minutes let's let's just hold the agenda. It's good to hear you using it though that way and testing it that way. Absolutely and and that that's that's great to hear. Yeah. I love, I love topics that we talk about because people bring them up and want to talk about and that makes me very happy so. So I appreciate you bring that up. So any changes or adjustments we want to make right Helen or Alex, can I do you need a minute. Yeah. So there is a draft page in the wiki for the new Aries language. You'll find it, let me grab the link. So folks can look at it. And it's going to be we started the basically started the rollout of the new language that was developed in the areas marketing working group. It'll take a little while just to get it updated in all the different places they use it on the homepage of the wiki on the landscape the project landscape on on hyper ledger.org which has just been updated yet as of yesterday so now we can update it on the hyper ledger website as well. Lots of place lots of kind of playing whack-a-mole with updating the area, the areas messaging but we are slowly rolling it out. So if anybody has any comments suggestions, etc. Please. I welcome you to join us at the last Tuesday of the month to talk with the areas marketing group and contribute your thoughts to this effort. So for Steven I just loaded up the new hyper ledger.org has some has some redesign going on there. And so that's, that's cool. And yeah, Helen, if you would wouldn't my drop on that link in that way we can get it in the notes and people can can find it to be awesome. Yes, I accidentally was going to send it privately to someone but here we go. Send it to everyone. So here this has got a draft page up here then. And so this looks far larger than the other than the previous than the previous page that we have any specific thing that you want to call out there. No just that top section has been updated the documentation page I'm still working on to include all those awesome links that folks sent me thank you so much. I do have other links that are helpful, you think would be helpful for either kind of businesses, business decision makers or developers please don't hesitate to keep sending them along. Again we'd love a really robust comprehensive ish looking list of resources for folks to see when they come to learn more about areas. We'll continue to be working on that documentation list and and updating this this messaging across everywhere in all the places. Excellent thank you Helen. Anything else about marketing. Alex anything else you wanted to raise. No that's perfect. It's actually happening. Very much appreciate all of your efforts in doing so. What is hyper ledger identity, like the focus this this quarter for the hyper ledger staff marketing efforts. So if you or your organization have events white papers, any, any sort of new products, any new blogs, whatever. I want to touch with the staff because they are trying to put together a kind of a best of recent news from the identity community from the hyper ledger identity community so please reach out to me or the staff. If you want to be included in those efforts and Sean Bowen like there's been lots of emails that have been sent out to the listserv with a lot of those details as well. Awesome. Next on the agenda is the update from Steven Steven do you want to drive around me to pull it up. Good thing. I think that's at the same thing twice. You're muted Steven. Sorry, go ahead and pull it up if you could. Thank you. Okay, so every quarter we put in a quarterly report to the technical oversight committee of hyper ledger. So this is the draft for areas. This will go in by tomorrow as a PR into the GitHub hyper ledger to see repo. So even if you don't review it here you can review it there and add comments and things but if you get a chance today to look at this. I'd appreciate it. Things. So there's a bunch of facts in here. There's an activity dashboard from LFX insights that show what's been happening and then there's a quick summary there so that link areas activity dashboard goes to a page that is for this particular quarter which is the April to June end of June quarter by the way. I highlight in this what's been going on. So you'll see that there's the AFJ, the move away from the Indie SDK. The addition of the CL signatures repo. Increased engagement across the three of the four communities, Occupy AFJ and VCX as far as coordinating. The new socket dock and a little bit of a touch on the news and the progress made on the use of OCA or overlays capture architecture. I then do highlight the each of the projects VCX this one I didn't I haven't updated the VCX one yet. It's the same as last time. So Patrick I'm glad you're here because it really appreciate either a quick discord note or or what you'd like to put into here. I know there's a ton going on in that so tweak this wording. I would dig in if if I need to I can dig in and sort of highlight what I think are the things but it'd be much better if it came from you. I'm not sure I've done the AFJ one. I think I have the 4.0 release was huge. So talked about that and the addition of the open ID for VCs exchange protocols, update on Occupy and then what I've been able to discern from what's going on in the areas and so that's basically it. If people could take a look at that and if you have any other comments or reviews or or emphasis that you think we should put in this, I'd welcome your contribution. I want to highlight here that here in the areas community there's there's two main bulk pieces of effort from not the code direct stuff but the community organization and Steven for years now has been driving up the quarterly updates and has been doing a fantastic job. So if you if you can help, then then please do jump in and review and and everything else. Also a periodic reminder that both Steven and I kind of just volunteer to keep this going. If you are interested in being involved more deeply in in sort of the, the, the community support aspect of areas, your help is always welcome. And I'm not really planning on going anywhere, but we certainly want to make it an opportunity for anyone that does want to be more involved to be able to do so. And so, so please reach out to either Steven or I if you have interest in helping with the quarterly updates or regularly running of meetings is something that is also of course always open. And so Steven appreciate your work here. There is also similar documents on a non creds and indie that I've done. I posted links in the, then each of those discord channels to let people know where they are and they can update them. Warren. Yeah, thanks Steven. I was wondering whether it's worth mentioning. Are there each of these projects where relevant stack up against the different AIPs. It's a good idea. And in fact, yeah. Yeah, that's a good idea I think that's more relevant within the AIPs are sorry within areas itself I don't know the TOC but I think that's a really good idea I think I'll see what I can do about adding that. I'll definitely need input. I think they just put that as a. Okay, I want to get this for next time. But I think I'll put it in there as a as a target. Great. Thank you. Great suggestion. I like it. You know when I look at the Steven it. Sometimes it feels like progress is slow and then I look at what's happened just in the last quarter and that's kind of amazing. I'm also. It's interesting that you know the comparison is quarter to quarter. It's a little bit unfair comparing just prior to summer to during summer just because of vacations and everything else that are going on but yeah. Interestingly, I mean I just put in, I just phrase it the way I phrase it every quarter but this was. Interestingly, it was up about 12% and down about 11% on up and up 11% the pre from the previous quarter so basically this is the same as the last quarter of 2022. Interestingly, it was almost identical to that but anyway, I just, I just say here's where we were quarter to quarter. Right. No, that's fantastic. And seeing this is actually kind of a good, you know, indicator of our progress so that's that's pretty great. Yeah. Anything else on the quarterly update. And I'll post when I post the actual PR I'll I'll post a link to the PR itself. So anyone can review it and comment on it as part of the PR. We'll see we'll go through it, probably leave it unmerged for about a week or so and then merge it probably a week week tomorrow, assuming no one objects, and they will discuss it. Awesome. Cool. Okay, next on the agenda is the did peer three stuff. This has had some forward progress, but but a little bit of weird, weirdity that we're trying to manage. Well, Bloom had brought up some some issues against the specific wording in the examples and caught some things that needed to be fixed. He has verified this and included some some example code using multi formats library and Python, you know, to verify and so I wanted him to independently verify that just to make sure that it was working. And we're having some trouble getting it to like merge GitHub's being weird. And so the work has been done there we're just trying to make sure that these these make it in here. These fixes specifically address some of the issues that the Daniel brought up into just into sort of clarify that and make sure that the encoding is proper. And so I appreciate Daniels. I'm just catching important things there, and we'll work to get this this merged. And I think that that does comprise the, the, the, the whole number of needed changes to the peer method spec for for did peer three, with one exception that I'll talk about in a second which I think should actually probably go somewhere else. And so the there's a handful of other related things to have happened here. And so the PR that Steven has created against the legacy did transformation that Timo wrote up, given their experience there. And so I've got comments from you here Steven on that in particular. You also mentioned the the adding it into the community coordinated update and there's a comment somewhere where Timo mentioned that that would be great I don't remember where it was. So anything, any commentary Steven that you can add about the transformation doc here. Yeah, I updated again this morning to, to add a few, few more things to try to simplify it. One of our developers who I don't think is here Jason Syratuk did some work on it and used it, and it provided good guidance. It's good. It's, I think I found the, the weird cases are the the edge cases or the reality of what we have an unqualified kids in the community so I think it's more much right now and then I'd like to take it over. I really wish Timo would merge this in to be able to take it from his but if not I think I'll take it from from the one I've got if you want to look at the changes. It might be worth looking at the changes that you changes from this time or the or all of them, all of them. I'll just look at the file exchange and look at in rich format. Yeah, basically just updating the how you go through the, how you go through it for the did peer. There was some extra. There were key and authentication entries, and then the way that the service entry was done was a little odd so I aligned it better and included rather than referencing how to encode it I put the actual encoding in that third step right there, which is just a copy out of the did peer spec so I did put a link into it but it's just a copy of what was there. And then the last one that was is was missing is the resulting string is a did peer to did and and we want it to be a did peer three. So we actually take the did peer to that we get and convert it into a did peer three, because we're going to use did peer three from then on. So that's, that's the changes I've made there I think they're all reasonable but team has had a chance to go through it, merge it, or, or, you know, provide detailed comments if it's not right. So that's one of review of that. One, ideally team emerges this in and then we can actually bundle it in. Were you intending to bundle it in alongside the community coordinated update RFC is that the right place to put that. Yeah, I think it should be an appendix in the community coordinated update. Yeah. I don't mind having a separate file just for clarity but then we could like kind of link it and make that happen there so. So, yes. What's that. I'd rather have it in line and just put it in there. Okay. Yeah, I think that can work whatever whatever's the most clear as the go right. Okay, sounds good. Okay. Um, so the last thing there's a there's a handful of open questions and come on and go away. The, one of the, one of the open questions has to do with how we want to handle. We mentioned in in did peer three that you need to know that the other party actually is capable of supporting it. Okay, because there we go. So, I did some thinking on how we actually would want the how we would actually want to have discover features know that you're capable of discovering or of supporting did peer three. This is a little bit slightly separate from the case Steven where you're talking about with the update where we're going to pop directly to three for use and we don't actually have to pause it. It did peer two. There's some efficiency reason to do that. And we know that it's already been transferred but the general use of did peer three requires of course that you first exchange the information. And then that you know the other parties actually capable of supporting did peer three. So, we've talked about using feature discovery to do that but with no actual details and that was brought up by by a comment from someone. And may have been REL that that brought that up is like hey this isn't actually documented anywhere like how actually going to do that. And so, I have some some notes here on what that would might be like that I wanted to bring up. And, and I think that this generally fits into the ability to sub to to have a feature type of did method that would allow you to disclose that you support a number of did methods in the in the process of doing so. But there's there's two issues that I'm trying to address here at the same time. One is is bringing sort of did method discovery into something that so that it can be a feature. The second one is how we individually figure out if you support. Namal go three of did peer. And so there's a there's a couple of options that I've got here. One of them is that if we write did method. So that it should be a prefix match to did peer. It allows you to specify or simply match the the start of the string. When you're when you're doing this so any, any did methods that happen to use initial characters to specify particular features of things did peer does that but this would work for any others that as well if they if they do, then you'd specify like did peer three rather than saying did peer indicating that you support all of those. This is a little bit also necessary with did peer as we have the soon to be deprecated. If not already did peer method one, which which is being deprecated in favor of upcoming carry things. But if you support portions of did peer, rather than saying did peer like this you can simply enumerate this sort of starting things that you do support out of did peer. That's one idea that I have the other idea would be that you we simply require that didn't the the the did method be indicated like this. And that any other details around the support could be included in some other attribute of the feature type disclosure so here's the ID, which would be of course the did method and there's another attribute that we can include that would indicate or help specify the the subset of features that you may support within the did method itself. And so I, these are the two ideas that I wanted to bring up in I have one more question related to this that I would love feedback on from the community. Before I take what I've written here and actually make it something that's like published in a regular way. And that is, where should I publish this. This, this could be an areas RFC. What would fit with the historical use of, of various RFCs and how we do this. It has been brought up that that areas RFCs is perhaps not the place to do this when when it is more broadly applicable. And given that this is a discover features thing that that can be used of course directly with did come in and doesn't necessarily relate to areas. And actually be something that ends up in did come.org is a way to to to document that moving forward. And so I bring it up here because it is of interest to this community, but I'm curious where this should actually land. I should mention that did come to work right now has the ability to post protocols. Related to a protocol, but not a protocol precisely. And so we would need some mechanism on did come.org in order to absorb these types of things that have previously been areas RFCs. But but but might be better homed, you know, in the larger community that's more anchor directly to did come. So, I've launched presented a little and launched a couple of questions I should probably share the link to make this a lot easier for folks to look at and so that link is there and I need to change the permissions on this I will do so. And now the link should work. The, so those are the open questions I have number one. How do how do we express the sort of the sub feature of did peer as it relates to did peer three, and also kind of related to, you know, did peer one, and the fact that you may or may not support that. And then also, where should this go in the documentation of the of the did method feature type of discover features. With that, I really want to hear what people think. So, I have a question of how valuable. Having it as part of discover feature because you basically have to use it before you get can make a discover feature call. You have to, you have to know the did method that the other party supports, but that's going to happen because you always pass a did in any time you do something like an invitation or QR code or anything. And not a bad mess invitation. What's useful here, particularly in the context of did Convy to is that particularly if you are planning to rotate away from one did to another did in a relationship it would be nice to know that the other relationship supports the new type of did you plan to rotate to. Okay, but chances are for did peer to three is we want everyone to be able to support to initiate with did peer to and use did peer three through the conversation which is why we want to propose a community update was we want everyone to shift to this. Yes, technically speaking, yeah, because so in it from the community coordinated update I think that still makes sense and we can still write the update to indicate that. Yeah, but this is a little bit more generically as it relates to just the independent to the community into use of did peer three independent to the community coordinated update. Okay. It could also be used to say, here are the did Indie networks that I support for example as well that could also be I could state that I use certain did Indie networks is the network the first thing after the. Yeah, the network. That's a great example then you're right because you could say here's you're right. Yeah, so so that's a little bit of a vote to support this as we design this, this method of discover features. Oh, I like that. Other comments thoughts questions suggestions. Yeah, I like the, I like the idea of matching. And the extension out to India is a is a good example. To your other question, it does feel like it belongs. Along with the calm. And not as an Aries RC. Exactly how to do that I don't know but it kind of feels like that's where it belongs. Okay. So I don't know if there's like a companion a compendium of things that go along with feature discovery as a as a mechanism and did calm and if so then it's one of those but I don't know how that's done today. So, um, the feature discovery is actually defined in the spec. So discover features is the protocol name. Here's an example that's included here. That we're off a link to but it actually comes directly from the did convie to spec. And it basically indicates that here it introduces the protocol and talks about why it's useful. And then here's the different states for this. So here's the relevant chunk here. So here's the the feature types that you must support a protocol goal code and header. And then additional additional values of feature type may be used and unrecognized values must be ignored. And it allows for extensibility of discover features for different feature types, and then, but it doesn't specify exactly where they should be defined that we had some lively debate about this. And it was basically this this feature here allows for the extensibility of it from from from this spec perspective. And of course interoperability profiles can can, you know, mentioned that the feature types in their in their usages as as must be defined so this could live in your approximate to did com. Because it is a thing useful to the broader community. It would be great for example if it was like a different feature types were linked here, but they ought to be defined some place. You can often define a feature in a separate protocol or separate thing where it actually relates and you might want to discover those relevant features but we don't actually have a good place to put one for did methods as it exists. And so it has been suggested Timo brought this up that that many of the areas RFCs that relate to this sort of a thing that are more broadly did come related shouldn't really live within areas. And so we don't yet have a mechanism on did com.org to document these sorts of things when they're not protocols, but we can make one. We can figure that out and have a place for those those features to go so that these types of things that are not protocols exactly, but relate to the use of protocols, have a home. And so, so Warren your your feedback that it feels approximate to did come and we ought to figure that out as is received. If I if I represent anything you said wrong please correct me. No, that's good. Thanks. Other comments. Suggestions. The fact that it still relates to protocol and how to actually use the protocol. It seems to me that it would still, it should still live in a similar structure to the way we do the areas RFCs. Perhaps it just belongs under a different sub folder within like did come itself. Like to go on did come.org. Well, so we're the, the protocols are, are they not all specified on the area site or they split between did come and the areas RFCs. They're migrating more and more to historically they've been on as areas RFCs more and more they're going to did come.org as it relates to sort of did come generally and not specifically areas. This is an example of that where like disclosing support for did come or for did methods using did come discover features is more did come related than pure areas. What would it not make sense to launch a separate did come RFC location then. Yes. And I think that's what Warren was getting to is that something like that should exist for something like this to go there doesn't have to be called RFCs exactly although it's a decent pattern. I mean that's an effort that's long overdue that having areas RFC as published only as GitHub readmes is, is terrible. So, we need something to hold back Steven tell me how you really feel. I've been wanting, you know, I wish I could find the time I know what we need to do I did. We did a similar thing on Acapai to publish all its readmes to a to a reasonable place, and it would be pretty easy to do that. I just haven't had the time I'm sure I'd love to, I'd love to get it done that we could publish these out to a website that would actually be useful to people. So, I wonder if we don't want something like on did calm, you know, optional features. And then there would be a way of describing linking those where appropriate to feature discovery and also linking to protocols. Be they hosted on did calm or be they hosted somewhere else. And it's a way of kind of tying stuff together like a registry, if you will, of stuff that we know about that is. I'm not sure if that's the right name but because it and it's all optional so it would be the optional features and then they would link to their respective things. I'm going to bring I'll keep writing this, of course, and then I will bring this up to the to the did come users group where the who's over that sort of thing. And we'll see where we get to I and figure out how to make that happen. One of the things that I do want to be involved in is that I think the book needs some better rendering and either using mk docs or docusaurus. I think would be a great way to take the book content and render into something far more usable referring Stephen to the work that you've done with the with the occupy docs and also the ASJ work that has been done in a similar way to make it more nicely rendered and browsable and usable. And so there's some there's some options there as well. We may end up with just for logistical reasons, because of the way that that sites built we may end up with that on a sub domain like a book. But that that's really an option there. Just, just for advice. kfj is in docusaurus and I don't know how it went but I tried to we tried to do docusaurus for occupy and it was really complicated so we just gave up and make docs was so much easier. So, just a That's worth knowing I'm going for easier rather than yeah so maybe maybe make docs is that how you pronounce mk docs is that Yeah, I think mk docs or whatever but the material for mk docs which hyper ledger has an extra license for has extra features for not sure how needed they are but it was dead simple to use and then it was so it was, I spent way more time worrying about content than I did about trying to figure out how to get, get things connected in a way that was useful to people. feedback. That's good feedback would be hosted outside of hyper ledger will be over and did come which is managed by the diff, but still worth knowing for those extra features anyway. So Sam, you're talking about here about the published form of everything. Yes, I'm still going to have a place where requests for changes can be applied. Yes, that still works via just regular GitHub stuff and then it's just rendered into something nicer. So there's still a repo behind it with with the same review processes and everything else that would occur there. What's the difference or at least the rendering. That makes sense. Yep. It's hard to beat GitHub for process management of this sort of stuff. Okay, Steven there are some open questions here. Are those mostly resolved in the updates that you have submitted, or are they do we need to handle these independently. I think we should just. The answers after I've played with these a bunch probably we ignore the first one and the second one is did calm messaging. One of the things I added to Timo's document is he only mentioned in the agent but I believe all three are used in different places so I made sure that if you come across an unqualified did that has any of these three types they all become the last which is did calm messaging is what they it should be. So that's complicated because we need to use the type in order to discover whether you're capable of receiving did come to V2 messages or not. And did calm messaging is designed to indicate that you support did come V2 message envelopes. Oh, okay then this is an issue. What should it be if we're just using did calm one. I think it is defined what it should be for did come V1 and a proper did doc, and we should use that one I think I don't actually know what it is. Yeah, but there is a defined one and we need to not, we need to not add confusion by using the same one that did come V2 uses. I thought that's what the except field was. Yeah, I thought it was the except field that use that. I don't know. I'll do some research on this and we can figure out what this ought to be. Okay. So that one and then the other thing is the first one I just got sort of hung up on. I guess we should just ignore it and you just get the keys you get and you put them into the did doc. So first now we have derived the key agreement key for the verification key. And and I guess we keep doing that because we already have the did doc when you when it's in a qualified did we already have it and so this is the the key only exists transitionally until you you know you generated the did peer to the did peer to string and then immediately generate the did peer three for it that's all you ever use is the did peer three one. So the question of during that transition during that execution of that algorithm, do we explicitly generate the key agreement key and it just adds more work so my thought was we don't. But one of the things we should definitely do going forward is is never assume that the verification key should be used for the key agreement key. It's a separate discussion but but we should be in my opinion we should start to be explicit about the key agreement key. Yeah good conversation but I agree that we should leave it out of this one. We should. Yeah. Very cool. So we only have five minutes left. We talked a little bit about Indy video and ask her and I'm going to keep this in the notes so that I can. So we can explore it. Why did I hit that we can explore it as as future things. One of the topics that I wanted to at least briefly raise attention to was the the AFJ has announced their goals to to coordinate efforts to bring into compliance with the European Union digital identity stuff and the the architecture reference framework. And it was raised without response so far really in in our channel whether this was something that we were going to pursue as a community directly that we were going to coordinate around the the types of requirements that were necessary to become compliant with the with the EIS 2.0 and the architecture reference framework and the in the protocols and the credential types actually mentioned there. And so I wanted to briefly bring it up to see if there was any sort of initial responses to that. And then to see if we should if we should organize community time towards towards that goal or not, depending on what people are doing. Any any comments. I think we should organize community time because I think it's it would be useful at minimum to understand what what the different groups within areas are doing and try to align as much as possible RFC's have been a great way to interrupt suite has been a great way if we can keep doing that I think it's a it helps everyone. Steve, your hands up. I agree with Steven. I think we should definitely look at all the requirements and see how we can bring whatever it is we need to bring in line with them, because that will make our products and specifications that we're building more more marketable more applicable and the European market especially. I agree with that I just wanted to add a plus a plus one to that I was pleased to see Timo's announcement from animal on that and if there's a larger community effort that then I think that would be welcome as well. Just a question. Is there any place I can take a look for some sort of brief conclusion what what are these regulations and standards, the UDI and RF, ARF, kind of refers to, you know, what are the concerns of these documents. There's definitely some links I don't have them off the top of my head and we just have like a minute or two left but but we will gather those. If you look up, just for anyone looking immediately. If you look at Timo's post in AFJ, he talks a little bit about what's required without getting too deep. I can indicate that involves the open ID for VCI and VC and VP protocols. And involves SDJOTS as a credential type, and there's also involvement or requirements around key stored and hardware security modules, in order to be compliant with the goals there. Those are three main topics there's probably a couple other ones there's one another one is, is the EU trust list that existed in the, in the, in the version one of this. And, and, and there, it's basically an X509 based system that has, of course, a way of resolving those public keys, and also authorized roles within the ecosystem kind of play in there so it's a little bit of a lightweight governance kind of a thing. And so there's there's stuff like that as well. It also includes, it also includes MDoc and the local transfer of MDoc as well I believe. Yeah, their proximity protocol is what they call their Bluetooth presentation. Yes, sorry, sorry, I had not brought up MDoc at all thank you Warren. Hey, you gave me your note in chat there's the DHS is also working on some stuff as well and so I think that that could also be a useful thing to sort of bring up and discuss. As far as a community effort to see those that are interested in, in sort of coordinating or, or broad community understanding of those of those efforts. It's clear that there's some interest in here. I will try and coordinate the right stuff here and it's actually been on our future business list at some point for, or future topics for to talk about. In the airf and so I will try and coordinate some some efforts there. If you would like to more specifically be involved to organize presentations please holler and reach out. That will make it a little easier for me than than trying to hunt folks down individually. And it's clear that that's a useful thing. Still as a high priority we're not going to lose the transition away from the unqualified dids as that's a pretty darn important thing for our community moving forward for all these other things are talking about. But we can we can definitely organize this on others discussion that we should have as a community is how does the UDI and our common goals affect the possibility of a IP three, or a IP next. And how we should coordinate that both with what the scope should be and what the timing should be. And in the utility of doing such and how we can make sure that we're not just massively replicating effort and goals there. But we're over time. I appreciate everyone coming. This has been a fantastic meeting and we look forward to seeing you elsewhere on the internet where we all meet at a regular time and we'll see you again next week.