 Morning folks. This is the 5th of July Aries working group call We have some good stuff coming up and some progress to make this is a hyperledger call and so the Antitrust policy and the code of conduct are in effect. It's here in the agenda Gender link in the meeting Chat You're welcome to add yourself to the attendees list or make any other changes that would be useful to the group Is there anyone new here today that would like to introduce themselves? Glad to see so many returning regulars We have still in the announcements list But I have also down later in the agenda the the marketing working group Maybe I'll just leave that down for report further down below. Are there any announcements that should be on our list? But or not. All right. Any projects want to share some release status or work updates? Yeah, I quite zero a to was released So released last Friday. I believe it was Thursday or Friday and Out and available. We're also about to merge The dropping of Python three six so that will be the next release It's just complete It's literally running now and will be merged as soon as the test complete and will have dropped three six from acrobat Awesome any progress on the github actions weirdness that you reported last week Yeah, that can be removed That was that was solved It was a resource issue and some and and some rules around Python that Basically was Essentially the amount of parallelism allowed autumn it defaulted to and we needed more parallelism in the github actions in order to run them So what did you add more parallelism or reduce the need for it? What was the answer there? add more Changes the fault we were letting it default to the number of threads I think it was I'm not sure friends is the right term in this case But anyway the number of threads from and it needed more than the default So it figures out the number of cores you had as you know Devils it and adds to or something like that and it needed more than that The particular run we were trying to do Cool Yeah, that that is good to understand um cool Excellent Other projects that want to share updates Awesome. Thanks for all the good work out there today, um, I Check in with the areas marketing group and And and and what's going on there? Um, I the main topic that I'd love to discuss today Is is how we this is just the notes I pulled from last week, but I've given the work that's been done um I feel a sense of urgency around this um, and I uh, I want to talk about the potential for A community coordinate a coordinated update in what those date targets might actually be to get this done um And so I'm grateful for the work that's brought us to the point where we're going to have this conversation I'd love to have that and then and then we will definitely have time for some open discussion today I was trying to not overpack the schedule. We've had a lot going on and a lot of great progress Thank you, Steven last week for um for handling the meeting while I was out Um, but uh, I wanted to just make sure that we had time to sort of bring up any topics that we needed to discuss as a group Um, so we could make sure those got those got discussed Any changes or additions or? Modifications the agenda before we get going All right, uh, helen or alex any oh klesio um I think it's worth mentioning that from from bifold side We're introducing a little bit of what i'm been calling ephemeral or temporary connection to address um, cure code density And that is uh encompass around go codes and if we have time we can talk a little bit about that Yes, that's an excellent discussion um Okay Excellent helen or alex any updates that you want to share Yeah, 30 seconds. There'll be a survey this week. We'll send it out. Please respond. We're gonna Try and promote it with a blog post for hyper ledger So look out for that. We'll also put the link in next week's. Um, we'll put in this in this meeting Notes as well when it's there retrospectively we'll put in for next week as well Perfect. So this I couldn't tell if if you had already updated this service from last week I didn't know if there was going to be a survey last week and now there's one. Anyway, either way No, we got we got attacked by stat days, but yeah, it's not this week perfect Yes, oh by the way, happy canada day and fourth of july or insurrection day if you're from england So, uh, we've had a bunch of holidays the first part of this so Um, I'll I'll also just say that we are the Marketing meeting will be the last tuesday of every month And it is in the groups. I oh like people should be getting it You should see it pop up, but um, please forward that to anybody in your organization and your You know your team that might be interested in contributing to the the work we're doing there We should have some great new Descriptions and you know boiler plates and taglines and all kinds of we're working all kinds of fun stuff. So if you have I an opinion about those things. We would love to have you Excellent and thank you for the work that you're doing there Okay, we will look an eye out. We'll keep an eye out for a survey so that we can better understand stuff and uh and looking forward to that um Okay, so we've got um Stephen you covered this last week. Um, and I haven't had a chance to dive in to see what other progress we've actually had But uh, but we we are very near The did pier three, which is of course the the smaller version Of a did pier two when it that's already been established And then we have this uh, this legacy did A transformation doc that was written up by timo To talk about how to make this actually happen And so That's that's kind of the the issue here, um, we there's some open questions here Do we want to have support the did con v1 entries? And and some of these other other things how to transform this I Figuring out some of these things would be fantastic so that we can move forward and actually pick target dates that we plan to implement these by Um, so here's the he's uh, if people haven't seen this, this would be super important to take a review of Um, and I noticed that it was linked in the meeting last week um, and uh, and this is the the transformation into a did pier two Um, that can then that can then make this happen. Um, and so, uh, here's the steps to go through and kind of make this happen It's a transformation. So this should be a deterministic thing You you stick in the information to get the same thing at every time. Um, that allows it to be done by both parties So that so that any sort of legacy dids in use can be updated And in referred to by the by the new values there And so this is a good candidate because of the of the interaction on multiple sides for a community coordinated update Uh, and this is a process we've done several times before when there does Have we do have something that is important enough to to coordinate the deployment of and so in this case There are phases to that and the first one is to accept the new But default to the old and then we and then we default to the new while still accepting the old And then the last phase of course is to is to fully deprecate the old and we just all use the new going forward. Um, and so This is uh, this is something that is necessary to happen for a wide variety of reasons Not, uh, not including but not limited to Moving to did come be to where there's those legacy dids will will not have a way to function anymore And so giving them a a path forward to a format that will make it work. Um, it's pretty important for moving that forward Any comments or questions specifically about the the current state of of this migration Did the fear three um changes get made? All right, it's a darn good question Yeah, so check the pull requests Yeah, that's a super old one Yeah So Daniel blooms we need to get a for sure we need to get an issue in for Daniel's comments A pr in you mean For the R and we do so, um, that's uh, definitely something we need to have happen I'll go ahead and drive that forward Yeah, I I could I I just don't know well enough how to describe I never understand the multi baseball to codec And how to describe it so I didn't get it in Um, the changes are pretty pretty small and then we do have to look at The other one to see why that example doesn't work Okay um, we can um I don't see alex here today Um, but uh, but we can also submit other prs in order to make this happen. So Yeah, anyone can call alex's has already been merged Yeah, yeah for sure, which means it's easy to send it to submit a pr. I'll go ahead and drive that one. Um To to make that occur to make sure that occurs this week um, so There is uh, this code as well. Um, or the this document as that has been described um We there's a couple things that need to happen. One of the things that we should probably do is is uh, is throw it into a An aries rfc this Independent of debate about where things ought to go. This is distinctly an aries problem In the sense that this this is a sort of an aries historical thing. And so I think it very, uh Perfectly lands as an aries rfc Which means that uh, the Upon verification of this we we would need to to get that in there so that we can link to it And then of course the the creation of a community coordinated, uh, uh update rfc That the references the process but also sets some target dates um And so there is code, uh within um A fj that does this so there's actually some reference. Um, and then we've got test vectors as well To to make that happen And uh to to make that work. So um, there's also the code here Um to actually perform the the translation, you know, right within the documentation here, which is pretty fantastic Um, and so if you haven't looked at this, this is critical to look at if you're if your code uses legacy dids in any form Then then we want to make sure that we understand this process and it's going to be a smooth transition So One of the other open questions that I have and steven you raised this last week was Well, you you mentioned it. You may not have asked the question Timo's document describes the transition to to did or to did pier two did pier three is a Uh more compact form of of a did pier two did when it's known to both parties And so the question is do we include in the community coordinated coordinated update a transition all the way To did pier three for those existing connections since they will be or do we leave it to just did pier two? Um, and and not include the move to did pier three I think we should go to did pier three for sure I mean The reason we have We already have exchanged a did doc. We've already transmitted the did doc Um, so it seemed odd to transmit it over and over The did pier the use of did pier two should only be to enable The calculation of did pier three to me Right For sure. I I don't argue with the advantages of did pier three at all. The only question I had was about The the burden of doing so the benefit of involving in a community coordinated update as we all get to did pier three faster The downside is that it could take a little bit longer just because of the additional stuff to implement The stuff being Once you have A single transition and don't even ever and then throw the did pier two away It's it's just another step in the in the algorithm, right Oh, it totally is. It's not a computational issue. It's a code writing issue In in the sense that there's more code to write if you're going to to did pier three instead of just the transition I would think that would be one line of code To make the transition between two and three I mean, all you do is you take once you have it did pier two you just do a single What amounts to a translation and you get a did pier three you just My only point is you have to write that translation and test that make sure it's working correctly and everything else It is a little bit of additional code writing burden to make that happen I mean the good news of doing it is that we all get to did pier three which is efficient And so that might be nice to bundle together But I was curious if anyone was nervous about including that just because of the code burden I don't think anyone's arguing the the advantages present by by making that change just the effort involved Any comments or thoughts there? Okay, I don't hear any objections I'll go ahead and write the community coordinated update with a move to did pier three And included in that process and and that gets us there. It's not a hard move But there there is some there's a you know some code to write and some implications of Of storage and everything else It also means that if you're going to support did pier three we need to make sure that we you know handle the Other aspects of that so So very cool Here's the question At what point are we seeking to have this fully adopted? What what timeline do we think we can dedicate to To this move as a community? I think I I certainly feel a sense of urgency around this as it's something that that is a sort of a weird historical piece That we just need to lose And will ease any future worker collaborations or integrations or anything else because of of eliminating that weirdness So here we are in july We are halfway through the year How how fast For for those of us maintaining code bases. Do you think we can Make this change and have it deployed Just kind of rough timeline We do it in three weeks That's really really fast I'm just We're working on it now. I'm just not sure how long it's going to take Hopefully just We expect I don't know Um For those so again, we're maintaining a By phone and we rely on afj. I don't see team. Oh, is anybody on fj on the line? Well, yes, it's me, but I'm not sure how much time it will take But yeah, probably probably we can we can do it in I would say in a month Yeah, I'll say I'll say a month. It's probably reasonable because again some Some projects already have their own priority established Um, and what does it mean for the projects? Um Are we talking akapi fj? And I mean every maintain code base. Uh, so that would uh, there there may be some trickle up effects to by fold Although that relies upon afj. So Hopefully there's shared benefit there And then any other projects that want to remain compatible there Um, I think would be important. So Um Okay, I can't speak to those. I think uh as aerial says about a month for fj slash by fold Um akapi not sure steven Yeah, I will I will I will make sure of Talking about this on tomorrow tomorrow's meeting Maybe a shade so We can we can work on it as soon as possible given the pioneering effort by Timo and I think there's already existing code in afj for this I think there's a decent chance it will Be fast for the afj community, but we can certainly hear back. Um That's excellent, uh, I would uh, so what I'll go ahead and do given that is that I'll I'll go ahead and attempt We also have summertime and vacations and a handful of other things kind of creeping in here So what let's do is I'll I'll go ahead and write a community coordinated update that um That uh proposes some timing that's that that's all you know in line with with those with those goals And then uh, we of course can you know argue about the the dates and the details You know against that pr specifically so we'll go and make that happen Um, okay, cool. So, uh, we're aiming for did peer three and the the timing You know, we're talking about about a month And that's uh, and that's that's great. I I'm really hoping this doesn't take us like, you know Six or eight months to pull off. I'd rather this happened much much sooner and and we can make that all go away Which is fantastic. So, um We uh, you know making progress in these areas will be really will be really cool Anything else about the unqualified did migration that we need to talk about today awesome, we'll report back next week with some Uh with some stuff to talk about and evaluate and uh and and make some changes too In that way, we can we can move those things forward in a concrete way. So that's awesome. Um, cool Uh with that, uh, goal codes. Klessia, do you want to give us an intro to the topic? Yeah, do you need a screen share or? Uh, no, it's fine. Um, so We're gonna talk a little bit about goal code. Um, there's two use cases for us that we are going to be starting exploring Leveraging more efficiently. Maybe let's start with that one scanning flow that you have open there Um, right now when by fold we have introduced We're currently operating this in the concept that Um, when one scan the QR code, we're either waiting for a credential offer or approved request And and the app just sits there waiting for one of those things things to happen Uh, which make created some confusion in the community around messaging. How do we want to just um connect for the sake of connecting? Um, so we're probably making some changes on the scanning flow and we're going to be leveraging the Um, goal code for providing is to providing a good user user interface From from a user experience from our from our user research and our user feedback Um, our user experience that this can indicate code and and the flow to be like one transaction all the way to the point where They're authenticating to a system or something or they prove something Either they receive something or they prove They prove something The new flow is going to be around. The first question is if that connection is connectionless If it's connectionless, um, we're going to assume That is for approved request And we're going to go through wait for the approved request to arrive and which will be Again almost instantaneously And then open the proof request screen for the user to to verify and then approve and accept share that proof request If it's not connectionless, if it's a connected connect full flow Then wait for that connection to be ready to be in a state ready and fully established And then we look for the go code of that initial connection to invite If there is no the the first step is that if there is no go code It's going to go through the contact detail screen Which means that it's kind of the chat the chat message So it's just going to open the to that chat item and the user would then have an option to Start a conversation started chatting there or if if The the issue that the other party issue slash verify didn't provide any go code It's going to go to that contact detail screen And the user will see if a credential offer approved request arrives there in addition to the notification part of it If there is a go code provided then There's two options. One is a go code provide for credential offer And in that case it will again Wait for a credential offer to arrive Go through open that credential offer and then wait for the whole flow of Share accepting that credential offer And then you're going to go to the credential list and to the end And the last one is if there is a go code and that code is related to Proof request or a verifier again, those are not the real go code. It's just a pseudo code Then we're going to wait for the proof request and then open that same proof request screen So that's a that is a new scanning flow that we're proposing It was just interesting to see if there is any feedback from the community around this flow And I'll pause here for a moment So I have a question which is not immediately relevant. We'll but we'll become so Okay, um in didcon v2 There's no difference between like a connection list and a connected Okay Flow and I'm kind of curious how you anticipate modifying that as that arrives Well, I'm hoping that in a didcon v2 in the future. We're going to be leveraging go code more broadly and therefore the that That question about this connection list is going to not going to be needed So the scanning from the qr code in a didcon v2 scenario will go right to the goal code evaluation Correct. Yeah. Yeah, cool. I I like that So a couple of things one is presumably as More goal codes are provided this expands out to do other things including One that says there should be a goal code about opening, you know, just establishing a connection and nothing else So there should be I think a no or a specific goal code for that last branch because I think um I've already been asked to You know, can we add this goal code as the way to go to do nothing except establish a connection? Does that make sense? It totally does It doesn't mean anyway I think it makes sense from the protocol perspective. I mean just from what is the user experience perspective? Um, so we're connecting. We're creating that connection. Does the user needs to know about that at all? Or is a completely hidden thing and why is it hidden? It wouldn't be hidden. It would be hey, I'm it's just that once a Once goal codes are in normal use, they will be used every time and one of them will be to say hey y'all I'm doing is starting a connection So are we saying that it would go a go code for that? No Evaluation there or is are you suggesting another branch? They both actually First of all, I will be a goal code for for that no branch, but over time more goal codes will be added Yeah, and that's fine. I'm just so for this new one What is the user experience? Do we we scan a QR code? We're sitting there waiting for that connection to be ready established Once it's ready. What do we do about it? It whatever the goal code is intended to do so I think somebody said we want a Goal code for Relationship. Oh, yeah, we put in one for relationship established relationship. I think that was what we Yeah, that'll take to the contact details screen, but again, I think we can talk a little bit more. Those are the three options that that we deal with right now And I think you're right that this will evolve over time and I'm just not sure how to Document from the rfc perspective Yeah What I'm saying is I think there is one already for the for the no option. So that should be included there and and yes I'm just saying you don't have to document it, but there will be more added in the future Yeah, yeah, presumably. Yes, it will be add more. That's what we're starting with One other comment if I could just for clarification Just for clarification about did com2 sam We talked a bunch about that about how did com2 improve things, but actually the way we use connectionless in Currently is to do a proof request. We do a proof request as a connectionless The training factor in many use cases is that the connection with our code and even in did com2 The proof request is too large to fit in so you still have to establish a connection Do the presentation request using the connection and then and then delete the connection if you want it to be ephemeral So did com2 doesn't buy you Buy you what what what we thought it would get us Well, so there's a couple of things Okay, sorry, that'll be the next topic about the cure code density. I think you were talking about Yeah, sorry Let let me just finish this scanning flow. I guess if you have a question This is only for the first interaction in the first one operation. It doesn't it doesn't encompass a sequence of operation Although as steven suggested, I think one of those operations could be the execution of action menu That would kind of a drive through a sequence of operations But this is just for one operation either accepting a credential doing a credential offer a proof request or just connect Yeah, no, I think that's why I Put will slash can after I asked that question yeah I would add and I didn't realize this but Because I don't know when this got put in but it's kind of interesting There is gold code been added to threads So the thread decorator has has a place for gold codes. I doubt anyone is supporting it, but it's an interesting option Because it does allow you to Sequence things along. Oh, I'm I've finished this thread, but now I can add another goal code I don't know. I just sort of that out just so people are aware that Yeah Yeah, from us from the wallet's perspective, we need to manage the expectation or guide the user from The scanning of a QR code perspective I don't know if the having a thread there. It helps right now But as our users again the scanning of the QR code is the signal that something is about to happen We just need to guide our users through that something Yeah, I I met that directly in the answer to a key question about a tool for sequencing Yeah, yeah, that's an interesting concept And I just wanted Sorry I was just going to say this is a great start for improving the user experience. So I like it Um All right So coming to by folks shortly. Um, I guess the next question that was in relation to the cure code density And which we are also leveraging go code So for us we're having problems with the Readability and and how consistent the cure code is being read and how easily Um Based on the if there is a cure code for a mobile verify feature for instance that has a proof request That cure code is grows and it gets more and more dense Um is relative to whatever the proof request is done if you combine multiple credentials That cure code will get larger and larger Um For what we're introducing in by fold is the notion of a temporary or ephemeral connection Which means we do establish a connection We use that go code areas that vc verify dot once To indicate that this is a ephemeral connection and upon finishing the transaction Both sides automatically discard or delete the connection Um So I scan a cure code the cure code is more because it turns more Is more consistent in size. There is very little variation. So it's relatively It's not relatively small and consistent, but there is no variation When you add a proof request or maybe multiple proof request But now it adds the the easy to scan and that consistent consistency reading Of that cure code So the cure code now is it's less dense It's easier to scan This is a I don't know it's a new concept. I don't know if that's included in the account v Two or v three or one of those But it's the idea that it's establish a connection where both parties are in the agreement that upon completing a transaction that that operation It will it will not say keep that connection for a long term. It's only there to facilitate A specific operation Are you showing this workflow on your screen because right now we just see the No, I'm not It's my screen that we're showing but No, there's no I I haven't created a workflow for that one So would this fall in line? Similarly to that diagram you showed Where I would use a specific Right, there's this scanning cure code the cure code for instance It's it's gonna the the go code is going to be for verifier And then the difference is because it ends with dot once It will automatically delete the connection Okay, that's interesting So I love this this actually has some some applications. So did conv2 Has a way to hang up the connection to basically say like yeah, I'm done And that's done using the did rotation feature to rotate it to nothing This is a nice optimization in the case where you know, you're going to do it Being able to signal that sort of a thing Upfront for for particular types of flows like this is not inappropriate at all And we'll actually map really well between both, you know, we're using having that used in did conv1 but also did conv2 So I I like that a lot. I think that this is a good approach The original connectionless one was designed to reduce the number of messages back and forth But when those messages are efficient, it's not really a harmful thing to have happen And does open up for a wider variety of Of cases that can be handled before that connection is thrown away If there happens to be any negotiations or whatever else or other protocols dot vc related that may need several messages back and forth But then the the intent to have that Not be a permanent, you know relationship Express in the goal code is a useful piece there Yep, and for us, we're just going to start with the verified ones I don't know if there is any other use cases there or any any foreseeable in the future But we're just looking from the mobile verified point of perspective point of view start with It's a use case that we have On the hand right now It could grow as well Yeah, the other generic concept that I'd love to mention is that if we find as a community that there is a set of implications that are performed a lot Like, you know where you know, it's more or less a predefined thing Then coming up with Coming up with A goal code that matches exactly to that specific thing is also not a bad thing for us to do as a community That hasn't quite happened yet But I but I think could happen in the future and I just bring it up so that If someone says wow, why are we why are we going through this dance when like this is a super common thing That like all of the software packages do like that's a perfect application for a goal code that is more specific Not just to hey, I want to verify something, but I want to verify something exactly specific Um Jenelle has a question what did come be to it's possible to send a perfect question create a one-time connection with one qr code Um, you can but the size because of the out of band stuff and embedding that into the uh into the out of band invitation that can get large um And so there's usually efforts to sort of minimize the amount of data that needs to be shoved into a qr code The the other related comment there is that in did come be to There's not really the concept of connection versus connectionless anymore meaning um, you have you get a A connection if you want with the same amount of effort that it took to get a connectionless one in did come be one And then the parties can decide when they want the connection to go away And so you from really kind of having a long term versus You know no connection You you end up With a situation where that connection can be can exist as long as it's useful and then disappear. So this this dot once um Goal code is a is a cool way of sort of signaling like we intend this to vanish as soon as the exchange is over Which I think is um, I think is a cool move Yeah, or or more generic more generic maybe even having I think I've been Don't know if I talk in this forum, but maybe have a more of a generic and there is like Connection dot ephemeral or forget or something more generic as a go code But the only thing missing is if there is a we need to know what signal When a operation or a transaction is done So both parties are in agreement that It's either one operation or a sequence of operations There's nothing the protocol that indicates it's done And I think that'll play a bigger role even When we're talking about app to app integration When for instance, if I open an app for a proof request I need to signal that app that it's done and you should transition back to the originator app Right now the users get stuck in a wallet app and there is no signal to transition back um One yeah, uh kim. Sorry your hands up Um, this seems to indicate that we might want to think about the right to be forgotten here as well If we're thinking about the concept of saying hey, we're we're done with this connection um Go ahead and clean up and close the connection Um, there might be some additional signaling that we can do there to say hey forget everything about me as well Um, that's not bad the uh, so we do have that existing mechanism of sort of hanging up the connection But there's no nuance to that Um having a protocol that says, you know, I'm done and here's the the terms that I'm expressing for that Um, it would certainly be applicable and in did copy to I mean could be done with the cover you went to as well, but um, but I think that that's nicely applicable I think for some flows, I was I was imagining for a minute plus you like why what types of interactions I would want to just not have remaining um And I came up with a couple of interesting ones, but I'm curious if you have something specific in mind that you're going after uh with this type of a flow so For us, maybe a more recent event it'd be like i'm scanning your code of approved vaccination I don't necessarily want a record of everybody or collect everybody information or contact about it I just want the proof right from a compliance perspective um, and there's other compliance, um use cases where I just need to verify that you are a Good standing active lawyer, but I don't necessarily want to keep or Have a need or a requirement to keep a record of those And and creating a connection established a record that is not necessarily always um wanted um Yeah, I so I think the popped into my head was a vending machine If I have an interaction with a specific vending machine, I may not want a long-term relationship with that vending machine Right and so that would be a good example or depending on how the architecture is set up You know if I'm like authenticating to a door or I'm you know, whatever else that that could be useful It's worth noting that all of these protocol things are voluntary in the sense that if a user or if a software decided to allow and And the user perhaps enabled this they could they could basically decline the forget Side of things and then you know if they wanted to retain that information about the interaction that happened And so from a protocol perspective of course, it's all voluntary and then but but it's still useful from a ux perspective to To know that that's what happened for example You know connections that I know the other party forgot I might still want in a history of past connections that show me some Information about what I presented or something But it's likely going to be presented in a ux perspective different than an active connection So that I can go see the things that happened before that aren't active anymore But I can go actually see the things that were represented there Yeah, correct. Yeah, so There's a little bit of question about what is it audit log versus What does it mean is that it's an audit log means I'm forgetting the connection But I'm not necessarily forgetting the operation take place that I just closed something Uh was sent away from my wallet, right? Yes And and that's kind of an open question. We haven't developed yet Yeah, I think those are two different things. We can delete the connection, but not necessarily delete The the records associated with that transaction. So it becomes kind of an orphan records Which is essentially means it's a connectionless thing, you know It also like having a connection and did convie to particularly means that you just know the did of the other party And so Like this whether it's a connection or not I think is mostly a ux handling issue not necessarily the actual data that we store issue True. Yeah, yeah, it's the concept of contact, right? So and maybe without a band and the whole like We're using connection We'll make this less of a trouble or or we're like the UI being polluted with a bunch of connections So we'll try this out and and see how that works But there's this idea that connections are not necessarily At front and center sometimes they're just there to for a purpose and And the purpose is not the connection itself. The purpose is just operation the underlying operation that that connection facilitated Yes, we've not we've imagined the problem but not really handled it well where You have different types of connections to different types of things and that might be nice to organize from ux perspective For example, if I have connections with iot devices versus connections with co-workers I might want those represented differently in the ux and we just haven't gotten there As a community to number one have the problem and number two You know decide what to do about it yep So so the my my only other question is that go code. It's the string. So we're gonna have to come up with some sort of separator I don't know. I think we briefly talked some time ago. I don't know if that has been formalized You mean for the dot ones thing or um for if I want to provide multiple go codes We had the multiple goal code discussion a while back And the complicated piece about multiple goal goal codes is that it balloons the number of possibilities for what are what's actually happening um and so The issue there is that um If I have goal code a and goal code b Making very clear about which one I want to do first or whether they can happen simultaneously or whether I can I'm looking to accomplish either goal a or goal b You know in the presence of two of them, um is is really complicated And so we decided that uh at the time anyway that uh that that a single one was way more straightforward It's it strikes me that right now the only time we have goal codes is in an out of band invitation And the other thing that might be useful is to actually Come up with a different way of passing goal codes in the middle of a of a Of a relationship um in the sense that you're going to send a quick message to the other party saying hey I'd like to work together to accomplish this purpose Um and and you could use a goal code sort of with an existing Connection to be able to further something and that would allow you to sort of say okay Well, we did goal a now. Let's work on goal b Um and and that could facilitate that. I don't know if that's a good idea or not. I just came into my head I I don't know yet But I was thinking that for those complicated workflows scenario multi steps I I thought that action menu would fit better Um, but I haven't really deep explored that much But interesting. Okay. Thank you Yeah, so I don't know the answer about multiple goal codes But that that was our previous discussion and what we talked about like why why we just went with one That's all I had for by full site. Thank you Awesome. That was a great discussion Um, we have six minutes left. Are there any other topics that folks want to bring up today? Well, all right then. Thanks for coming to the meeting This week grateful for all your work and we will see you next week with more fun and adventure Thanks, folks Thanks all yeah, thanks Thanks