 All right, welcome to the January 30th. Holy cow, 2024, Aries Cloud Agent Python Maintainers Meeting. PRS issues release 1.00 and then just a status update on Acobi for non-credits and W3C, if there is any. We're recording, so I'll post that after. Reminder a Linux Foundation Meeting and a Hyperledger Foundation Meeting, so the Linux Foundation Anti-Trust Policy is in effect, as is the Hyperledger Code of Conduct. Feel free to sign in. Agenda meeting, agenda for the meeting is now in the chat. Well, let's get started. PRS, let's take a quick look at what we've got. Pinning black version seems fine to me. I ran into some interesting fun stuff by putting a minor change in and configure out how I got 1,000 black changes, so I'm not quite sure what that is. Parcel revert of connection record schema changes. Daniel? Yeah, so in the PR that I did that just fixed the OpenAPI generation, I also tweaked the connection record usage, connection record schema usage within the admin API, switched it to using a stored connection record variant. So like the OpenAPI would actually reflect that the connection ID is always going to be set at the time that it's being returned in the admin API. But my usage of stored connection record actually changed the OpenAPI, so it also used stored con record. So I just did some minor tweaks rearrangement to get it back to the original name of con record, but still have the same characteristics of indicating that the connection ID is set. So yeah, shouldn't impact anything. I think the integration test failures are the same and on creds related ones that we've been seeing. OK, so we'll play with the order of these. There's no objections to merging either of these. Presumably that's just a very small change. Yeah, so this is just aligning all of the different places where these tools are present to this. Cool. This one is the one we wanted to discuss. Patrick's here as well. Yeah. Yeah, go ahead. Yeah, so this one will probably not going to merge it. We're looking at other alternatives. So me and Daniel were just having discussions. So I've found other things after the last comment I've put in, but it seemed like the problem here has to do with the PyLD library validating values as false and they provide default values of some argument as false, but the problem is with Python and empty dictionary is also considered as false when you compare in Python logic. So sometimes it wants to check if there were if it's false because that's the default value processes, but if it's actually providing an empty dictionary, it will also consider it as false. So it falls into some checks that it shouldn't in the code and in the traceability context, there's a lot of definition with an empty dictionary as the context value. So there's like two things going on. There's the traceability context having some terms that have an empty context field, which is a dictionary. And then there's the PyLD library assessing this as a false value when it should access it as an empty object. So I'm still making some tests. Moving further along in the traceability context by changing a bit the library. So I still need to do some tests, but the goal would be, I think, first to address this issue in the PyLD library. It's an old library as we found like it hasn't been updated I think it's been four years. However, it's made by Digital Bazaar, so it should be fairly solid. Some of the maintainers are at the VCAPI meeting. I think Dave Longhi is one of the maintainers there and Manu. So I will bring it to them, but the problem is actually in the context resolver at line, if you click on the left, context resolver. Yeah, I think we got to this one. Yeah, it's like another one further. It's the same thing, but it's like on the context resolver file at line 68 on the left. It's the same kind of logic, but it actually happens before this. Like there's a similar 66, line 66. I think that's the step it happens before. And if you go up at the beginning of that function, or anyways, it's another function. It's a bit nested, but yeah. So that's the point I'm at there. They provide a false as the default value, and it's actually being passed an empty dictionary, and then it considers that false because that's just how Python does the logic. I think, you know, I don't know in JavaScript, all objects are managed, but it maybe it's like a bit different, and it's probably just a language sort of differences. So yeah, I will bring this up this afternoon. So there's a traceability call this afternoon and the VC API. So I will bring it up at this meeting. Ideally, we wouldn't want to have to change iCAPI for this because I know iCAPI is doing what's supposed to be done. Yeah, closed, closed. When was the last time anything was merged into this? 2020? That's not good. Yeah. Like, I think Daniel said he made some research of this like alternate package that does this and there's none really, I think. And as far as I know, like the library is good. It's just that small bug that for some reason what I'm discovered. So yeah. Okay. All right. Well, I, as you might have seen while you were doing that, I switched it to draft. Yeah. Sorry. Yeah, I need to. Yeah. That's okay. So remember, once you are ready, switch it back from draft. Yeah. I mean, ideally, there should be no PR. Like if we can resolve this on the external packages, that would be the best. Either that's being the traceability context or the PILD library. Yeah. This one I think is okay. So lots of file change, but the change is literally one line. It changes the security context or sorry, the context of BBS to this. This redirects to this and evidently in some cases when that redirect, the redirection fails. So this simply changes it to not redirect but rather go directly to the current location of the context file. Andrew raised a couple of issues about it, but it looks like it's safe enough to do, notably that if it already had the redirected context in it because somebody had manually put that in before passing it in, we automatically add the BBS context to it, which would mean two contexts that are identical, but it turns out that for this, testing it in the JSON-LD playground that that's fine to do. It's not a sin. So I think we're okay to add an end. So I presume this will get updated once we do a few more full request merges. Ian, I think this one's ready and you're getting ready to merge this one or it's still in draft though. Yeah, there's a couple of integration tests that were failing. So I synced everything up with main branch and I'm just rerunning the tests right now. Okay. Otherwise it should be good to go. Okay. And this one as well? That's Jamie's. Yeah. So Daniel had requested some changes and I don't know if Daniel, if you've had a chance to review the updates that Jamie's done. I haven't quite yet. I was going to wait for Daniel's review and then I was going to review it after that. Yeah. So there is, I had some confusion because I didn't realize that the old implementation had some mistakes and then just aligning those with Daniel's like what he did. But yeah, those were updated a while ago and I think they're way better now. So hopefully you can get it done. But yeah, I'm just trying to finish the rest of the endorsement stuff based off this branch. I will, I'll make sure and give you some more feedback or an approval on that today so you can move on with your life. Excellent. Okay, good. All right. So we'll try to, Ian, since you're already running the test, let's try to get this one merged first and then we'll just go through all of the ones up here updating the main. If it passes, we go forward. Obviously, we bypass this one and then we'll get everything in. Yep. Yeah, I've got a pin black version. We can probably just merge that one, right? If that one's good to go. Oh, it's already ready to go. Yeah, it's got a little green check on it. No, result conflict. Shoot. Good try, though. I'll, uh, I'll regenerate that lock file and push up. Okay, so it should be good soon. Okay. And I'm happy to keep an eye on all those during the day and just do one after another without, as we go. Okay. A couple of them to issues. So this one is talked about. This one is interesting. I noticed the same conversations going on with AFJ making sure that everything works. Um, go ahead, Daniel, and talk about this one. And then let's decide what to do. Yeah. So I, uh, I've got my setup where I've been banging Akpai and Credo together to see what happens. Um, and this was the first issue that that I ran into after I was actually finally able to get like the dev release of AFJ, I mean Credo, um, going. Um, so it's strictly expecting as part of the out of band invitation in the handshake protocol that exchange 1.1 now instead of the exchange 1.0. Um, I've got some, uh, changes locally. I haven't pushed them up to a PR just yet. Um, I could probably do that open it in draft just to get it out there, um, where I've just gone through and just, um, added additional, uh, tweaking our admin API and a couple of spots in the out of band protocol and in did exchange where, um, determining which handshake protocols in use is determined based on the strings getting passed in and all that stuff, um, changing those points to accept the 1.1 as well. Um, it looks very similar to, um, I think some of the changes that required for out of band 1.1 to be supported and work. So I'm kind of following that as a pattern and hoping, hoping that that will be enough to, uh, to get it working as expected. Um, but I'll go through and make sure that we've got the backwards compatibility still as well as, uh, resolving this issue with AFJ. Okay. So you've got this one. You're running with it. Yeah. Appreciate it. Good. That's excellent. Um, um, that one's already talked about this one. We've got a couple of notes on the log messaging processing time. Um, we're going to, we'll probably not do this immediately, but, um, this will probably get bumped up. So the idea here is that let's at least get locally in the logs processing times for various things. So we can look at it when we need to, um, the background of that, um, from a BCGov perspective is sometimes we get, um, certain, like certain events where we're issuing a credential and it takes a very long time and we're really not sure exactly where that time is spent. It doesn't really make sense. Um, and, and then it might take a two or three times and then, then it works and, and we don't really know why. So, um, the idea here in BC wallet, they put in an ability to log things so we can see it. And the idea here would be to add a similar capability on the, um, that side. So we don't have to do a, there has been a definite talk of using tracing for that. Um, the, the tracing capability is definitely a way to do it, um, but that requires more coordination across various things. And so the idea here is let's have each component provide some technique with minimum overhead and then, um, let's figure that out. Patrick. Uh, when you say a very long time, is that like 30 seconds, five minutes, 30 minutes? It goes from 30 seconds to even two minutes. Yeah. Good. Yeah. So very strange. And this is in the wild. So we're talking, you know, we're on the, uh, people on, on the, uh, wallet team are talking to lawyers for two minutes in awkward silences. So it's not, it's not the most fun thing in the world. Right. Can I ask them out of there? Yeah. Exactly. Yeah. So this one will be closed. Um, so this one is about, um, one agent getting a peer did from another and using the same one in response. And there's really no requirement for that. It's not a bad strategy because, you know, the other side must support it if it sent it, but it's also not a requirement that it do that. So we definitely want to do not want to require that. Um, Sheldon has removed that, um, check in the, um, in the test. So you can admit a peer did too and whatever the other side wants to send back is fine as long as it's a day, basically, and it's a qualified did. So that's there. Um, Jamie's working through this. I think you've got a PR coming relatively soon. Jamie, you were sounding like you were pretty happy with this. Yeah. It's working with manual testing, but some of the integration tester, I'm just working through those now. But yeah, I'm waiting for the other one to get merged and then I'll open it. Yeah. Um, I think that's most. Oh, um, this is being done in a plugin. Thanks all for input to a key, um, on, on what to do. Um, I think that's there. Uh, he's he's pretty well completed it and, um, so it'll be in the plugins repo. We're going to merge it into the, uh, or deploy it relatively quickly into the, uh, BC gov depth traction environment and start to use it. And then it'll be used as, as mentioned in the, um, protocol for app attestation. And will be available for others to use if they want to. Um, those are the main ones. I think I did have another discuss. What was it? Um, no, no, um, these are old discuss. So I'll probably remove the label from them. Um, any other, um, issues or, or pull requests that we want to talk about. Patrick. Yeah, I always have a few things I can discuss. So, uh, one of the things is something I discussed with a key finesse to do with, uh, how I can buy and those error. So for now there's these different errors that are raised and we found that you don't have too much control over like what status codes or return and stuff. I might open an issue eventually. Uh, one library I found was the AIO HTTP catcher, which is a sort of way to centralize your errors. Uh, and you can really get into what message you want to return and what status codes you want to return. Um, I can link it in here. I don't know exactly what it would involve, uh, in the code, but it seemed pretty interesting to, um, have a solution. I can just link it here. So that's something, uh, cause I'm starting to look, especially for the VC API routes. Like one of the goals I would have eventually is to, for iCAPI to be able to pass many test suites. And sometimes they will ask like, oh, well, you need to return a 400 for example, but currently the validation middleware returns a 422. Um, so that's how it goes. So I would like to investigate a way to have a bit more, uh, freedom around what error code, error codes are returned based on the routes of the, uh, the API. I'm mostly concerned about like request validation. You know, sometimes you might want to return a 400, uh, 401, uh, so on, depending on the case for 404, maybe if it's, uh, something related to this, uh, I think this would change. I don't know exactly the impact it would have, but it's something maybe, uh, could be interesting to see. So it's to really decentralize all the errors that are raised by mostly by the admin API. Um, another thing I wanted to touch on that to do with verification. So hang on one sec. Hang on one sec. So let's, uh, the concern here would be that this number up in the corner, um, last updated and these, um, is it just not used enough and they're, and then that automatically leads to we already use, um, AIO, HTTP, should we, uh, you know, so it makes sense to use it. On the other hand, um, it's not, uh, a commonly used library. Is there something else we should be using? Anyone have any comments, suggestions, ideas on that? This might just be my own perception, but I feel like AIO HTTP is, has increased in popularity since ACPY first started. So I wouldn't say that it's particularly out of the ordinary to use it by any means. And so how, and so combining it with this catcher might not be a bad idea in other words. Yeah. I mean, I feel like I need to understand a little bit more of, of the problem that Patrick is experiencing to, to say whether this is the right solution or not. Um, but I wouldn't rule it out outright or anything. Yeah. Yeah. My, my most big concern is so when you get out of the routes folder, you know, and you get into function, you want to raise errors, right? And when you raise errors, uh, you're bound to the errors you raise, like, or maybe there's a way to make some custom errors that are going to raise a specific status code, uh, as when you are in, like, I would like the ability, for example, to raise, uh, a JSON response with a fold, like I can define what status code I can return and the message, you know, so when we're validating a class, uh, if it gives, uh, specific, you know, invalid credential subject, I would like to return a 400 error that says, that has a message field that says this is an invalid credential subject or however. And currently the validation middleware just returns a 422 invalid request, right? So that's, um, this is the type of, uh, limitation I'm currently in. Uh, I haven't spent too much time on it. So this, yeah, this is like one of the options I found that I wanted to bring for discussion. If there's other ways, uh, you know, I can also, uh, try to look, uh, yeah, there's other ways to do this. Do you understand a bit better? I think so. Um, I would be interested in having an issue open to kind of capture, um, what you've experienced. I think that would be good just to get a little bit more time for, for deep thought and, um, considering the specific cases you're addressing. Uh, my, my gut reaction is, um, I wonder if some of the validation that's occurring in the schema then just needs to move out of the schema and just into the handler of, of the request instead. Uh, especially if it's resulting in that 422, that's not particularly helpful. Um, but, um, again, that's kind of coming from, I haven't spent as much time thinking about it as you have yet. So, um, uh, yeah, not sure if that's the best approach or not, or solves all the issues that you're hoping to solve yet. Yeah, sounds good. I think expanding on what Patrick said, um, it's kind of like a little bit of a tangent, but not so much. Uh, this is probably like just make, make more formal and more consistent. The restful type of endpoints that we have in the admin interface. Another problem that we have raised in the past is some, like similar topic. We're using the post verb a little bit too leniently. So if you want to be very, very strict or kind of like argumentative about how, how to go with this, we might want to get like a bigger conversation about cleaning up in general, the rest endpoints and no, not only the error handling, but also like what verb is being used for what action. Uh, I'm, I'm not like a super strict like believer in like, it just needs to be crud because then we wouldn't have the admin API, but at the same time using posts for everything is also not good. Um, just kind of wanted to know that maybe that needs to be taken into account for a broader conversation in this realm. It's a hard one because that breaks, breaks things. I haven't seen too many that just in when, you know, when I go through the admin page, I don't see too many that seem wrong, but. We, I think we've done much better in recent years, but when we were setting it up in the beginning, so some of the oldest endpoints, there was a bit of a happiness in using posts for, for stuff that might have been better with maybe a put, right? Like it really depends on what you're doing. Stuff might have been fixed since they last looked. I just think if we do this type of kind of like rationalization of the HDP endpoints and restful interfaces, it might be good to just like look at it as a whole. Yeah, I would, I would also like, you know, with all the recent work for Anoncrez, there's new endpoints being added, the VC API thing, maybe a sort of seeing all the duplications that there is and think if that's still the right way to do it would make sense. Are you talking, Emiliano, about like the issuance protocols and these type of endpoints or more like agent management endpoints like the wallet and the credentials? I would have to like look it up. I remember seeing the endpoints, I can probably fish a couple out. I think there were sort of kind of like here and there, kind of like, you know, breadcrumbs across the whole API. It might not be a lot that needs to be fixed, but it would, if we do, I mean, I think it's making it consistent with the rest in HDP since it is an HDP interface that we're using, it might be good. And it goes alongside having proper error messages and not like 500 or 422 generic error messages when the endpoints get called. Just for my knowledge, what is a 422 officially? It's like an unprocessable entity. Yeah, unprocessable entity. Okay. A 400 is an invalid request like the client sent and valid request, but when it tweets, it's a request that the server cannot process. Okay. Which might be the right error message. If it is an unprocessable entity and you don't know why. Yeah. But if you know the specifics, we should return like a better validation message. But with the catcher, we get the idea there is we would get much better ones, you know, as it says here, much better message and we could control the code. That's basically what you say. Yeah, yeah. Yeah. Okay. Okay. All right. One thing I wanted to mention if there's 30 seconds, because you said about issues, there's that issue that Jason Leitch opened recently about basically logging some timing for some specific methods. So adding some instrumentation. I think maybe we should revisit that as well as the pertinent logging. I forget where we ended up. Yeah, yeah. Logging if it is finished or not, but that would be very useful, at least for us. Yeah. I'd really like to see that get into traction and get used. And then we revisit the adding more information to the logging. Which I think is what you suggested earlier today. Yeah. Yeah. Okay. Thank you. Quickly before we go, I've got two more topics. So give me a half second more. Release 1.0. I think we are very, very close. I would like to, you know, finish 12 and then let's get 1.0 out right after it. It's a long, long overdue. For those that haven't heard, I think that's a good point. I think that's a good point. Accompi was nominated for a United Nations. Open source award. And so open source. What's that? Like government open source applications. Yeah. Even if we don't win that, it would be good to combine that with the 1.0 release. It's long overdue. Let's, I'm going to start to look at all the things we need to do to make 1.0 happen, but it's not much in the code area. It's more in the, around it. So that would be my goal. If everyone could think about, okay, here's what needs to happen before 1.0. Maybe that's what I'll do is open an issue and get people contributing to that. So that's one. Second thing is Accompug next week is up against the same time as the DSR webinar. And I'd like to cancel the Accompug and encourage people to go to the DSR presentation. Are we good with that? Or should we have the Accompug? What is the webinar? I've not heard of this yet. Oh, it's DSR is going to do a presentation on the indie work they're doing, the AFJ work they've done, as far as ledger agnostic and various things to do with the whole identity space. And so I think it's an important one. They've been building up to it. Hyperledger has really been encouraging people. So I think we should support it by not competing with it, if you will. We could have a follow-up maintainers if we need it, but if that's okay, I think we should encourage people to go to that. So I'll send out a notification that it's been canceled. There's the event. Yeah. Cardano and on-credits checked, Asian framework. It's got everything in it. So I think it's worth us taking a look at. Thanks, Sharif, for posting that. Yeah, did I send the right link? Let's do this February 8th, Thursday. Oh, that's the third link. For some reason. Oh, you know what? They rescheduled it. Okay. Well, that's a whole nevermind. You're right. I've got it down here as there. Oh, nevermind. Oh, but I encourage everyone to go to it, you know? So nevermind that. Acapogue's on next week. We're going to talk about release 1.0, blah, blah, blah. Okay. Sorry about that. Take care all. See ya. Sorry for running over. Thanks.