 Thank you. Thank you. Welcome to the 9th of August, 2023, ARIES Working Group call. We are glad you're here. We have some good topics today, including our expansion of the topic that came up last week, ARIES Community Effort to support the EIS 2.0 UDI ARF. We'll explain those acronyms in a minute if those are unfamiliar, and also some updates on some other stuff and some, I think, a little bit of lack of progress given the fact that it's August and a lot of vacations happen during August. But we're going to have a great meeting today and make some forward progress on stuff. We have, this is an anti or a hyperledger call, and so both the antitrust policy notice or the antitrust policy and hyperledger code of conduct are in effect. Please be mindful of those. Please reach out if you have any concerns about activities in our call and how they might need to be corrected. The agenda link is again in the notes. You're welcome to make any changes there that are useful to the community. And please, and we do appreciate your contributions. Are there, is there anyone new today that would like to introduce themselves? I'm definitely glad that that you're all here. Announcements also related to August being a big vacation month by full meetings or pause for August and AFJ is bi-weekly with meetings during the summer. Also during August. Any other announcements or or corrections to those that we should have for the group today. All right, we are sticky up into the fall. Well, it will get IW on the list here. The workshop is worth attending if you are in this space and interested. And we'll we'll get that on the list in coming weeks. Do any of our projects want to share release status or work updates. That's been happening during this last time period. All right. On our agenda today, we have some topics that carry over from last week, mostly because there hasn't been enough progress made. But we have, we're going to have a quick marketing update. I do kind of the important issues, which are the, the coordination off of of unqualified dids and the related issues there. We have some with some non progress that has happened that we need to still push forward and make happen so that we are ready to do that. And then the, the, we've got any vdr askers that carry over Stephen from last week or did you add that for this week. I saw your comments in the in the chat. Sorry, which one. The individer ask our transition. Was this carry over from last week I wasn't sure as I saw the comments that you had made to I don't have. I don't have anything in particular to say I was going to maybe mention the individer did indeed did get merged into the main branch so that's now in the main branch. Announcement but not an official release based on that but that should happen in the next day or two. Save the thunder for that to the next weekend. I, I, I didn't in my haste this morning. I wasn't sure if I didn't check whether this is a carry over or related to the comments that you made in the discord channel. So that's okay. And then the last topic is going to be probably our main one today, which is the the architecture reference framework coming out of the European Union digital identity effort and and what and what we can do there to coordinate as a group. Any changes that we want to make to the agenda before we get going. All right. Marketing update. Helen or Alex, I see Alex. Good morning. Good afternoon. Good evening. Helen's away this week. I think primarily so I'll give you a very brief update here. Good progress. The first changes are live you go to that link there which is instantly the first search results that you would normally get if you search for hyper ledger areas for most people. New short description there. We've got a type library got some new panels up there about contributors commits and lines of code. We're going to have a longer description going in here and also talking to hyper ledger if they can get some funding together it's a little bit of money so we can make a small animated video to have this section as well so lots of changes coming for this section that we're working on right now. There's also a draft page in the wiki which is linked to the second bullet day fun to see where things are going. That's shaping up we're going to make that a bit more accessible down the bottom but that's a lot of the new talking points in it as well. And that's progressing well I'll let you know when those changes are going through and finally, as the bullet says on the agenda there. My pleasure doing a lot of work on identity and the density comms this quarter so if you've got things you want to highlight their all ears to reach out to the people mentioned also myself, if you want to have something reaching the wider community. So yeah, things actually happening and becoming live which is very exciting and I'm sure there'll be more to update next week, at least I hope to be more to update next week. Fantastic we also need to acknowledge the hyper ledger new logo that I've done I think it's a it's quite a cool improvement. And so it's not it's similar to their old one but I think I think graphically much improved so it's a very cool there. I did notice though they've got to, they've got to watch the transparency on their on their favacan, if you will, shows up in the browser tab but but pretty fantastic cool progress there. Thank you Alex for that update. But then Sam just to note that the favacan is being updated. Thank you. We're catching bugs and errors on the site and we're fixing as they go so if you look at related projects we're going to that that's going to be edited and we're working on rolling out changes over time. So, yeah. Well, well done, Sean and team. And thanks for all he do there though. It looks pretty great. I'm a fan of the new one. I think it's it's it acknowledges the old one but looks so much better. It's very cool. Awesome. The did peer three front there and the unqualified coordinated unqualified dids coordinated update. Not a lot has happened this last week. We, I suspect, mostly as a as a result of folks being off on vacation. And we might be in this state for a couple of more weeks where it's a little hard to, to make the necessary progress, but we'll keep tracking it. And we will. And we will make sure that that we move it along at the speed that we're capable of doing so in that that we're ready to move quickly on that as folks return from from vacation and the community is more or less back together. Any any updates that anyone wants to share or corrections for anything that I happen to get wrong on on that. We're making good progress in in acopai on on peer did peer three, lots of, you know, learning and figuring out from people that haven't looked at this, or things we haven't looked at in a long time. I think we're in pretty good shape or we're going to be soon so that's good. One of the good things about this is I'm now fairly sure that once the dids are used during establishing a connection but are not used thereafter. And so it actually becomes a lot easier. Once the connections establishes just during connection establishment that that it's a little tricky so I think we should be in good shape from that perspective so that's a good thing. I will cross out this one part of the, but the verification key and key agreement key and all that stuff. We don't even need that. Yeah, that can be just crossed out. Yeah, or deleted that would work. But the, you know, the good thing is, there isn't really a need to transform unqualified dids existing unqualified dids because the dids themselves are not actually used after creation. So, that makes it a lot easier. What do you can you explain a little bit more mean by that. I mean, when you send it did calm one message. You create a, I believe it's a JWK that holds the key that's encrypting it, maybe it, but it, what, what gets stored there is the key. It's a reference to a key. And so if it was a reference to a key then then that would include the did, but in fact it is a key a base 5825519 key. Right. And as a result, you're not actually exchanging dids back and forth as you send messages. We aren't yet. We will in the transition to did come to you. Yes. Right. And so it just makes this a little easier. We still are working out. Okay, here's how we're going to transform it. And here's how we'll reference it. But the good thing is, you know, it's makes the transition to unqualified in did calm one a lot easier. It doesn't in your right I had I was so focused on did come be to that I was I was not mentioning the key base nature of did come be one is that applied here. So, which, and I get why now you're, you're worried about that. So, okay, that's good. Yeah, yeah. So, so the transition. Go ahead. Sorry. I was just going to say that that that we the importance there of making sure that we have them both solved during this update is important. So that we're we're it's fixed by the time we get to did come be to that and that's that's the real important piece is that is that it's it's ready for moving off of that entirely. Yeah. All right, go ahead. You say something about AFJ. I would note AFJ did emerge this week of a or at least a lot of work. I think the PR was merged but I did come be to. Not yet, not yet. Not yet. Okay, but we are very, very, very close. Yeah, very close. But yeah, we, we haven't yet emerged that into main branch. We have another branch which is called the computer but but yeah yeah we are pretty close to to have it. I think that some has a good point here about the fact that maybe in a future, we will upgrade existing did come be one connections to be true. Right. So, yeah, for for that it will be useful to have this, this migration internally and have it. Okay. Good. I have a question for you, Steven in a cup by for for the exchange. Are you going to use the peer to. Yes. Okay, nice. So did peer to and then. And then. And this is where it got kind of weird as I would say that, you know, did peer to but in future you would use, you know, for future interactions you would use the did peer three. Um, reference, you know, string, but that's where I realized in did calm one you never actually pass the did string again. You only pass the key. But Sam's right that in did comfy to you do pass the dead and if so then you want to use that the, the did peer three. Yeah. So there's, there's 2 concerns here. 1 obviously is the continued operation of existing connections, which is why we're doing this. The other 1 is that we want to eliminate the need for anyone approaching our community to understand the, the, the, the old way of doing things that we hit, we hit, we need to make go away. And that way, all, all they need to understand is that dids are involved there. So those, those are the 2, those are the 2 kind of concerns and we may in the nitty gritty need to figure out what the right sort of compromise is towards those goals. But that's, that's the goal and the point there. And partially so that we can of course be ready for did comfy to as I've said, also because we want to. We just want to make it easier for people approaching the community to not have to learn like some special thing that we did historically. Yeah. Excellent. Thank you Steven for the clarifications there. Did we do we need research to do this that anyone happened to look into the right label for the creation of the did doc. We have to dig into the to the RFCs and see what it actually says that with what it says in the did comfy to spec. I didn't get a chance to do that one. Okay, I didn't either. So, but I think that deep communication is for the comfy one, right. Oh, that's right. That was the question. Can you add that to the notes. The question was, are you do we differentiate between the economy one and the two by the type or by the except parameters. By the type, the service type changes the except parameters are useful inside of did come be one and and knowing whether you're using the old envelope or the new envelope format that was a that was a transition step as part of a IP to in order to prepare for the eventual move to did comfy to, but it's the but that's the difference. So, so we do different and we do differentiate with with the type. And so we still have to nail down exactly which is to be used. Yes. We just need to go find the, the, the right link that that says that in the docs and then we'll need to do a quick check against existing code bases to make sure that we're that lines up with what's actually been done to make that to make that happen. Yep. Cool. Okay, anything more on this topic. So Steven, I really appreciate your info here. All right. So the, the next thing to discuss today is the, there's a lot of titles that apply here. And let me explain what these are, what these actually mean. So, the IITIS 2.0 is the second version, obviously of the IITIS. That's the European digital identity standard. And there's a 1.0 that that is in kind of an effect. It kind of didn't quite have the goals that I'm heavily summarizing and so may not be perfectly accurate as I say this. quite have the goals that it aspired to and so they are underway with EITUS 2.0 which is an update of those given the newer available technologies and based on lessons learned with things that didn't work with EITUS 1.0. And so this is a definitely a European standard but has lots of effects all over. There are countries not in the European Union watching the standard and being mindful of it both because they want to work with the European Union on various things and also you know want to of course learn any lessons or wisdom that they cannot they can offer there. EUDI is the European Union Digital Identity Standard that I believe I probably have this backwards responsible for EITUS 2.0. In the ARF here is the architecture reference framework that has been proposed as the way to satisfy the requirements in EITUS 2.0. And so that's a lot of acronyms together. I will fully claim that I am not the world's most expert on all of these things but have been waiting around enough to reach some level of familiarity with them and everything else. So late here is a post that ANIMO made. This is a little bit ago at the moment. I can kill some of these old tabs up here where they described their desire to make the areas framework JavaScript align with the architecture reference framework. Here's a link for that. This is a little bit thick. There are useful things here if this is the right thing that I think it is. There's some new terminology here that we won't go over deeply today but they differentiate between a verifiable credential that identifies a person and verifiable credentials that do other things. They have different requirements as it relates there. And in lots of these acronyms come down through that. There's the other really useful diagram is not that one. This has been updated since I've seen it last. So I might be looking for a diagram that doesn't exist. This is the one. This helps understand the protocols and the credential types in play. And it has identified as required OpenID for VCI and OpenID for VP. And then as well as the proximity flow, this ISO number basically refers to the MDOC proximity flow specification. You'll notice that there's some alignment between that. It doesn't say MDOC exactly in here but the MDL MDOC standard defines a proximity flow which is Bluetooth based but specific to it exactly. It doesn't build on any other protocols in the process of doing that. It also identifies both this MDOC standard as well as SDJOTS. As the method that they're identifying for the credential type being used there. And they also have type 1s and type 2s are kind of a big thing. Type 2 configuration has to do with not, and I may be wrong here so please someone please correct me if I am, has to do with with sort of the secondary non, you know, personal identifying information credentials that might be related within the system. And so for those that also allow JSON-LD, VC and LD-Proofs, but SDJOTS are required in type 1 and so that seems like the common target that people are approaching. You'll notice it says other optional protocols here which they left open but realistically because these top ones are required those are going to be the ones that folks are focused on. And so this guides a lot of this discussion so if you look at the list that Animo has talked about here they're talking about this is the same ISO standard the 18.013-5 and so this is the mobile driver's license flows which are very different both from a credential format and from a protocol perspective than anything done elsewhere. They also have the open ID for VC related protocols there's two of those there's the VCI for verifiable credential issuance and VP for verifiable presentations that comprise the commonly referred to as this but not really officially and those are the protocols there that can actually pass those. These are pretty nicely designed to carry similar to the Didcom credential protocols to carry any credential formats along as sort of the definition is defined there and so this will actually pass MDoc credentials. You'll notice in this diagram that the MDoc spec does not define a protocol for the issuance of that they kind of hand wave that and say it has to happen but they don't specify how only the presentation of it and so one of the things that has emerged is a popular choice there is the open ID for VC protocols. Of course we could document and describe how the same thing could be done with our protocols that have been designed inside of Didcom for issuance and presentation of multiple credential types but we haven't done that work and so in absence of documentation the only defined path there is the open ID for VC stuff for issuance and of course for presentation in addition to the proximity flow. You'll also note that the MDoc spec does not define how to do an online presentation of it only the proximity flow over Bluetooth and so there's a little bit of an odd gap in the spec there where they were mostly designing that for in-person presentations not necessarily use across the internet and so that's another thing going on there. So the open ID for VC related protocols it also specifies the use of a hardware security module for the keys and when I say the keys I'm air quoting a little bit because they're not very specific about exactly which keys they mean in the sense that is this just keys you use for the credentials or does it like is every key required to be stored in the HSM that's a little bit of an interesting question. Also note that the hardware security modules do not typically contain the broad range of key supports or key types that we are comfortable with in the cryptography that we leverage and so there's some open questions on exactly how that that happens but their ANIMO would like that to be added to ASCAR so that they can use ASCAR as an underpinning for that and then the last thing that came up in the diagram that I brought up was SDJOTS as a format so JOTS is a JWT token and that was kind of invented prior to verifiable credentials but they have an adaptation of them or a specific use of that spec that qualifies as a verifiable credential. The SD is for selective disclosure and they have worked out recently a way to modify the signatures applied to a JOT such that you can selectively disclose the credentials that are actually in there and so that's the fourth item of support that they're talking about and so they also call to kind of like gather the community together to do this and to work it out which is great. It was voiced last week that focusing on this more broadly as the areas community and not just within AFJ would also be valuable and so I wanted to one of the things to do that I was hoping today at the beginning of this is to raise awareness of any efforts that are going on in in different code bases so that we could understand what was already happening and then perhaps identify work that was not yet happening that needs to be coordinated within the community. There's a whole lot of talking and please if I've made an error on something here please offer a correction there so that we can avoid confusion and also for those that are aware of efforts in code bases already if you would mind volunteering that information out so that we can be aware of the work that's already happening in various ways. Sam one thing I've noted is if you're following along with what's happening in AFGO they've got a full effort right now to add SD JOTS to AFGO so seeing a lot of BRs and things towards that goal. The other thing I was thinking was as I understand it MDocs and SD JOTS are very similar. I believe they both use the same technique for selective disclosure so one would expect that you get some crossover there that might be. Did you say MDocs and SD JOTS? Yeah. I was aware of that and the disclosure is part of MDoc so that's cool. Yes and I think it's the same technique the same cryptographic technique underneath. Cool. What other efforts are underway for adding various elements that we've discussed here to two areas projects? We talked a little bit about this yesterday during the ACAPUC call but we are currently exploring what it would look like to enable support within ACAPI for open ID for VCI endpoints in the protocol. We discussed a number of options that could be something that is implemented directly within ACAPUC. That's probably my least favorite of the options the other two being as a companion service to ACAPUC very similar to the VC AUTHAN OIDC project that's been around for quite a while and then third option would be as a plugin which just behaves more or less like the companion service just with tighter integration in ACAPUC so it has more direct access to the crypto and other elements that it would need access to so it's something we're considering and weighing our options on at this point. So that was just for the open ID for VC INV VP protocols. Is that correct? Yes. We have also looked at the SDJOTS stuff. The crypto for the SDJOTS stuff actually isn't too too crazy. It's pretty straightforward at least by our estimation so far and there's already pretty solid libraries out there for it as well. So we recently added JWT sign and verify endpoints to ACAPUC and we're also looking at adding SDJOT variants of the same sign and verify endpoints and then those could be pretty trivial the integrated with an open ID for VCI implementation I think. So this feels like a lighter lift than the protocol support? I would say so yeah. There's going to be if we wanted to use SDJOTS and JWT VC within issue credential and present proof within ACAPUC that would be a significant chunk more work but if we're focusing on shortest path to open ID for VCI and European standards compliance, I think we can wait to do that format definition and all that stuff for DITCOM protocols and focus on just integrating with the open ID for VCI stuff. Cool. Other work that's going on? I would add that in that presentation you gave they talked about the category two I think you said are type two being JSON-LD format W3C data integrity. That would be the path to getting an on creds support in so doing the work to make an on creds W3C JSON-LD compatible and securing it with securing a JSON-LD credential with an on creds and perhaps a second NIST supported key. So that's a second that would be the path in for being able to use an on creds in that type of architecture. Yes the other thing that I'll mention too is that obviously the other protocols would allow for DITCOM to exist and not invalidate the solution but it's clearly not as a selected option. The thing that we the best option we have going forward to help them correct their limited choice limiting choice with the open ID for VCI protocols is to allow for or design feature parity for DITCOM credential related protocols. So Daniel mentioned for example adding the format definitions is separate work but also shows that you have another protocol that meets all the necessary needs for what they're doing. That would be not just the format definition for SDJOTS but also the format definition of course for the for the on creds as an LD cred which we've talked about that in previous meetings but also of course the format definition for an MDoc as a credential type that would allow for the MDL stuff to transfer over that. That's particularly interesting with a DITCOM Bluetooth transport because it shows an alternative way of presenting these besides the proximity flow that is usable in this particular context and so that's a powerful thing to do not that it's necessary for the basic requirements but for the future evaluation and perhaps revisions of the EUDI ARF in the future that having protocols ready to go changes the nature of those discussions if we already have protocol compatibility there. So maybe a bit of a pedantic point to make here but the non-creds in LD creds with LD creds would it perhaps be a little bit better to describe that as a non-creds in W3C VC data model format as opposed to LD since we're not using link data proof signatures? Yes that's probably true. It's actually the way it was worded I was trying to match the wording that's in the on the screen that Sam showed earlier I believe they said with data integrity oh LD proofs okay Jason LD with LD proofs is what's there but yes W3C format W3C data model format yeah. The specific narrow eye of the needle threading here is that with the non-creds in the W3C data model format we can dual issue a credential that is both LD proof enabled and a non-creds enabled in the same credential and that would slide narrowly in this window right here is that is that your point Stephen yeah. Yeah that's exactly right. And then other these other optional protocols can be useful here so long as we define the the data types necessary to pass the credentials that they're talking about right the MDL the SDJOTS and of course the LD proofs that may also have a non-creds sort of along for the ride in the same format. The W3C data model allows for multiple proof types to be present in the same data structure itself which allows for the coexistence of LD proofs but also a non-creds for the credential that's being passed so thanks Daniel for that clarification. Other comments or ongoing work here? So we've recently added the hyperlature non-creds project and the non-creds RS. Do we see the W3C format formatting of a non-creds credentials going into the non-creds RS project or I know there's existing work from Andrew Whitehead that's currently written in Python but obviously our user base for areas is a little bit wider than just Python? Yeah that's definitely the approach would be to put it into the in our creds rust. It's only like the actual non-testing code is about 300 lines of Python code and all it is is moving data around in data structures so it's trivial work. It's really just figuring out the best way to get it implemented and enable it to be used and it's the same type of thing we always see which is if you receive it it's fine. If you receive either format you can deal with it and then it's a question of when can you start sending it out in the new format so that everyone expects it so the same sort of community coordinated update? Or we may not have to do that as long as we can specify the different sort of credential types and all of the other protocols that are going along which means that you could send it in the old way you could also discover that the new way is being used. The updates are necessary when there's not a higher level way of doing that. We'll have to do the research into this but I think we may be able to use the existing mechanisms we have in order to discover that support which makes it a little bit easier for deployment. It means that projects can deploy it without really fouling things up and in the need to broadly coordinate. We may want to push it as a community effort to to gain support in the in the various things and then demonstrate that. But as far as actually executing a community coordinated update it may be a little bit easier than that so we'll we'll see what happens there. Very cool. So we have this is so an AFGO, AFJA and ACAPI the the main code bases here. We have an open ID for VC support being looked at. We've also looked at to understand the JWT support there and then we've noted that the protocol you know the definitions for these credential types is extra work. Mentioned in animos list but not yet really anywhere here yet is the is the ASCAR work which is decidedly a community effort there. So this is support for the hardware security modules and so that hasn't really been discussed anywhere. Steven you're a little more approximate to Andrew than the rest of us. Has this come up in conversation at all or is he aware of this? Not that he has to do the work I'm just I'm just curious. Yeah I mean it's been talked about in the past and and theorized that this would work and and is possible and he's that's about all I know is that structurally it's possible to do but no work has gone gone into it as far as I know. And ASCAR to clarify is in Rust, right? Yes. Yes. I was 99% sure that was true but I want to make sure. So that is that is Rust based. So all of you teams that have idle Rust developers sitting around this would be I'm making a joke here. This would be a great a great application of Rust skills to to be able to look inside and and see what would be required for for HSM support and satisfying this particular requirement. There is a little bit more research that needs to be done by those who understand the details here on what exactly needs to be stored in an HSM but having generic HSM support is the largest chunk of that and then figuring out the details of implementation will be useful there too. So yeah good we have more underway than nothing for sure and so you know understanding this I think is is pretty unimportant. Any other comments or thoughts or ideas that folks have on the EIS 2 UDI RF topic? All right I'm hoping that that we can draw in some experts to help us figure out the details in the in the question marks that we have around this and then for those with ongoing work in these various efforts it would be really cool to hear back about about you know progress that's happening or things that that we've learned along the way that may be more broadly useful to the community in that manner so that's that's excellent as well and with that we're at the end of our agenda today are there we have 12 minutes left are there additional topics that the folks would like to discuss if not we can end the meeting early today. Kim your hand is up. I think it might be worthwhile to have a discussion about the the movement of RFCs over to the Diff and kind of a roadmap of removing the RFCs that are protocols that exist in the Diff from the Aries RFCs. So here's some that's a good topic here's some historical context a lot of things were done in Aries because there wasn't originally because there wasn't another place to do them for example did commas developed in Aries and later spun out in that the did conv2 work happened in a separate group of the Diff. The didcom.org exists and there's a didcom user group that actually meets on Mondays that is open no Diff membership is required for that and and everyone is invited to attend there's also an open discord channel for that topic as well that that exists for that particular group and so there are a lot of of the produce some of the discussions we're having today for example the migration off of the unqualified dids is distinctly an Aries discussion topic but there's lots of stuff that actually applies more generically to didcom generally speaking and some of those conversations are better held elsewhere so there are two types of a couple types of RFCs we have the concept in the feature RFCs and lots of the feature RFCs actually describe didcom protocols lots of those are at least linked to but are more broadly applicable than just the Aries community and so those protocol definitions have a really good you know forward home over in the didcom users group and on didcom.org as a place for those to live some of theirs and we ran into this last week as we were discussing things there isn't yet a place inside of the didcom users group for non protocol based RFCs and we ran into this with the definition of a of a feature type to be used inside of the discover features protocol for support of did methods and and as a result there is a little bit of work that needs to be done there to figure out how to accommodate. We have far fewer Aries RFCs being created these days as a result of that and so there's a little bit of a discussion that hasn't really happened yet and that Kim I think is is is highlighting about where these things ought to live and should we do anything about the historical RFCs that already exist within Aries but but maybe be better homed over in the didcom users group. I have that's kind of the scenario I think I am yet to come to a personal conclusion on what I think might be the best option there we certainly have a few of a few options in front of us but but it's not quite clear on exactly what should happen in my mind or on what the timing should be any any thoughts or comments on the topic from from anyone. Well I'll take a first stab at it here I think leaving the RFCs and Aries RFC I think causes some confusion on what the source of truth is and so I think at least marking and linking to what the source of truth is would be valuable even if we leave them in existence so that there's clarity on what organization has the source of truth. And I think regardless the AIP concept needs to continue so whether it's in Aries or Diff or whatever it it needs to be used. I think I think that in RFCs haven't yet been discussed for for something that moves they can of course happen everywhere but Aries is a really useful community to do that in and so no there's not really an argument at this point that AIP should should not exist. The proposal is not that all RFCs move but that they're I believe but but that the the RFCs that contain stuff that ought to be everywhere else be updated to link to whatever the sort of the canonical version of it is rather than but anything we still need for example community coordinate updates are within the Aries community are still going to need RFCs etc so this isn't that all RFCs die it's just that we no longer we resolve the confusion about number one where new ones should be created for various topics and number two what to do about the historical ones when we don't want to have you know multiple sources of truth on a topic. Does that make sense Steven? Yeah yeah I think we also have to come up with a far better way than get have repository markdown files to publish them to make it far easier to navigate them I mean way too many got created the only ones that matter are the AIP ones so we definitely could do a way better job at coming up with a way to make it clear which ones matter and which ones are are are less important let's say. Right I've been playing with MK docs and that might be a reasonable mechanism to do so they pair well with GitHub Actions and for publishing on GitHub Pages and so I think that there's some there's some options there moving forward. Yeah I did the acopie acopie.org site with make docs and just a conversion script and it was pretty dead simple the hardest thing being sort of on the fly cleanup of links to make them resolve within your new structure but that's about the only tricky thing and I came up with a good scripting way to to deal with that whenever I ran across one. Right so there's a couple steps I think that needed to resolve this and one is that we need to make sure protocols this is pretty clear we have an existing process over in the income users group for for the for managing and updating of protocols what's less clear is what to do with the non protocol related RFCs there's are there are a few and that something that needs to be resolved I'm going to ask that that be put on the agenda over there for this next Monday so that we can talk about what to do there and and make that happen and then when that's resolved it's a little bit easier to then go through and we could we could go through and identify the the the options that are better homed over at the the did come users group we can we can create new versions there and then update the copies that we have here to sort of point to the right location that's the canonical version of that and so there's certainly some options there right now there's some protocol definitions that are listed on the com.org that actually point to areas RFCs and that and that probably ought to ought to be updated where the the actual documentation ends up there rather than pointing back to areas RFCs just to avoid confusion and so there's definitely some some work to be done trying to make that happen there so Kim that's not a super satisfying resolution of the discussion but but there's definitely stuff that needs to to come up at the did come users group to sort of enable the larger discussion or the larger effort effort to occur any further comments there or or things that we didn't address well any comments on anything um so Sam would it be valuable to link to the diff in this meeting um like in the project section up above so everyone knows how to and where to get to the diff yes you're welcome to add a link um I'm I have to run really fast to something else and so I'm not going to be able to do it right now but I can't come back later now to the notes or anyone else that has the the relevant links to the did come users group that would be appreciated um and and we can better sort of circulate it's been a while since we've highlighted related meetings as a regular thing but that might be necessary sort of to just regularly increase awareness about what's what will be talked about there and and things to happen um and so as another example there is a um there is a in the did come be to spec in problem report there's a there's a requirement um that the parent thread ID be present that may not always be satisfiable and so there there'll be some discussion about whether um you know what to do on that um in did come be to land and when you when you're returning problem reports uh for a message which you cannot actually process and don't know the thread of um and so that's that's an example of of of topics that will happen there um and we'll definitely need to I'll go ahead and get links in the future meeting so that we can link them in here and we can be aware of those um that's a good idea Kim awesome Kate we're about out of time thank you folks for coming I appreciate the discussion today um and uh we'll we'll uh we'll keep on with uh with the necessary topics and trying to raise awareness and and the progress that we do make as a community grateful for all of your efforts and the things that uh and the work that everyone does uh to benefit of the community grateful for all you do and we will see you elsewhere of course and next week at this meeting thanks folks