 All right, welcome to the July 11, 2023 areas, CloudAge and Python user group meeting. Number of topics to go through, I've messed with the order and the agenda in the lower part, but I realized I didn't have data in the summary, so I'll fix that as we go. We are recording, so we'll be posting this after. Reminder, this is a Linux Foundation hyperledger meeting, so the code of conduct is in effect, as is the Linux Foundation antitrust policy. I'll post the agenda link in the meeting. People are welcome to jump in there and help out with note-taking and add their names to the attendees list. For those new to the call, welcome. Glad to have you here. If you'd like to introduce yourself and talk about what your project is and what brought you here, we'd love to hear from you, so I'll leave the mic open for a few moments to let anyone introduce themselves. Yeah, I'm new, I'm Robert Simpson, and just went through the areas developer course on EDX, and so I'm looking to develop some verifiable credentials kind of apps with images involved, so that's the direction I'm headed. Okay, BCgov just added a photo to the person credential that is being used within the province, so definitely workable. There's just a new RFC about using a data URL in it, so. All right, good to know, thanks. Yeah, all right. Okay, next up, sorry, anyone else wanna jump in? Okay. All right, as far as announcements go, so I'm gonna try to keep this meeting relatively short. The Aries Framework JavaScript workshop is on right now, just started, so I had signed up for it, looking forward to it, so I think I've kind of kept the agenda a little bit shorter than it had been, and hopefully we focus on the right things for this, and people can jump over to that that are interested in that. Accapai release 082 and 100-RC3, the release candidate three have been released, so those are out in the wild and recommend updates. One of the last-minute things, and it really is part of the dependencies of 8182, but if you're using the images, artifacts, container images, 082 has been updated with this, which is there was a bug noted in non-creds when using Ascar and the CredEx library where a verification with multiple revocation registries involved would fail because of the handling. This was something in the Python wrapper, has now been fixed in CredEx, been fixed in and being fixed in the an on creds RS library. But be aware of that one. Other than that, there's a change log and a number of new updates in the 082 release. Likely we'll have breaking changes, and we're gonna talk about one of those a little bit later in this. So the next release is probably 09 or perhaps we get to 1.0, we'll see. 1.00 RC3 is identical to 082. It was an unfortunate decision that I made to start releasing release candidates of 1.0. Thinking we were closer to that than we were. And so what I've decided to do is just continue the release candidate stream for anyone who was on that, but just simply make it compatible with whatever the latest ACAPI release is. So identical to it. So you'll see those as they go. I don't know, Daniel, if you wanna share any updates on the an on creds Rust and ACAPI, we did a presentation last two weeks ago. PR 2276, which is the main work that's gone into that has been merged into a branch in ACAPI. And there's a project for, and we're getting more developers on that. Jason Sherman, I'm not sure if he's here today, but we'll be starting on that today. Wrapped up something that got merged earlier today. So he's gonna be jumping on that and pushing on it. And we'll add more people as we can than anyone who's interested in helping out with this work is welcome to join in and put up your hands and we'll help you get started and get moving on that. This is a very high priority one for us getting an on creds RS. It's a big effort and we need to, and involves a bunch of cleanup. And so we'll improve the overall state of ACAPI and we're looking forward to getting it done. As well, work on did peer and two, did peer two and three supported ACAPI continues not too much updates to make. And Jason Syrotuk who is doing the work is not available today. So I won't give much more of an update, but he continues to work through it with more and more success, but it's a bit of a struggle through both a learning curve in ramping up on this and then the sort of dynamic nature of did peer one, two and three and how different implementations have come about. So we're really trying to nail that down into a single implementation that's consistent across all of the Aries libraries. This came up this week in issue 2289, which is to switch over to poetry. This is a purely a developers question. And so I've sort of opened it up. Maybe Daniel, you could talk about it or others that are proposed this idea of using poetry. I know I've seen it more and more in projects, but I don't know the implications of it. So I leave that open to others. I'll, I guess briefly comment and say that. So I was on that raised that issue. If I'm being honest, I don't feel too strongly about this. If I continued using the standard PIP stuff that it's been using for a while, I think that's just fine. But poetry does bring some nice to haves. It's a better developer experience, I would say overall, and has slightly more dependency resolver and all the stuff around like resolving the tree of dependencies and stuff is slightly better for poetry than as compared to PIP. So yeah, it's just kind of a nice to have. We've got a lot of experience using it on the NdCO team and we use it in our plugins and it's, there's no issues with like mixing and matching between, installing a package that was built using poetry and then using that from PIP or the other way around. So there should be no change ultimately in terms of like the actual usability of the package that gets published. Okay, anyone else want to comment on poetry versus PIP? I definitely agree with Daniel. The resolver is absolutely very, very beautiful. So I think that direction is very welcome. Okay. What is the type of effort to do the transition? Is it just a single PR to basically go through everything and change it? Obviously to get have actions change. It's a breaking change. So this would be a good time to do it because we have breaking changes going into this release. I guess it depends on how you define a breaking change. It's a breaking change in the sense of if you're a developer on the project then there's a bit of a change in workflow. But as a consumer of either the container images or the package that gets published to PIPI, there's no change. Okay, okay. I would say, I would say whether we do it now, whether it changes much or not at some point, it's going to happen. So, rather keep it for later, we can just go ahead. So I believe the change is not much for those that I'm not really able to pass like Daniel said. Okay. So I would say we should encourage someone with poetry experience to put in a PR, make the change and then we'll announce it and just make it known to all developers working on Accopy about the change. And right. Any, I guess the other way to put this is from any of the developers, any issue with doing that, anyone against the idea of using poetry versus what's being used now. I mean, it is two extra characters when doing an install. It's like. I guess my only comment would be what's the scope? Are we changing all the images, tease poetry? Are we leaving all the requirements texts in there? So basically using poetry to do the dependency resolving and then just exporting them as requirements and just, like I'm using poetry. So I'm fully on board with that. I just kind of want to know what the scope is. My assumption, but I could be wrong. My assumption would be we basically changed. We include the GitHub actions that are producing the dependencies to also use poetry. Yeah, that's what I would recommend. We could, as Jason was saying, we could just export a requirements file from the lock using poetry and use that to install. But I would definitely recommend just doing a wholesale shift to poetry wherever we use it or wherever we're using PIP right now, that is. Okay, sounds good. Yeah, I just, yeah, that's it. Yeah, okay. So invite anyone to make the change if someone wants to say they're gonna do it now so that there's not multiple people working on it. That would be great. Or tag yourself on issue 2289 and a PR is welcome. We've got people with lots of experience, obviously from different organizations that can evaluate and review. So we'll welcome that PR. I may add a comment in there just recently, yesterday. There are some dependency conflicts with what's going on in Acapai and other assorted things that you kind of have to pick specific versions of packaging and whatnot. So maybe as part of this, we can smooth that stuff out. So I'll leave a comment in there if I can remember exactly what it was I did yesterday. But it'd be nice to not have to have poetry say, hey, I can't do this because, yeah. So I'll try to remember where that was and put it in exactly. But yeah, we can smooth that stuff out, it'd be great. Okay, John, do you wanna add something? No, no, no, no, not that, sounds good. Okay, next topic is a couple more PRs that we wanna process. 22.95 is in today. So let's look out for the co-op press. Allowing it to be public. This touches on the end of the resolver with the goal of allowing a, for instance, did web to be a, oops, did web to be a public did. So we encourage folks to look at it. It looks like we have some updates or some review being done on it, encourage that. And then if we like this, we can get it merged. So this looks like a good change as far as any comments from it. Daniel or anyone that is taking a look at it already. I've only glanced at it so far, glanced at it deep enough to know that it overlapped with work that I know Sikbo was doing. So I invited Clement on the Sikbo team to comment and he's now left some. I just haven't gotten a chance to follow up on that. Okay. It also may, I don't know, overlap with some of the work. It's did related. So I did wanna get a Syro to look at it. Jason Syro talked to look at it in relation to the did peer two, three. Yeah. I had the same thought. And then I back steps because it was specifically talking about handling of public dids, which I know did period. Yeah. So yeah, but I think it would be valuable to have his insights, especially because of how much he has been touching. I agree. Yeah. Okay. It's funny that what you said that described exactly my thoughts today on it. Okay. Next one was this one, which is a classic example of why not to have too many discussions in a task when you should be getting together on a phone call to talk about this. So I'm hoping the right players are here. So the overall issue is a while back, we made it a default to remove credential issuance records from Acapai. And we did it by having a flag called preserve exchange records. And the intent, I think at the time was that we would also do this for presentation exchange records for not only for an exchange record, but also for not only issue credential, but present proof, but that didn't happen initially. We do want those removed and in some cases, but we do want some fallback to allow specific instances not to delete those records if they don't want to. We now have sort of two schools of thought and there's been back and forth on this with me going particularly far back and forth in deciding which to support. So basically Jason has implemented this idea that we would remove it and then implemented a way to allow the removal to be requested, which is this approach, which is there are two schools of thought and there's there are, he has implemented four flags, auto remove, for example, sorry, presentation and then the role of the person. So whether it's a verifier, a holder or whichever. So auto remove exchange type. So there's quite specific controls over these. And that's one way we can do it. The other way is simply add a flag that says by default, we're going to remove any present proof records. Once they've completed. If you want to retain them, you would use this preserve exchange record. This preserve exchange record would apply to both issue credential and present proof. There's pros and cons and a lot of back and forth. So let's have a discussion here to finalize this. Jason, do you have a opinion on what ought to be done? Not really. I mean, I agree that there's a, there are a lot of configuration flags and learning how to configure Akapai is difficult. It's tough to wade through. So adding four more flags, I think that's a good idea. I think that's a good idea. I think that's a good idea as opposed to enhancing the existing one is I can see an argument against that. The, the reason for having the flags, particularly because I'm coming from traction, which does want to retain records. My thought was more along the. Allowing the flexibility to do anything. So I think that's really, if the community feels like, Hey, let's just do what the original intent was to have the. Preserve exchange go across all the exchanges. I'm fine with that. It's really, it's more of a community kind of thing. So, you know, having former flags is confusing potentially. Flexibility comes at confusion, I guess. So. But that's really it. It's, that's where my head was at with. And with adding the flexibility was that I. Coming from where I came from that would have been wanted. But. Yeah. Enhancing that current flag would still, I think achieve the goals for the traction team regardless. So. Okay. I think my. I'll jump in with my views. And I'm really back and forth on this as, as you can tell from my ridiculous comments on this. My feeling is generally that acupy. And the storage should not be for long-term. Storage that acupy should be strictly for. You know, protocol. So I think that's really important. So. For tracking in flight protocols and once a protocol completes, it's up to the controller to preserve any information necessary. So. I like the default of removing them all. I like the ability to save them if, if you want. So my leading was sort of where we were to begin with. And I think that's really important. And I think that's really important. And I think that's really important. And I think that both issuances and. And. Exchange, you know, present proof records. Often. Well, while any particular agent can do all of those things, often they, they won't do both. So there won't even be any crossover. So. That would be mine. Daniel, you've weighed in. So I just had a thought while you were talking there. So I think I'm in agreement that I think we should have the preserve exchange record. Be the. Command line argument that controls the. Or that influences the removal of these records. With the only remaining question that I really had as I was thinking about this, do we really need the granularity of picking and choosing which records we did and did not preserve. And I think a better answer to that rather than having more command line arguments is. In the admin API. We make sure that we continue to respect the auto remove. Parameters on the presentation and credential exchange. Endpoints. And so if you need that granularity, you can just do that through the admin API. And then otherwise, you know, you can, you can either turn on the hose or turn it off and that's it. And I think that would be preferable. Okay. Gotta make sure I write a note down here. Yeah, I mean, I'm. That sounds good to me. And I really think that the like, say coming from the traction world, the. I think they can write a plugin. They can do that. They can do that. They can do that. To do. To change that behavior, right? It's not, it's not a huge deal. And I think at the end of the day, the real behavior they want is actually slightly modified. In that they don't want to retain the whole record. They only want to retain a subset, which would be like preserve with transform or something. Because they only want some historical context to know. So that's the whole conversation, not the, all the encrypted stuff. So a very small payload. So I think to me, that would be let them write a plugin or we can write a, that's kind of specialized behavior. So I think if we stick with the acopi behavior being option one, respecting the auto removes on the API. And then letting additional funky behavior be in a plugin. I think that's probably the way to go. Okay. Do we need to do anything with this to enable that. Plugging capability or could we just move forward with this one? And then that can be. Done at a, at a, as needed. I would say they, they can do it when needed that. As long as right now they have the ability to keep all the records they want, which as I say are. Massive right now, which is not what they really want, but that's just, that's just the way it operates. So I think just by having the, the preserve exchange record option. We'll keep them working just fine until they have time to address like what it is they actually do want to save, which is a small subset of that data. Sounds good. Yeah. Okay. Any other feedback from anyone want to weigh in on this one. At this point, we say we go with one and we make sure that the admin API has the necessary. Fine grade functionality that, that could provide this if necessary, that a controller could do what they needed to do. Yeah. I think, I think it's the optimal solution right now. Because I think respecting the auto remove and giving the other guys plug in to be able to like keep what they want. And I think it makes them more in control. So we don't actually need the full transaction history just like a sort of a way to track about the history of those stuff. So I think like it's the optimal solution. Okay. Yeah, I know that topic has come up before, which is that even if you preserve the record, it ought to be. Well, maybe we should talk about that. You know, as Jason said, if you preserve the entire exchange record, you've got all the messages that went back and forth. Does it make more sense to preserve when you preserve it to preserve a minimum sub a subset of the data or do we preserve the entire protocol and leave it to a plug in to do the proving essentially. Yeah, I think I lean towards leaving it to the plug in. Yeah. Sorry, Daniel, go ahead. No, but that's really all I had to say, I think. Okay. Right now I know in traction, there is a plugin that tracks the status change timestamps. So that's something they want to have. They just, I don't think they've sat down to determine what's the end. I mean, we've got this whole thing. What do we, what's the data we need out of it? So I think they can just enhance that history plug in to say, great, when it hits complete stage, let's remove all the unnecessary stuff. I just don't know if they've reached that stage yet in their getting user feedback on what as a business I need to see to be able to know what has transpired. Yeah, I think that's a great question. I think that's a great question. I think that answers the question, which is if you want to preserve something, you can decide what to prune and what not to prune, what, what do you want to keep? So if we do something in occupy itself. To prune the record. We're making that decision globally. And that's probably not the best idea. We're going to go with that strategy. So that answers that question. Yeah, I would think it can get very specific. Yeah, that's good. Okay. Okay, the last thing I wanted to do then was, are there any other pull requests? The other one that is this one. Are we at a point where we can merge this one, Daniel, or are you still looking, you didn't get input. From anyone on that. Yeah, I would. I think that's a good one. I think that's a good one. I think that's a good one. So instead of. I don't know. Observance of. Convention and protocol. I would appreciate having some review some others since I had a small hand in that, but. Jason got that one, I guess. Most likely you're the one to do it. So over to you and take a look at that one. Yeah, I can, I can look at it from a coding point of view, but I really quite honestly don't know enough about what's going on with that one. I don't know if there's a technical. Thing in there related to that. I probably be able to weigh in on that, but certainly from a. You know, a code perspective of what's going on, which I'm sure is fine, but yeah, if someone's more an expert in signatures than I am, which I'm sure there are. That'd be great. Okay. You go ahead. Way in and just put in whatever you think is appropriate as a way to look at it. And then we'll decide from there if, if we need someone else to take a look. Okay. Sounds good. Awesome. Thank you. We've talked about this one. This one is going to be stopped. So there's a few players that are down in the list. That are quite old. So we'll probably take a look at. At some of them. Yeah. This one is, is pretty small and just to do with an OS separator. So I'd really like. I just don't have enough knowledge on this one to decide, but maybe somebody. Could take a look at that one as well. Just to clear it off the list. That's the last important one. Oh, Daniel. This one. I'm guessing we want to. Remove this one, I think. But a decision needs to be made as to whether it has anything that helps with what you're doing with the non-creds work. I mean, the goal of it was to use. The existing things for ledger agnosticism. We now have an on credits where that's. That's the basis of it. I don't know if we want to do anything like this. Right. Not really just close this one. So I can go back and do another quick scan. It's been a while since I've looked at it, but I think. From my memory, I think we're probably. You know, just end up closing that one. I just, they very much went in the direction of. You know, I think we matched the same interface that existed previously. That was very much defined by Indy. And so anything, anything you would plug into. To their interface would have to more or less resemble. Indy. Which is. You know, achieving the same goals of ledger agnosticism, I suppose, but is a different approach from the non-creds interface where we, we went back and simplified. And so that's kind of what we've done. I mean, I think it's all the complexity of. Indy specific stuff is behind the scenes as opposed to being. Right up front in the interface. So. Yeah. I can go back and give that another quick scan through to see if there's anything that. We could really benefit from still, but yeah. Almost certainly it's, it's, it's to be closed. So, and now. That's a fine outcome. Don't, don't be stressed about that. But it would be worth you having a quick look at it. Okay. I think that. Gets us through these five. This is being worked on. I don't know about this one. I don't know about this one. So there's a few others we can look at, but they're not urgent right now. Left them long enough. So we'll look at that. And I think that wraps us up. If anyone. As I mentioned earlier, anyone is interested. In helping out with the. Inspiration of the, an on credits RS work that has expertise in, in acrofi internals. Please raise your hand. Let us know. And we'll be glad to. Get you involved in that. With that, I think, are there any other topics people want to raise at this meeting? So the, the only thing I wanted to follow up on that was on the agenda. There was the extra meeting plan for maintainers each week. Yes. Yes. So one of the things we wanted to do was to have a maintainer and extra maintainers meeting. I was thinking. In the off week for this is the, the developers meeting. I was thinking. Maybe the half hour after that meeting, we could have this one. So. Nine Pacific. For 30 minutes. On Tuesdays. Would that work? Daniel, you're important. Jason, you'd be important. We're straight. Works for me as well. Okay. Awesome. I will put that on. On the, this is a maintainers week meeting. Keep the key thing we want to go over would be. Work in progress and the processing of the PRs. I do encourage maintainers at any time. I do encourage maintainers at any time. To follow a meeting with the set of maintainers. We do have a list. And where we're working on things to, to get discussions like we had with this presentation exchange record. So we're not going too far back and forth. So I do encourage that. And those can happen as well, but as, but let's have a meeting every week to, to go over what, what we're doing from a purely development perspective. This can be more focused on sort of end user things and, and demos and things like that. Right now maintainers, there's a list of, of maintainers A and B there is a process for becoming a maintainer. If you feel like you've done the work necessary and want to be a maintainer. Yeah. Definitely occurs that. Or if you simply want to join in on the maintainers meeting. I would encourage that as well. We welcome you. With that. Any other topics to go through. All right. Thanks for joining. I will set up the maintainers meeting for next week. And as they say, if anyone wants to join in, bring me on. On discord. And I'll add you to that meeting. Perfect. Thanks, folks. Thanks. Yeah. Thanks for having me. Thanks. Thanks. Yeah. Thanks for having us.