 Let me try again, thank you. Desktop one, desktop two, and I'm so automatic at hitting desktop one. Oh, well, thank you for pointing that out, Ian. This is all the stuff you've missed so far and seeing on the screen. That's a, well, lots of things to see on my screen and list of files. Oh, well, okay, let's get started. I will hand over to who's going to present, Golda. No, Kenny's going to present. He's the one who's working on it. Okay, so I will stop sharing that screen or either screen and turn it back over to Kenny. Yeah, good day everybody. I'll share my screen. I don't need, can we also share my screen? Yeah, I'll share my screen. Okay, so what we are doing right now is to send machine credential to the VCDI format, the W3C format. So I've started running the agents due to because it takes time to run the agents. So I've started running it already prior to the meeting. So this is the Faber agent. We're running the Faber Alice agent. So this is the Faber agents already running and created connection between both of them. So, yes, we're up to that, yeah. So yeah, this is the part where the Faber issued the credential to Alice. We could see the credentials issued, the connection ID, the comments and the formats, if you touch to the VC formats and get to send an offer to Alice and we could see the attachment formats and we could see the credential offer. Where Alice issued a credential of... I think I'm not sure we're seeing... Are we seeing the whole part of your screen, Kenny? I think I'm only seeing the part where the build finished. Do you want to load onto your screen the part with the VCDI credential offer? Okay. Yeah, I'm only seeing the terminal with the Docker Compose build. Okay, I think that's... Maybe it's in a different tab of your terminal or if you wanna share your whole screen either way. Okay, I'm trying to... Yeah, no worries. Let me stop and share again. This seems to be a theme today. There we go. Okay. So is it better right now? Yeah, now we can see. We're seeing the QR code and the rest of the log. Yeah. So, okay, what you guys missed out? The connections were already created between Faber Agent and Alice Agent. So, this was the part where I sent the credential. I issued a credential letter to Alice, which is open running already. We could see that it sent a pillow to the endpoint, send offer, which sent an offer and created a credential proposal with the format of VCDI. As we said before, VCDI just did a written format. But that's the name we chose. We all chose. And also with the filter attachment and credential offer being sent to Alice. So, that's, if you look at Alice, Alice received a credential. Let's get down to where our credentials are. So, our father received and credential was being issued to Alice. Cool. And then... Yeah. Go ahead. Go ahead. That's a little bit. So, as far as the new endpoint, I think we tried to make them as smallest perturbation as possible. I don't know if Sarthak, if you want to share as far as using the new endpoints. Okay. Okay. As far as using them, it should just be a matter of, I don't know if Sarthak, if you want to share as far as using the new endpoints. Okay. Okay. As far as using them, it should just be a matter of choosing the type to use. Yeah. And I don't know, Kenny, if you want to show the piece of the code. I don't know if you had that prepared to just show the call to them in the branch so that people can see how to call them. It's, you know, it's as little different as possible. So, it's like, it's not a whole big chunk, you know, that you have to import. I believe it's just a flag that you're adding. You know, this is, this is as little perturbation demo as we can do. Do you want to share that Kenny? I'm not sure if you have it handy. I don't want to put you on this. Yeah. I appreciate that. And this should be it. That is when trying to run it, you have to declare, there's a declaration of the credential type. You're running with. Yeah, I mean the code for the new demo. I don't know, like, just to show the, you know, the test that we're running in the code to just to show that it's, it's almost the same as the other demos, but just like a slightly different flag and format. Okay. We get that. Sorry. Yeah. No, no worries. And if there's questions, Sarthak's also here who's been working on it some too. So. The code is still in our repo with a pull request into. The ACAPI. So if anybody has opinions about the pull request. They're welcome to put it in there. I saw a couple of things myself that I want to make it a little more dry. So we're still, you know, we're still doing a few final changes on it or the next couple of weeks before it's actually going to merge. We could just share the, we could just open the PR and share that. I don't want to take too much time here. I don't want to take too much time here. I don't want to take too much time here. I don't want to take too much time here. Stephen, if there's other stuff we got to do. Yeah. Warren, you want to go ahead with your question. Yeah, thanks. I haven't really been. Paying attention to what's been going on in the. In this particular. Branch of investigation. Would somebody mind catching me up a little bit if that's not. This is. Providing a way that the non creds credential is passed in W3C, VC data model format. VCDI means VC data integrity proof. And so the format is of the credential and the presentation is in the. VC data format VC DM. And then it's in the W3C format. So what that means is we're passing data in a standard. W3C standard format. It can be held whether or not. It can be held by a. A holder that may or may not know enough about it. And in particular. We can do parallel signatures, and then we can put in a non creds and a. For example, ECDSA signature on the same credential and leave it up to the holder and where the holder is interacting with a verifier, which signature to use for a given presentation. So that's the sort of goal of this. Does that make sense? Yeah, I think so. So I'm wondering about the compatibility. Like, are there. Wallets that would then be able to ingest this or interact with this that wouldn't have been able to before. Yeah. So we're in parallel to this. There's an effort. A code with us that animal. Solutions is developing that adds this to both credo and, and to bifold. So we plan on using this in BC gov. And, you know, allowing others to use it as well so that, so that we can transition over to always using W3C format credentials. Compliant credentials. And there's no more. Is it a non creds? It's still going to have in a non cred signature, but the format will be W3C format. I see. Okay. Thanks. And then, and then as well as I say that does lead to this idea of a non cred signature so that where a, for example, a jurisdiction or a verifier absolutely requires that a, for instance, hardware base can be used that can be done, but where, but that allows, you know, linkability and less privacy protection. And so where that's not absolutely required, the privacy preserving credential signature can be used. Yeah. I mean, for what it's worth that, I mean, I got interested in this because ceramic is doing a similar thing where it's basically, these are all just JSON blobs and like, why can't we arrange them in a format that's compatible with W3C since that's also a JSON blob with certain rules and, and a signature. And so I'm excited to see everybody kind of standardizing on, on the actual standard and that way, you know, if they have that in the credo wallet, then somebody else who's not even in the non creds universe can like, oh, I look at this credential, they can use it. And I think that's, that's going to be kind of cool. Yeah. Great. Thank you. Any other questions? And yeah, I think I guess you've got it up on the screen, Kenny, as far as just, you know, what it is you need to do to use it is just in, there's a demo there. Excellent. Yeah. So we totally welcome any thoughts as you were preparing for the final merging. We should be getting approval and merging within, we said by March 15th, I think. So that's the goal. And we'll be working with people's group more. Excellent. Hey, all right. Thank you. Thanks very much. Any other questions or comments? All right. Hey, I picked the right screen again. I think you're seeing the, the agenda. Excellent. All right. There we go. Oh, okay. Just a slight delay. I got it. We're actually two screen chairs running for a second there. Interesting. I just grabbed it even without waiting, but we're good. Okay. Good. Okay. Presentation. So updates on various things and on credits RS is Jamie here. Yes. Jamie, you want to give us updates? I believe endorser is done. Yeah, it should be. All integration tests are working for endorsement and running on PRs. And it, yeah. So I think that should be done. Unless something comes up and. Okay. And now we've been working on a design and then Jamie started working on an on credits RS update process. So when you want to transition to using an on credits RS. The multi tenant case had to be handled carefully. Notably. What we want is for an on credits. So we want to have an on credit. So we want to have a tenant to be able to independently update their tenant to use an on credits without having to do it in. In coordination with all of the other tenants. So we didn't want to have an acopie upgrade. Trigger the. So when you start to use the non creds RS, you have to update the rec series of records. You have to use the non creds. And. If that was done at the acopie level versus at the tenant level, then it would require updates to controllers of all of the tenants at the same time. And we didn't want to have that. Certainly in BC gov. We have. Tenants that use their own controllers independent. Implementations of controllers. And so. The process now will allow tenants to upgrade on their schedule. So there's actually a endpoint that is called. And the, the basic idea is the controller would. Ramp down their instances for a given tenant controller. Ramp up the instances with new code that uses the new endpoints for an on credits. And that new code would also call the endpoint to upgrade. So that would all be coordinated within the tenant controller. And independent of. Certain settings in acopie. Obviously there's things you can't do such as. Upgrading from an indie SDK. Tenant. If you will to. Using an on creds. RS directly. So you've got to be on ask our already. And things like that. So. That change has been done. What Jamie's been working on right now is. Making it so that credits and an on credits libraries are both loaded. Into acopie so that tenants can be using either of them. And. And that. All the. Endpoints are available. However, depending on. Which wallet type. The tenant is using whether they're using ask our or ask our an on credits. Certain endpoints will return. Will. Will just return as not available. So if you're using credits, the new endpoints will be not available. If you've transitioned to using an on credits. The old. It will be not available, but those will be. Not removed entirely, but rather. Will be on use. There will be a check and say, no, you can't use this endpoint. Given the state of your. Settings and your tenant. I think I got that all right. And Jamie's enabling that and getting that work done. Jamie, you want to give a brief update on where you are on that then. Yeah, it's pretty close. There's like a lot of work to. Well, there's a lot of work to do with the. Integration tests and. The demo, because. When you run it in a non-creds, then it has to use. The different endpoints for. Creating. Yeah. I think this. Like the schema and credit debt were already done, but now the. There'll be. Different paths for. A non-creds ratification versus normal revocation. So all that had to be. Changed, but. Yeah, I'm hoping to have a PR ready to. By today. Yeah, I saw the PR you put in you. So you've got a start of it in there, but more to do. So that's awesome. Yeah. One quick question on the revocation. Are we in the new. Version, are we a. Controller control of the revocation, like it's all handled by. I don't know, Daniel or Ian. Is that all under the covers? If you will, that's what we wanted, I believe. I believe that is true. The only thing that was like left as a question. And the implementation was whether. We needed to expose recovery processes, which I think we decided we did. Want to have some recovery mechanisms. Okay. Since that's something we've experienced in the wild before. Yeah. But like manually setting up a revocation registry or. A series of. Entries that manually doing any of that stuff has been removed and it's all just handled automatically. Okay, good. Good to hear. I had a, I answered a question on discord where somebody was outlining all the steps they were doing. As a. As a controller and I'm just like cringing because I'm just saying no, you don't have to do all that. If you miss it's done. So. Thanks. It should be pretty straightforward. Like. You have to send a different payload. But it's not like a lot different for creating schemas and credits and then the revocation endpoints. Are almost the exact, or I think they are pretty much the same. For most of them. Okay. So. In theory, it should be pretty easy to change over a bit. Good. Good. Okay. Any other questions, comments on the non creds RS work. Sounds like we're getting to the end of getting to the close to the end of it. Daniel, are you back enough that I can schedule a meeting with you? Yes, I'm back enough. Okay. I really like to talk to you and perhaps. Jamie as well and anyone that's interested, let me know, but on. How one goes about implementing another. Ledger. So another VDR in acopai. With an on creds RS in place. I think you've done the most thinking about that. And so would love to have a chat about that. Some folks from Hadera are very interested in this and they want to get started. And I'd love to be able to give them some guidance on how to do that. Cool. Sounds good. All right. Excellent. Thanks. Okay. And Daniel, I saw that you've done some updates on did peer and AFJ interop. And PR 2748 just wondered where you were on that. Yeah, this is again, I've been out for a few weeks. So not a lot of movement, but I've returned to this and started poking around again. I was under the impression that handling multiple versions of a protocol by the same handlers. I was under the impression that was more further along than it actually is. So there's some catch up that needs to be done there in order to make it so we can actually handle 1.0 did exchange and 1.1 did exchange. But I think that's the last thing keeping this PR up at the moment. So I'll be digging into that. It's kind of been done before without a band, but I'm not totally happy with how that's been handled there. So I might follow suit. I might try to improve upon that a little bit. But either way, hoping to make progress and get this done and out of the way as quickly as possible. Excellent. Good. Okay. Not seeing Sheldon here. So we'll move on from that. Akif did rotation. You're getting close to that one. I saw some commits today. Yeah, just was finishing up some of the stuff from the PR comments. So this morning, just working on adding two more end points, which is to create that did appear two and four. So I think that was one of the recommendations is that right now there's no end points to actually do that outside of the did exchange create request. So I'm just pulling some of that logic into a separate endpoint that will be under did rotate. So I can share my screen. Yeah. Ian, are you listening to this? I'm a little worried you're doing the same thing. Oh, we should coordinate. Yeah. Definitely. Yeah, if there's realize you were working on that a key. Well, honest, but maybe I mean you might be doing for me on share my screen and you can share. Oh, there's a beautiful sun coming up here. It's quite bright. Yeah. So you guys can see this. You're not here. I thought he was here just I'm here. Oh, okay. You're. Oh, there you are. You're not. Yeah. So basically it would just be a post method under did rotate. There'll be another one for did peer for and the only two things that I think that is required to create the did peer is whether you have a mediation record and your current endpoint. So I was just pulling the logic out from what's been did exchange. I noticed that things are added in my query here, whereas I'm not sure I usually tend to do things through a JSON body, but you guys can let me know if that's the right way to do things, but. Yeah. There is the setting. There is the setting emit did peer to and did peer for. That's right. Wouldn't we use that. Um, I think that's still all embedded in part of the did exchange logic. So you still have to add things in order for it to create the to call the create method. Yeah, so Steven. The stuff that I'm working on is related to using the did peer to and did peer for and invitations and connections. Yeah, so I don't think there's overlap right now. So. So what the, what the, what the stuff I'm working on it will create a did peer to or did peer for for the invitation based on the setting. And then reuse the, if there's an existing did peer to or did peer for it'll reuse it. And then I've been testing that with connection reuse and blah, blah, blah. The other piece that I talked about working on that I haven't started yet is the ability to actually create did peer to and did peer for independently through the wallet create did. But I haven't, I didn't touch that yet because I was running into the same issues that Akif was just talking about where you need a bunch of extra information that needs to go into the dead. So, yeah. So I think Akif and I should probably just touch base. Yeah. You know, we're not stepping on each other's toes, but I don't, I don't think there's overlap right now. It's just potentially we're touching the same code. Good. Yeah. I'm just wondering if the create should be what you're using a key for rather than putting one under rotate that's. Yeah, I was just kind of thinking about that so this could actually be under the wallet method or sorry wallet endpoint so it should actually be maybe slash did peer to slash create and then did peer for slash create so it can be under here. Well, you wouldn't, you wouldn't need to separate end points because you can, you can just put the method specified in the Jason body and the did create. Yeah. Yeah, okay, we can we can do that and maybe so I can I can maybe stop the work on that it was kind of just minimal work that I was doing this morning but the other thing that we talked about was having as part of did rotate is you need to specify the did to rotate to but the possibility of down the road adding like sort of all in one method that does the did creation and does the calls the rotate in one step so right now it would be a two step method. But I think for the purposes of getting this done I don't know if we would add that right now. Okay. But yeah, yeah. Yeah, so this is just a general concern. It can wait until after a Keith is done talking here but about did peer to okay. Sometime last week is brought to my attention that the service endpoints for I don't remember which agent it was maybe this is something that needs to be brought up in the areas discussion. But some of the service endpoints being generated their type was did calm communication rather than. Yeah, did calm messaging instead of did communication. But there's a difference there in that did communication has a string for service endpoint and did calm communication is supposed to have a JSON object as its service endpoint. Well, it's did calm messaging is supposed to be or is geared I guess more towards did calm v2 rather than v1 and vice versa so just something that was brought up to my attention that I thought I should raise here. Do you have the definitive what it should be. It's so both did communication and did calm messaging have the except field inside of the accepted parameters of that service type. And you can specify whether you want to do did calm v2 with either one of those service types. The main difference between the two is that they're expected to be structured differently. You have the routing keys and recipient keys nested at the same level as the type attribute, whereas in did calm messaging it's nested inside of an object inside of the service endpoint attribute. So it's, as long as you're consistent with your, your structure of the service object itself. You can use either one for either did calm v1 or v2. But it was brought to my attention that the did calm messaging was using a in one of the agents somewhere was using a string rather than an object which was supposed to use. Yeah, as far as I'm aware. As far as I'm aware occupy is is using exclusively did communication for the service objects that it's creating. So where did come messaging is being seen. I suspect that's probably in a fj or credo that we should be looking at for some scrutiny there, I guess. And, and it did communication remind me is it a Jase a string or Jason. For that one, the service endpoint is expected to be a string. Okay. Okay. Thank you for popping in there with the more definitive information day. Okay. Thanks for bringing that up. Let's take a look and did messaging it did I get the string right there. It's that did calm messaging and camel casing. I just typed it in the chat for clarity. Okay. Thanks. I could see the chat because it's so bright in here what a son. Thank you. Okay. All right. Any other comments on did rotation sounds like we've got some coordination to do, but it should be fine. And Ian and a key for work it out and let others know Daniel's looking at the did rotation as well. So you'll have a hand in that one. Yeah, I just, I just want to, I guess so for the updating the wallet met the end point. Because creating a did peer to requires a few extra things. I think that would have to be refactored a bit. So if everyone's okay with that. But just, um, I would only only affect it if you're making a did peer to two or four. Yeah. Two or four. Yeah. I think that's additional features. Right. I think the wallet end points have been overly focused on like did sovereign did key creation so far. So the options are rigidly defined. For what is required to create a did software that key type did. So I think as we, as we support more did methods. The requirements for each did method is going to be quite specific. So I think it makes sense for that options to either be arbitrary. You can specify anything you need. And then the method that you define processes, those options and complains if there's issues with, you know, missing options or anything like that. At the end point level, we just accept an arbitrary objects of options. Okay. I think, I think that makes sense for now. And then down the road, we can continue to generalize it further. So I think that makes that makes it easy to get this implemented. Excellent. Okay. And then the last thing I wanted to touch on. Implementation work that's going on is did RPC or sorry, did com RPC the RPC. Just the lessons learned, Akif and, and what, what is added. Yeah, so that was also me. So the lessons learned was at the time of the initial, the way that our RFC was written is problem reports and acknowledgments were not required and I still we don't need acknowledgement messages from based on the experience of implementing this. But what we did come across is if there was issues with the agent to agent messaging the, the requesting agent doesn't have a sort of context of if anything goes wrong and why it went wrong. So we thought that maybe it might be best for the responding agent to actually send a problem report if there is an issue processing the incoming request at the agent level. And then that would further just complete the transaction. So yeah, I think we just added a little piece in the RFC that a problem report should be could be sent by the responder. Yeah. With that being said, from what I've been told is that the DRPC implementation is working both in Akipai and Credo. So for the intended use cases that the BC wallet team is using it, for example, they seems like it's working well. Yeah. Excellent. Yeah, so Daniel not application layers but just messaging layers at the application layer of the API returns validation errors. But if by chance you pass through the validation and you send some kind of bad message or something that the other agent can understand. Seaborr not Jason. Sorry. You said more instead of Jason. Right. Yeah, you're just basically what you're what you're saying they're Daniels. Yeah. Messaging layer errors. Okay, excellent. All right. We have an RC one Akipai RC one. Are we ready to go with a RC to I think my plan was that did rotation. And ideally the reuse so the two things that are active and close to completion would be included in 012 0. Thinking we could do an RC to I sorry I didn't get a chance to create a query that would show where what's what's in RC to So, you know, or sorry what's in main that is not in RC one. I probably should have had that ready to go. Hang on one sec. Open merged interesting. There we go. So there's RC one there. I've done a bunch of things on the GitHub pages so that's irrelevant to the rest of the world. We've got a non creds things. One of the main things was the problem with the revocation notification this one. Yeah, that's this one. Yeah. Which was causing issues in. Yeah, so I think we will probably will I'll do an RC to just for that one. But I think we're holding off on on finalizing 012 0 for did rotation and fear did and reuse. I think those things should be all part of 012. We good with that. Yeah, we definitely want this almost know. Sorry, we just definitely don't want any of this non credits upgrade stuff in 12. Okay. Okay. Status of 1.0 I don't know that we need to spend a lot of time on that. It's going to follow 12 fairly closely I think the non credits piece will be will be it with the upgrades. And, you know, people will be able to use it still with prior but but the goal will be upgrading to the ledger agnostic and on creds and be able to use that with a bunch of other ledgers. DRPC was added directly into credo. It is in the main branch, but I'm not sure whether it's going into 050 or not. So, in response Jose to your question I'm not exactly sure where it would be that would have to talk. Yeah discord message on on open wallet would probably help with that. All right. I think we've covered PRs. I don't know if there's any issues that we want to go over. So we're probably done. If there's any other topics people want to bring up. I actually did have a couple of issues that I opened up that might be worth calling out real fast here right here. Yeah. So, first, I'll briefly talk about the multi use invitation one. It's this is really low priority. There's just an issue with emitting the key list update web hook. We can probably push that off. It's not really here on fire. The next one though that did pure respond in kind behavior behaving quite strangely. So, when using a multi use invitation. And having somebody perform a request through that multi use invitation with a did peer to or did peer for for some reason that I do not understand yet. ACPA is still creating an unqualified did, but instead of including the did document and they did doc attach it's doing it did rotate attach. So it's this weird mixture of two different routes through through the protocol. Okay, so this is quite broken at the moment. I need some attention. Okay, this one's really high priority then. Yeah. Okay. Are you able to take that or do we need to find somebody else to this. I can take a look at that one because I think it's going to be the same codes that I'm working on right now. Yeah, you're probably right. Okay. If you don't mind, I'm going to attach your name to it. Thanks Ian. Take a look at it. Yeah, I'll take a look. Okay. Well, that didn't work. Sorry. That worked. All right. Any other ones you wanted to highlight or anyone wants to highlight. We've got the upgrade the two wallets concurrently so recent ones. I did have this one. Daniel I don't know if you want to take a look at this one at all but this is the running the generate open eye which I run when we do a release. I got an error on fail to start. It has to do with permissions and agent log. Aha. I just realized that. All right, I suspect we've seen this before this has to do with the multi multi log. The multi tenant logging change that was made I'm sure. I could certainly take a look. It looks like you were able to work around it though, right? It's probably honestly not required for us to have any logging going on for the open API generation. It just spins up and occupy instance in order to. Oh, I know that. Yeah. So we can probably just remove that line and just call that good. But there is no logging going on. Doesn't occupy have to be running in order to generate the open API. And so then this isn't then the script didn't work. Yeah, I think the script needs adjustment but it's it's a matter of over specifying. Oh, I was able to fix this by removing the log item. That's right. Yeah. Yeah. Yeah. Yeah. Okay. I can probably fix that. I should have realized. So I did realize what was going on. Okay. Sorry about that. It was a while ago. Okay. Log file. I just have to find where that is. I'll take a look. Okay. Oh yeah, there is a fun one here. And again, not a hair on fire one at all, but there's certain places. So we use doc strings to generate internal documentation. And when people put in comments that are documentation doc strings, sometimes they structure the data such that we get errors in generating the documentation. And so there's a handful of places right now where those errors are coming up. So at some point, somebody will take a look at that, but it's pretty low priority. There are some recent one recent ones. Yeah, I think that should cover other than that people are working on some of the other ones I just noticed the one Daniel's working on, for example, the Accompany credo did exchange. So, Sounds good. The poll requests we're getting down to eliminating the last of them. Obviously, we've talked about these ones that to concurrently did rotate. The new format was what we demoed early. The please acts will go away once the, the areas are FC is merged. And then these last three, I'm, I don't know what we'll ever do with those Daniel. I'm hoping you can tell me. Probably end up closing. Yeah, to be honest. Yeah. Yeah. All right. I had any other questions. Oh yeah. Yeah. Yeah, one more issue that was opened a few weeks ago. There was some back and forth on it and then there hasn't been any, any further chatter on it, but it seems like it might be something we will want to do is a 2781 the lack of user agent header one. I don't suppose anybody's heard any movement from the anatomy folks on this. It seems like they have a fix. Maybe all we need to do is just encourage them to open a PR. Yeah. But yeah, this one seemed like a This is preventing occupy from being used in certain environments, which isn't ideal, of course, AWS especially is picky about which user agents it permits. Definitely not ideal. Yeah, okay. And so is cloud player. So I remember doing some Python stuff and the Python was getting blocked because cloud player was like, oh, you might be some sort of bot network. Yeah. Sorry, I'll finish this off in a moment. No need to wait for this. Okay. All right. Any other comments to wrap up. Thanks, Daniel. And I'll I'll try to set up a meeting a little later this week to talk over the how to do a registry had era folks are really anxious for it. So I'd really like to help out, but I don't have an answer of what that is. So I'd like to coordinate something. All right. Thanks all for joining. Yeah, thank you. And with that, we'll wrap up the meeting. Thanks for the demo. Golden team. Kenny and team. And we'll see you in a couple of weeks. Take care all