 All right, welcome to the February 27th, 2024 Aries Cloud Agent Python Maintainers meeting. Normal PRs and issues to talk about release 1.0, things going on that we're well aware of, adding support and ACAPI for it on creds, the out of band invitations that came up this week, and Ian's been working on that, and then the discussions and comments that are going into upgrading wallet types. So those are the topics for the day. If anyone has anything else, let me know, and we can hit those as we go. Reminder, this is a Linux Foundation and Hyperlegger Foundation meeting. So the antitrust policy of the Linux Foundation is in effect, as is the code of conduct of the Hyperlegger Foundation. So please follow that. Posted in the chat the information about the meeting. So feel free to jump in and edit PRs. I think we're pretty up to date on the PRs. Oh, that's a new one, but oh, open last week. Okay. That one will get updated. Oh, it looks like it failed something. But anyway, this is the W3C format. One, we've got the new exchange to peer related fixes. Be good to get those moved forward. I don't know if Daniel can hand them off to anybody. This is definitely not going to happen. I don't, yeah, this is not going to happen. The please act. So this will be closed soon. We've removed please act and retired the protocol in the Aries RFCs. So this will be closed with a reference to that. These two will be closed. And then the last one, Akif is now working on this did rotate protocol from the Akif from the BC Gov team. So we're working on that now and that will be completed. Might even have been completed yesterday. He was hopeful to have it finished. Daniel did a lot of the work. Akif had some additions to it and then test cases to write. So that was moving forward. And then these ones are likely to be closed. I would think although Daniel did work on that one. So pull requests are pretty up to date issues. The big ones are the upgrade. I haven't had a chance to re review those, but we'll talk about those a bit. These are documentation things. Eventually I'll ask someone to look at that one. It's pretty minor stuff, but nice to clean up. I don't think there's any of these we want to really look at. So I think we're okay to move on to the topics because the ones that are in here that we want to talk about are covered by the topics we're going to go through. So if I go back to the meeting, let's move release 1.0 down and do that at the end. Ian, did you have a meeting with the what's cooking folks yet or is that still being arranged? It's still being arranged. I had a discussion on Discord with the developer in Myanmar. All kinds of non hyperledger related difficulties in that kind of thing. Yeah. So they've got another developer they're bringing on the project and so they were going to schedule a meeting for Wednesday morning with everyone so that I could get an update. But then I got a text on Discord last night at 10pm asking if I wanted to join the developers meeting, but I was asleep by then. So hopefully we'll still be on. I'll follow up with them like first thing Wednesday morning. I'll just ping them and just make sure or I'll you know follow up and get a status. But it's been slow. The work has been slow on that one. One thing you want to do is encourage them to be ready for an Acapug presentation for next Tuesday if they can. Okay. So no matter where they are, I'd really appreciate it if they could come on and present where they are. Yeah, it looks like there's a couple of issues with the demo. I sent them a couple of updates that they need to make. I pointed out a couple of changes they need to make and then there were some other issues that I ran into. I'll try and work with them to make sure they get at least the demo working. Yeah. Okay. I'll include that in the instructions and just assume that. But if you could, yeah, it'd be great if you could arrange your meeting with them this week. Yeah. Okay. Oh, out of band invitation supporting peer dates and connection reuse. So I had kind of thought but wasn't sure that was supported. And so put in a topic to say, okay, let's make sure this works. And after looking at it for a bit, Ian's determined it is not supported. So Ian is working on that. There's an issue in that he's put and documented what he's working on. But to summarize it quickly, enabling creating peer dates that can be used in invitations, reusing the same peer did in all invitations, whether they be used single use or multi use invitations. And that is necessary to use did peer did types two or four is necessary in an out of band invitation to allow a invitee, the person receiving the invitation to find out and reuse the connection they already have. So you have to have a did that is fully resolvable as it did. So a did solve that is published on a ledger works and we've used that in the past, but a peer did type two or four is also a fully self contained did doc inside the did string. And so they work for connection reuse. So that's what Ian's adding support for. He's adding a way to bypass. So the default method would generally that you'd use the peer did two or four as the way to generate a peer did and use it for all invitations. But also adding a way to bypass that. So a an agent could choose to allow for separate ones if they want, not use reuse. And there's use cases for that of which Ian has worked on one in the past. And then and then working on the invitee side to make sure that reuse is enabled there by default. I think I think on the invitee side that everything should work. I think so. Yeah. But yeah, by tour side. First is to add support for creating did peer through the through the wallet did create endpoint, which right now the did peer to and did for doesn't work. And also, we're going to put a tag on or enable putting a tag on the did to specify which did is actually going to be used as the did for invites. And then just make integrate that into the event invitation. Okay. Okay. Thanks, Ian. Upgrading wallet types. So we've had a number of convert conversations here. So the specific issue we have right now is we have an ask our wallet type. And and we have an ask our and non creds wallet types, wallet type. And we want to enable a a occupy instance to upgrade from ask our to ask our and on creds. But we want to also give a tenant in a multi in a multi tenant occupy configuration, the ability to upgrade upgrade on their own time. So we don't have to run an occupy upgrade that upgrades all the wallets, because that will require all of the controllers simultaneously updating their code to use new endpoints. What we want to enable is allowing each tenant to choose when they want to upgrade, giving them a mechanism that they can indicate, okay, upgrade. And, and they would do that in a way that simultaneously updates their endpoints. So the scenario we envision is that a tenant controller will release a new version of their controller will scale down all of their old controller instances will start up new ones. In the new ones, there will be a upgrade wallet type command executed as part of the initialization. So an endpoint to do that that will trigger the batch operation that will update all of the all of the records necessary in the wallet, all of the relevant records, and then we'll proceed with using it and the new controller will use the new endpoints that are required when you go to ask our and on creds. So that should give every tenant full control over their upgrade. Ask our to ask our and on creds is the current use case. We do anticipate that at some point there will be another wallet type. So this is very similar to a version to version upgrade. But you know, and in a traditional app where you and upgrading a version requires updating the database in some way. In this case, the database upgrade is constrained to just upgrading data records. There's no change in the database schema or structure of the database. So no need to, you know, do anything like that. And, yeah, and, and as I say, it comes with an associated change in endpoints. So that's why we think this this will approach will work in and others comment on what I just said, did I cover it correctly? Yeah, so just there's two tickets that we've created. So the first ticket is just to make sure that the acupy can support both wallet types simultaneously. Because right now the way we initially did the non creds integration was when you start up acupy either with Ascar or Ascar non creds, it'll enable the appropriate endpoints. So we need for the multi tendency for all of the endpoints to be available. So that's what the first ticket describes is how the making sure that acupy can support that. And then the second ticket is the actual upgrade process, how the upgrade process is going to be built. And it needs to work for multi tendency, the way Steven described, but it also needs to work for a single tenant acupy as well. And just kind of related, like we have to think about this multi tendency upgrade anytime we do anything that is a breaking change. So in this case, you know, it's, it's fairly straightforward. We're creating new endpoints for the non creds. So, you know, the controller has to switch over to use the new endpoints. And then, you know, they do the upgrade when they, you know, when they do, when they do their update to the controller. But anytime there's a breaking change now, I think we need to evaluate. Yep. And I think this is really something we want to get finished for the 1.0 release. And it'll be a barrier to getting to 1.0. But being on 1.0 is also a benefit. So you're, we're doing a carrot and stick on this one, I think, which is helpful. So I think that's the plan here is we get all this work done in preparation for the 1.0 release. Does that sound right to anyone? Any comments? Okay. As far as the 1.0 release, we've got our flag. We still haven't had really the LTS discussion. And it's something I'll probably think about while I'm sitting in a cabin in the woods to try to go over exactly what that would mean. We have got this resolved. So this one is now resolved. That one is almost resolved. I guess that's to be completed. But we're pretty close to that. And then if I come back to issues, if we go to 1.0, so the biggest one that's a concern is this one. So we'll have to think about this one. I don't know if anyone, Shar, Alex, or Adam can talk to Daniel about what he suggests we do with this one. But this is, this one would be a good one to finish off. I know Daniel had that as a sort of a local branch that he was doing to make sure and running a bunch of tests. So he had an easy way to do it. Maybe if one of the three of you could talk to him about that and see if we could get someone to take that one over, at least understand how to do it and move it forward. Good. Thanks. Thanks, Shar. Akif, I don't know if you were there when I first talked about this. Any comments on did rotate at this point? You're on mute if you're speaking and if you're not. Sorry, my mic was frozen. I'm going to some changes up today and hopefully start getting the process going for getting some comments on that. Excellent. Good. So it's pretty close. You're happy with it? You think it's going to be an issue to finish or is it all right? I think it'll be fine. I do have a question just regarding the hang-up portion. I don't think it's too critical for the rest of the stuff, like the actual rotation part of it. Just in terms of the way it was written as the hang-up message takes a to-did and I'm not sure if the intention there was that to link it to the did that was initially you were trying to rotate to. So that was something I wanted to maybe ask Daniel about, but it's not documented in the RFC, so I don't know what the intention was there. I would say post it on Discord and I would talk to Sam about it because I think Sam did the did rotate. I'm pretty sure the intention of hang-up is to tell the other one, hey, I'm deleting your record, so I'm never going to be able to receive a message from you again. You can do what you want. Yeah, so I think in that context it wouldn't even matter if you sent it with the did that you were trying to rotate to because the intention is to just sever the connection altogether. Exactly. The intention is to sever the, you can confirm that with Sam, but yeah, that is definitely the intention of the hang-up. Okay, otherwise the rest of it is looking pretty good. Excellent. Good to hear. Okay. Okay, the last one that I realize will come up and I hesitate to ask because we just are still not completely finished defining and deciding exactly what to implement, but I think we're there for what pretty close for what we're going to do for upgrading. The next one we're going to have to consider from an anon creds is how to add a new did method. Creds supporting did method. We've not done that yet. We do have a potential offer from Hedera because they want to add one to Acropy, but that is another one we want to support, which is, yeah, another did method, another ledger basically. So one hopes that with the anon creds ledger agnostic there is a straightforward definition of how you do that, but as far as I know we have not tested that theory and so that will be the next thing that comes up. I don't know, Ian, if you have any comments, have you seen anything in that area yet? Have you taken a look at that? Well, the way that the new anon creds module is architected, it's got, I can't remember the term exactly, something like a plugin. So theoretically we should be able to do it, but I suspect we've got other touch points in the code, like just, for example, on the wallet create where we're creating dids in the wallet, it's got the hard-coded list of did types that support. So depending on how much support we want, there might be other places, but I think if, I mean, there might be some tinkering if we want to do it by a plugin, but I don't think for adding a new ledger and a new did type, I don't think it's going to be too onerous, but there's just might be some places in the code where we've got stuff hard-coded still. Yeah, okay. Okay, good. Okay, well that's starting that conversation. We're definitely going to have more to come on that one, so just be ready for that. Any comments from anyone else before we wrap up? We're just at the end of time. All right. Okay. Alex, while you're here, Acreta is working great, just so you know, we're continuing to use it in BCgov, certainly, and highly successful at running our tests and getting things done. We're adding a, the last one we're going to add is a verification test where you, in the initial setup, you get a credential, and then in the loop for each agent is just hammering on a verification to see how much we can hit a verification service. So what's that? Awesome. Okay. I heard that. Excellent. Okay. All right. Well, thanks all. That wraps up, and we'll see you at the AcrePug meeting next week, and we'll talk about probably some of these things. Again, if anyone has any topics they want to go over for the AcrePug meeting, let me know. Otherwise, have a great week. See ya.