 All right, welcome to the March 26th Aries Cloud Agent Python Maintainers meeting. We'll start out with OOB issues in backwards compatibility. Look at the rest of the PRs, maybe a few issues, and talk about release 012.0. That's the big thing. Couple of status updates on other things past 012.0. All right, OOB. Daniel just posted a comment. Look at that, we're down to four PRs. Nice. So we don't have any backwards compatibility? Is that what you're saying? We do. The problem is that if we want any of the new features, then we lose the backwards compatibility, basically. So if you started up Accompy with no additional parameters, no additional command line arguments, you'd be able to continue to use Accompy as you were previously. But as soon as you turn on any of the new features and as soon as you try to use didExchange1.1, you get into some trouble. So yeah, because of how we're gating the features where we just have a command line argument with a flag for emit didPeer4, didPeer2, and that influences the creation of our out-of-band invitations. We're putting a didPeer in as the service instead of the inline service that we used to. As soon as we turn on any of those flags, the out-of-band invitation is no longer consumable by past versions of Accompy. So even though I went through this whole process of making the didExchange protocol be backwards compatible because of that entry point, having that characteristic of my respondent kind where it doesn't actually have much of an impact, which is fun. Is there anything we could or should do? Do you have a recommendation other than just flag this? Or can you think of what we can do? Does it make sense to have a separate parameter for which did we use with invitations? Because that was the piece I added. Because originally, the event did to and did Peer4, just use a regular did in the invitation. But then kind of downstream, I would start using didPeer2 and didPeer4. And I added the didPeer2 and peer4 to the invitation. And I just piggybacked on the existing parameter. But maybe that can be didPeer2 or didPeer4 for invitation. Give me a separate command line parameter with that. I'm always reluctant to add more command line arguments just because we've got a ton already. But so we have a flag on the out-of-band invite creation endpoint for creating a unique did, which is like halfway to reverting back to the original behavior. Except for the fact that when the didPeer2 or 4 flags are enabled, it's still creating a didPeer2 or 4. But it's still doing the original, like not reusing the same did every time for each invitation. So we could either add another flag to the createInvitation endpoint to have it go all the way back to the original behavior with the inline service with no did being explicitly created at all and just having keys generated and that's it. And then that would preserve the original out-of-band behavior. Or we go the other direction, I guess, where we have it default to the original behavior. And then we have an additional flag for enabling connection reuse with didPeer. And then that's what activates the functionality, as opposed to the command line argument. Sorry, I missed that one. What was that last one again? We retain the original behavior of the endpoint. So we revert any changes that were made to the behavior at least externally. Except when we throw in another flag that says reuse using didPeer instead of a public did. And then that would activate the new behavior instead of the command line arguments as they currently are. In which scenario are we expecting the old behavior to be required if we move forward with default into the new one? It's mostly a backwards compatibility and transitioning to newer versions of Acobi throughout the ecosystem kind of a problem, I think. If we could instantly update everybody at the same time and it wouldn't be an issue, but, yeah. Yeah, I'm wondering if the, like I feel the same as you feel about the command line parameter. I just hit that problem, Steven, when I was looking at why OB broke in BC or 10. And basically it was like two plus command line parameters that need to be set. According to each other otherwise, there's like a weird scenario and so I'm a bit aware of adding a new one. I like the idea Daniel has about like adding an extra payload attribute basically to explicitly request one or the other because that also is easy to kind of like phase out later on once we consider it migrated. And in that scenario, I don't know. I'm wondering if doing the new behavior as default add the flag if you really need the old one is the way that we want it so we can drive it away from the old behavior as well. But this is just off the top of my head. I haven't really thought these three too much. So the only thing we can really do is parameter at invocation time that lets them control it a little better as opposed to relying solely on flags. Right, right. Cause the flags are making it the all or nothing behavior. Yeah, yeah. I like that idea because again that what does traction do? Can you control? Like can you turn off emit deer did peer four emit deer did peer two in those? I guess you can make them false, right? I mean, those are command line parameters now, right? Yeah, so I'm just again trying to think of a traction instance if attraction in it. On a traction we would have to do is add those as part of the configurable settings for that instance and the instance would be able to flip the switches. TBD meaning like you need to be tested because like anything else in me behave a little differently. But I think we could turn it on on a pertinent basis like we do for some of the other settings like the log level, whatever it is. I think we already did. I'm pretty sure we added it as those are, yeah. So the idea would be a traction instance would leave these off and then a tenant would add them on. Yeah, we can do that. We can make, we need to make sure of that but I'm 99% sure that was when Akif added them that was a pair of them. Oh yes, if those, I'm just trying to find the PR if those are the ones that Akif worked on, then yes. We, what we need to do is only like they're already usable via the API. We would have to add them as the UI controls in the tenant UI, but yeah. Then it's definitely working. Okay, kind of wondering actually if we should have the command line flags at all to be honest. Yeah. And my reasoning there being that, so our entry points for the did exchange protocol, we start by accepting an invitation or creating an invitation, but then later in the process you can also accept the request. So at accept invitation or accept request we could just specify what kind of did we wanted to use for the protocol instead of having it be a command line argument. So we could have like a method, a did method parameter in the body of the request that influenced which one it did. So we could be using a different type of did for each connection. We could, yeah. Based on what the other agent can support. Right. Except there's nothing that really indicates to us what the other agent supports in terms of did methods though. So it would be like best guess or we would have to have some prior knowledge about the agent that we're attempting to connect to and dictate it that way I guess, but. You'd have multiple reusable invitations and then they could just pick which one they want to respond to. Because otherwise it would have to be some kind of negotiation in the. Yeah. In the connection protocol or whatever did exchange. It makes sense to me to have it per connection rather than command. So I mean really what the best thing would be this is saying use did and then identify the did you want to use. But. We could just what you're saying I think is just adding a new parameter use did on this. Right. Or more specifically use a particular did method and then generate a new one from. Oh, right. Yeah, yeah. No, no, you have to use a particular did because you have to have created the did ahead of time and then use that did because for reuse you got to use the same did. It's not the same did method. You have to use the same did. Right. So that's true. You don't need to throw it ahead of time Stephen if there's not one there this tag there's an invitation did it will create a. And then it'll reuse it. Yeah, I'm just wondering if that becomes more complicated than actually just saying use did. So there's two different dids at play. There's the one that we use for the invitation and then the one that we use for the connection. And. Oh, I see what you're saying. We started off talking about the one used for the invitation and then I transitioned to talking about the one used with the connection without much preamble, but. But I think the same does apply in both cases. So if we did have a previously existing did then being able to specify which one that we wanted to use for reuse on the invitation that might be kind of a nifty feature, but what's currently implemented is we'll just create one market in the wallet. And then if it doesn't exist when we go to create a new one, we'll create it at that point. Okay. But yeah, but yeah, what I was referring to was the one that we use for the connection after the invitation phase has been completed. Yeah. So indicating which did method we want to use for that long term. But doesn't it need to use the same one in the invitation or how can the other invitee know whether it's being reused or not? On response, yeah. Yeah, on response we have a did rotate attachment which is signed by the key that was associated with the invitation. So it'll be the keys associated with the did and the invitation in this case. So we have the chain of rotations, I guess. It's all way to fabricate for me. Yeah. Okay. It's the same mechanism that helps us to transition from initiating a connection with the public did and then going to a pair wise. It's the same process just with a peer did that happens to be statically resolvable instead of resolvable from a network. Got it, thanks. Okay, so what we wanna do is get rid of the did peer and met did peer two and those. So we get rid of those parameters entirely and we add into this two more parameters. One that says we keep this one for backwards compatibility but we use invitation did and connection did method. Does that sound what you're saying? I think, I'm not certain on the details but I think we're talking about the same thing at least. Yeah. So for instance, I don't think it would be this specific admin API endpoint that we would be changing. There would be one on this one but the create request is actually creating a request to a public did without an invitation prior to. So invitation. Right, yeah. Where's invitation? Invitation doesn't exist, had a band. Yeah. My alphabet, I'm not that good at it. So in this case, we could have a method selection or a use this did selection. I think in this one, public did is in the body if you look at the body of the payload, scroll down, I think it's got a public did. Yeah, you use public did is in there. Yeah. So you'd probably want to add the parameters in there for the invitation did and connection did. Now, would we use connection method here or does it go into the other one? So we could do it at this point and then if this was like a multi-use invitation, for instance, we could set the behavior for each connection that was generated from that multi-use invitation. We could also give the option on accept request which is a separate admin API call. We could also have it be present there. So if we wanted to switch from what was set on the invitation or if it was unset on the invitation, we could declare which one we wanted to use on accept request. Actually, that doesn't make sense. Let me think. Because at the point of receiving a request, we should be responding with the same did method that they sent us. Right. Yeah, so I think that also means that at the same time for invitation, it wouldn't make much sense for us to declare which method we're going to use because we'd be responding in kindness. Because we'd be responding. Yeah, exactly. We've got to the same point right there. Yeah. So it would only be on accepting invitation where we would say, this is the did method I want to use to accept this invitation. Does that make sense? I think that makes sense. So what is that boiled down to? We're adding a field here that is used did. So in order to solve our problem that we started discussing where we have an incompatibility between the sent pass versions of ACAPI, we would need to add a field that specifies whether a new did is created and used as a service for the invitation or not, or if we have the old behavior. The parameter that we add could specify which did method to use. So if we put use reuse method and then have it be like for or whatever, then it would create a did peer for did as the invitation did for that connection or for that invitation. But that wouldn't influence the did that gets generated for the connection itself. So how about this? This may be too obscure, but if we had a thing added to here that says used did, and it specified either a did method at which case it would create one if necessary and reuse it if necessary, or you specified it a full did and it would just use that did. Then, so it's a little tricky in the coding because you got to tell whether it's a did or a did method, but that is relatively easy. And then you just do that. And that gives them the opportunity to create a new did every time if they want on every connection invitation, which Ian covers your use case, allows the did method to get created, the did peer two or four gets created for reuse by just specifying the method. So it kind of covers it, it's a little subtle, but it covers it. Yeah. Yeah, I think I like that. And then, okay, now back to, okay, so Ian, are you nodding on that one? Yes, sir. It's not too rude. Okay, and then on did exchange, we still have the situation of create request where you're creating it. I think you still need the same thing because I think it would be used did method here and that replaces the emit and you get either a two or a four. So it might as well just use did again and do it the same way. Yeah, yeah, that's what I was just thinking as well. So it would be on create request. The create request would be sending did exchange request to a public did. And then the other endpoint we would need it on I think is the accept invitation or receive invitation, whichever it's called. Receiver. Oh. Accept invitation, yeah. Oh, right, because that's the same as this. Yeah, you're right. Yeah, you're right. Okay, got it. And that allows you to specify. So we're adding use did to each of those. They'll all behave the same way, which is you can specify a specific did to use, which is Tobias Looker's use case from five years ago. Or you can, or you just specify the method. And now we know whether you're using a did peer to four or whatever you want. And then we drop emit and so on. Yeah. And then the omission of those parameters all together from the endpoint would basically have the original behavior of the right then at that. Okay, cool. Okay. Okay, I like that. I think that, I think that solves our problem. Can you run like, we can write this up, I can write this up, but can you run with the Daniel as implementation since you're so deep in it? Yep, I can run with it. Yeah. Awesome. I'm definitely in the weeds and trying to wrap this up as quickly as possible. So yeah. Awesome. Are we getting rid of the admit did peer to and did peer for command line arguments completely then? Yes. Okay. Yeah. Round to second. That's not going to cause anyone issues for. No, they were added. Pretty sure they were added here. So the only scenario where it might be interesting to have the command line argument is in the case where we're automatically responding to, if we're automatically accepting invitations. Auto accept. Yeah. So we could have a default method that we have in that scenario, but that would be the only case where we would need something like that, I think. So definitely her tenant settings, it was added here, but here it was 2696 with January 9th. So that's recent enough. I'm just, I'm just worried that it's going to be used if someone's already using it and we take it away. Yeah. But it sounds like it's not, I mean, that's something you get asked at the ACA book next week. You can say we're getting rid of these two arguments unless someone's got an issue with it. Yeah. So when was the last release? Yeah. So definitely it's never been released in an official. Yeah. 11, November and those were all added after. Okay. I think we just drop them. I don't think we need to discuss it. Let's just get release three out. So, okay. So you're adding those parameters. Okay. So back to the argument you were just presenting. Do we really need those parameters? Where do they help and would they actually help? Yeah. Yeah. So it would only really be on automatically accepting invitations that there would be a question. Oh, I see. In that case, we can do something smart, which is we could say if the Hentik protocol was did exchange 1.0, then we can assume that we're just going to do an unqualified did. And then if it's 1.1, then we can just assume did peer four or something like that. I like it. Okay. Okay. And make sure when you remove a mitt, you remove it from the pertinent settings piece. Okay, cool. Do you want a new PR for this? That's what I was just wondering as well. I was wondering if I've done enough damage in the PR that I currently have open and if I should stop and let this just be reviewed as it is in this chunk and then followed up with another set of changes. I like it because then we get the description of what we're doing into a new PR, a new issue that could be copied into a new PR. Yeah. Okay, cool. I can do that. I can open the issue and write out. In that way, you can see if you agree with how I figured it out. And there's at least two of us looking at it from that perspective. Is that right? Yep, that works. Okay. So for the existing PR, should we go ahead and call that one ready for review or should I make a PR to the PR covering the issue? No, I think we run with this one and we just put another one in. Yeah, got it. I've marked it ready for review. I also updated the PR with the updated summary of the changes that I've made. It's kind of snowballed a little bit over time. But yeah, so that's up to date and ready for... Okay, I can take a look at that one today. That is a seriously long conversation. Yeah. It's been a fun one. Yeah. Okay. And then these three we're waiting on after 012. So that's all we need to discuss. Yeah, I think that's all we need to go over. I think we're there. All right. And we need to switch to another meeting anyway. Yeah. Thanks, Daniel. Yep, thanks. See you guys. Yeah, and then we'll be on another one in a minute.