 Good afternoon everyone. Morning. Yeah, morning or evening or whatever where you are located, wherever we are. Is that is the areas framework. Setting up an agent initiative and credentials. Is that done by Indico or is that someone else. The thing that's happening like next week. You mean the workshop. Yeah, yeah. It's done by Ariel Karim and beer and so. Two from us at animal and then Ariel. Also does it. Yeah, I certainly won't be able to attend because I'm on vacation next week. But I think. Yeah, with spirit Karim and Ariel the workshop should be in good hands. I think we can get started. Okay, thank you for making recording. It is. All right, so. Welcome everyone to the Arizona jazz group called July. Six. Yeah, I need to remind you to abide by the high-pitched code of conduct and entity trust policy. You like the edge yourself to the tennis list for free to do so. I posted the link in the chat. Anyone new here that would like to introduce themselves. I think. Yeah. Okay. So for today, I don't have a lot on the agenda. So we can see if there's issues or PRs or things people would like to discuss and otherwise we can keep it short today. And I think it's also more vacation period and yeah, it's been less going on last week, but I know I saw some work on the did conflict to stuff and Ariel had left a lot of comments on issues and stuff. So maybe we can cover some of those. Are there any status updates was the Bible call this week. Yes. We didn't have a lot of new things, but a couple of things that I will mention is we're making some changes to the scanning flow. And there's some conversations around go codes. And I don't know if there's a potential opportunity for some of those go codes logic move to FJ. We're introducing the idea or the cons new concept of femoral connections or connection gets deleted when a transaction or operation is completed. The main driving force for that is the cure code density. Make that is smaller. When you were using connectionless for request. And I also thought that the areas community called there are some code about some talk about the pier did upgrade to feed did come. We did the two of three. I've added an issue to airs framework JavaScript. I feel like the, the one of the frameworks to, to implement those upgrades and not about a kind of a month framework timeframe, but they were asking what is the timeframe possible. And we say one month a month. We were not sure, but, but yeah, yeah, I think it's if I'm not wrong, it's, it should not be so complicated to add it this to a FJ right. What do you, what do you think. I, yeah, I just created that issue there so I don't forget but yeah there's not a lot of details so someone who understands more than me please update. Yeah, is this anyone willing to pick this up in the coming months. Yeah, maybe, maybe I can, I can do it but I will have to study a little bit how it works. Yeah, yeah. I can help you with the implementation or like guide you if you have questions. Cool. Yeah, and for the, a formal connection like make your code smaller. Have you considered using shortened URLs. Yes, we do not want to use certain URL service for. Possibility of some privacy concerns around it, whatever service is using now have the ability of track. Again, I piece and know what is happening. So the shortening URL was we decided not to pursue that side. And you'll be another piece of infrastructure that I need to be maintained and supported. Yeah, okay. Yeah, no I think. Because when you like you connect to the HP endpoint of the issuer or like the inviter anyway so fetching a document from their servers I would say doesn't make tracking more possible because you already are connecting to their servers and domain for creating the connection. And we have in cases just integrated directly into the agent so the agent receives the connection request it also handles the. It handles the like the URL shortener I think, in a lot of cases you probably want to separate it but I think for easy deployment. Yeah, I think that has worked for us also quite well. Sorry, I don't understand the suggestion and so you're saying agent is in charge of the real shortening. The sure verifier. Well noted the creator of the invitation. This is a mobile wallet so they don't have a HP server. So we need to stand up like a mediator service something on the side. Okay, yeah. So if you have a mediator. There is a, an RSRC I wrote specifically for this and this is how I did it when I wanted to create invitations on device that were shortened is Is it in here. I can't find it. If you, if you are talking about your shortener protocol, it did come. Yeah, okay. Short. Here, yeah. So, this is a RSRC I wrote where you can use another agent to shorten it for you. And in our case, we used it with a mediator so the mediator, you need to contact mediator anyway to register the key, but you also can request the mediator to shorten the URL for you and then you get back like a shortened URL which the mediator then holds for you and there's like a requested validity seconds. This does add some like tracking possibilities, but you are already sending the key to to the mediator and when the other device wants to send a message to your device, it has to connect with their device to the mediator anyway so Yeah, still, all the connections between the servers are already made because the other device is already connecting to your devices mediator so having that having it resolve a another object from it I think doesn't introduce too much new things, but yet maybe something to consider. I'll look into that one. Thank you. And agenda. Does anyone have anything specific for the gender they would like to discuss. I think I think it would be nice to review some issues and PR just to because there are some PRs that are open for a long time, like for instance the one for revocation so maybe we can try to move forward or discard some of them. I don't know. Yeah. I think we can start with some ones that are really open really long. This PR, yeah, February 9 already to add concurrency conflict for process messages concurrently. I think the changes were quite simple. Instead of like waiting for the previous message to be processed we we allow them to be processed concurrently if you add this config parameter. It seems, I think. Yeah. Do we think they should be merged or I'm a bit out of like what it was specifically about. Yeah. Maybe we will, we will need to review it or just to see what what's missing there. Yeah. Okay. Anyone want to take them down. I will, I will, I will do a review. Yeah, I can also do it otherwise you don't have to pick pick them up. All of them. Okay, I'll take it. You can take the next one. Okay. Out of band proof proposal. Good addition. I think. Yeah, I think we also need to look into the transparency and see exactly what the concerns were with this PR. Yeah okay I think the problem is that we look without connection ID which in some cases we shouldn't do which I think can lead to issues if I send you a message with for specific threat ID I can like hijack a exchange I think. I wanted to keep this on hold until we have like properly integrated connectionless with out of band which we've never done. So maybe we can merge this with with some small tweaks. I think. All right. I can also pick this one of them. I think I left left comments on both of these. Okay. Yeah, this is I think on hold because the presentation exchange work is on hold. We have been integrating with it. But there were issues in the packs library that really prevented it from being integrated. I think. Once those are dressed I think they're currently being worked on in the in the presentation exchange library. We can integrate it and then we can also integrate this. Yeah, so I think we can keep it open for a while now so we don't lose the. The thing. Yeah, we don't lose the, I think it would be a good test to add. Okay. This one. And yeah, a lot of good changes in here. I think we need to update it to integrate with some of the latest runner updates. And yeah, so yeah, I'm not sure if anchors still going to pick this up so maybe. Yeah, we need to take it over and get it merged because I think there are a lot of good things in here like things that are going to break soon if we don't merge this and it updates it to all the latest versions. If we if we can add commits there I maybe I can, I can pick them up pick them up and. And just do it on the branch and. Okay, yeah, that I think can we. It's from checked you can push to organization things so you would need to fork their PR. Yeah, okay. Okay, yeah, it will be just a matter of asking anchor to accept the PR and let's see. Yeah. Okay. Okay. This one is open I just never finished it I don't. Yeah, I. I wanted to add a role to the credential improve records because it's sometimes very hard to determine which role belongs to a record, especially if they're in state dawn or like whatever state. But I just didn't finish it so something I'll have to pick up at some point. This one. Yeah, so using a multi use invitation multiple times. So I already connect received a multi use invitation and I want to use it again. The change being made here is to remove the check. I have already connected to this ID, and that allows it to just like create another out of vent record for ID. My concern with this approach was that as I understand it that these need to be like message IDs need to be unique within the context of an agent. And this breaks that model, because we basically have multiple out of vent records with the same ID then, which can get tricky. So I think if we want to reuse the same invitation multiple times we need to think about it like okay what's the impact of that or the implications. Yeah, I know Ariel you had done some research into this the last time right or. Yes, I think the only the only issue would be on the mediation recipient or module, because if you have this an invite or something like that. It will, it will try to to find a single connection from that invitation so it would break as you, as you say. But if we change the logic there. It should not have any, any particular issue I mean, according to what I understood, nothing from this from the spec are is preventing to have to two connections made or start bootstrap it from the same invitation. So basically, it's not incorrect to, to, to remove this check. And also, sometimes was something that that happens to me sometimes in our app is that you scan a QR code with an invitation. And if you are not connected to internet or you have a problem. You will have an error and, and, and if you if you are going to scan the same QR again you you have to make sure that delete the autofund record that has been created for that. Because otherwise the framework will reject. It will not allow you to to to to receive again this invitation I mean to with the same QR code so you will need to ask the other party to create a new QR code. And sometimes it's something that it's not so I know it. If you don't manually delete the autofund record, you will have several records that they are not used but I don't know. I think it should. But to have this, this, this change in the framework. But as I said, we will need to also modify the initialization of the mediation module because it will fail. If we, if we have more than one invitation, please show once wants to say something. I have a question over something that you say that when you delete a connection that have been records to remain so they're separate. I think so yes. Yeah. Okay, so we just probably to make some changes in by phone that so deleting a contact. Is it recommended to delete both the connection and out of band record should be fully removed. It depends on as a holder, probably yes. Because you as a holder probably yes because there's always a single connection type to an out of band record. But as like or like if you are the creator of a multi-use invitation, for example, you can have one out of band record with thousands of connections. And it could be that you remove one connection, but you don't want to remove all the other connections or the out of band invitation like new people can still connect to it. So in that case, no, but in in like the case of like I created the single use invitation, or I received a single use invitation or like received an invitation then it makes sense to also remove the out of band record. Okay. Is there anything on the flag or when deleting a connection or those are two separate steps separate steps because you can also have I can receive out of band invitations and reuse connections so that could actually be like a lot of out of band records also connected to a connection itself. So we could add some logic to remove associated connection records but it gets a bit complicated, I think. I just think we probably need to clean that up again from a mobile holder point of view, the user experiences they're think they're deleting their contact. So therefore everything should be gone. And it sounds like this out of band records is staying around left over somehow. Okay. Yeah, I mean, there's something to say to just remove the out of band record directly after you've created connection because you don't need it anymore. And so maybe that's also something we should advertise more. Alright, so upon completing the connection the out of band record can be purged as well. There's no need to keep them around. Unless, does it, if there is a, if there is any, if there is a multi use connection or not the out of band that call for a reuse connection, do you need that original out of band invitation. No, only, only if you create a multi use invitation. The multi use invitation will become invalid if you delete the out of band record because basically the out of band record is the multi use invitation. Yeah, if you're the one creating the invitation as a get it but if you're the one consuming the invitation then it's relevant. Yeah, then it can be removed. Okay, thank you. Which brings your question. Do you know if there's any plan for FJ to maybe create a API docs is in addition to the guides that already exists which are pretty good. Yeah, yeah, it's on the plan but like not something we have had spent time on or like I'm not sure if we have time to spend on it in the near future I think. Okay, thank you. I think we all hijacked as a conversation a little bit. No problem. So yeah, I think we can, we can. It would be good to remove this check but also about we will need to make sure that that the mediation module is probably updated. It is. What you call the trick Patrick can pick it up. Can you address this area or. Yeah, no problem. It should be a quick action. Sounds good. This one. Yeah, I think. Big PR. And I address most or all of the, the feedback you, you gave in May, I think. And there are still some questions, I think. But it would be nice if you can, if you can look at them. And I think you, you started doing a review when, when we were at the dice in three, three, but you didn't finish it. I think. Yeah, so I think I finished it. So I think. Okay, so if you, if you consider it finished maybe I can, I can do those small modifications and. Yeah, we can probably continue like that. I mean, it, we will be using only this manual way of our external way of handling the indexes and that stuff. And maybe in a future we can incorporate some automatic stuff in the in the framework if needed. And does it introduce any breaking changes besides to the interface of the. No, no, the only issue is that if you have. You don't have a registry and I don't get it in implementation you will have to update it because now you are required to, to also support these methods or include the method methods for revocation registry definition. Yeah. Right there before. I think we made that experimental right so that it can have breaking changes. You see, I made a PR for that right. Or it's probably this one. And so it's the Anacrylate for us module. Oscar. EBS checks to do to see credentials service. So I didn't add one to implementing your own registry, I think, or maybe on the guide. Okay, so I added it here. So I'm not sure. Oh, and it's also added. Okay, okay. Okay, so that's fine. Yeah. Cool. Okay. This one is a book I fixed to make the document loader work in note 18. But the CI now fills. So something I have to look into. Okay. This one is accepted and ready to merge. So, I think it's just a simple fix to take the role property into accounting in the request. We actually got something merge today. This PR experience still here. Yeah, it is. Oh, he, he left as soon as we started with the PR review. So, so maybe he's waiting to that. Yeah. All right, so we have actually incorporated these changes from this PR in a in the wallet we built ourselves but there is like it's dependent on a. PR that is in here. That we're also using and I think, yeah, so we need to wait for this to be really work so I can look into this again and try to get this merged. Then this one. Artem is on the call today. Let me see. So this splits up the demo into two cases. Yeah, cool. Maine and did comfy too. I think, yeah, we took a really long time to review this PR. I left a comment. Yeah, so I left a comment that I think it would be easier maybe if we can keep the same demo and then have Yeah, just adds like different features to it so did comfy one did comfy to so that you don't have to run completely different demos for different cases. Yeah, but what do people think of it and now for our to be of any comments on this PR or Hello everyone as I replied the intention was speaking the demo into parts it's like there are some models which are optional. For example, in the wallet and a scar wallet and you cannot just integrate both in the single demo. And in order to demonstrate this capability we need to create separate demos and similar for ledgers. And this is why I decided to split the common one and come with to also inter independent demos so in the future we can create new demos easily. Yeah. I think I'm fine in general with splitting it up I think it's just like if we can prevent by maybe adding like just if you add a feature that's only available and in some demo we say like this is not supported with in the SK or or something and it's always hard to decide I think where to split demos, because if you're, are you going to do it on this conversions or are you going to do it then on credential formats or exchange layers that converse open ID and, and then you get a lot of different demos that. Yeah, maybe hard to do but yeah, I think I'm fine with it. I don't know if anyone else has comments on this. I think I think it's the approach exposed by Artemis is okay. My only concern but which is not related to items work is actually because I don't know if you have seen that I have reviewed the problems on the D on the demo. In general, and it seems the demo as it is right now, it's not working fine. I think it's related to the problem that we have on the performance for ref nappy. Because you will need to patch the ref nappy in order to make it work properly. So, because I tried to run the demo, following the steps we, we say in the read me. And if we, I mean, if we do the repo clone and the young install and that stuff. We will not patch the ref nappy, because this is something something that is working only on CI automatically. So, it will work very slowly and, well, you will have those, those problems of timeouts and what has been reported sometime ago with this guys. Your suggestion I think was to move the demo to another repo. So, yeah, maybe, maybe if we are having more and more subsets of testing of demos, maybe we can do something specific or specific repo for demos and to show different flows and lectures and maybe we can do something like that in the future. Yeah, I think having a separate demo repo for the demo or maybe some example flows and that kind of stuff I think that. I think that's good, because then we can really simplify the whole setup you also have to do for the demo I don't have to need to have all the complex dependencies. And the issues we have here, and then we can just make the demo repository note 18 only. And I think yeah that would probably fix a lot of these issues. And also maybe I imagine that some people will will start from the demos to set up their projects. And if we are we are already using this ref nappy patch and that stuff. And we will not have these issues because you know, I know we we mentioned this in the on the documentation and the guides, but usually. Well, you know, we are usually people try to test the code and we will only read the documentation, they have a problem. So if we can if we can prevent them to have the problem, it will be better. Yeah, that makes sense. Okay, anyone objects to extracting the demo from this repo. Don't necessarily object. I just want to make a comment that you might also add complexity to maintain the demo. Because as the code API or a new version evolves. Now, there's an extra effort to keep that demo updated and it might be a red the case that it's already out of date for that reason but again just want to keep the risk that the demo becomes kind of afterthought, and it will just quickly become abandoned where which I've seen with other projects kind of what happens. So it depends how much you want to keep it in line with the code and, and if someone is trying maybe the main branch for AFJ, maybe it has latest features and they want to demo that one. So how they have to go back to another repository how do we keep those demo in sync with the features that are available in the main or in the features that were available in the, in a previous release, that's going to be a little bit of a challenge. Yeah, fair, fair comments. Yeah, it's kind of already like that. I mean, I don't think the demo is working for the past whole months. It probably should be hooked into the CICD or kept up with the date because, because certainly when I came to the project the first thing I did was look at the demo to try to you know get an idea of how to do stuff and there I just got a different mistake every time so it was fixed. So it was a little frustrating. Putting in another repo doesn't, you know, makes it a little harder to do. Yeah, maybe what's missing is that demo as you mentioned that that demo has to be CICD and tested as part of the build flow that's another test that it needs to be passed. But, but, but do you think demo that we can run the ref nappy patch if we put it into the resolutions of this package that Jason or I mean in the in the We could maybe buy like the problem is that in. I think there's a few problems. We could add it as a dependency and not with like the resolution. The problem then is that the package is published to only work with note 18 so if you try to then run yarn install in the whole repo in in in note 16 it will give I think an error or like your note engine is not compatible with this package and then it can install it. But if you were to bypass that issue. We could I think do it manually in the demo with a resolution field or something or we could just like check that if you're not in note 18, we throw an error either way, like, and we create an alias for the ref nappy package because we always use like the your patch version. I think that that should be possible but we, it would require some work and changes to the packages and how we setting something. Yeah, I do think there are some things to consider here, maybe some potential benefits with extracting it is that we currently now have to keep it up to date with every change in the repository, which is good, but if we don't do it, it's it's there's a lot more potential to break it. Well, if you extract it. And it can never be broken basically, because you always use a version of a fj. And the only thing it can is that it becomes outdated. But I'm not sure what's worse and outdated or broken demo broken broken is worse. It might have been outdated is like, oh, we don't do that anymore. We asked a question but broken is like what did I do wrong, as especially as a beginner coming in. It's hard to tell whether the error is like mine when I'm just a demo or if it's the demo itself that's airing out. Yeah, it's like, it's like the dogs right, right. It's like, if we wanted to, to have to keep the dogs in the same repo because we want to make sure that it is always up to date but it's, it is not necessarily true, because we are not running the demo on the CI CD step. So it happens what is happening right now that is, even if it's there it's it's broken. So, yeah. But yeah, I totally understand what what what what Glacier says it's true that we will need to, to keep an eye on other repo as well so yeah, it will be a little bit more of work but I think it's a good trade off. I mean, I know when when we make like a new big release also need to update the dogs at migration guides to the documentation website so I think updating the demo. It's probably not that much work. And then we would have at least a stable demo that doesn't break with every commit because I think running it in CI is quite complex because it's a CLI tool. So then we would have to write test for a CLI and interactive CLI kind of interface, which I'm not sure is worth the complexity. Makes sense. Okay, so. Yeah, I would then propose still to, yeah, extract it. And that we update it for like because it shouldn't even break between like zero or four one zero or four two so it should only break whenever. A, a breaking change release is made, which is like not often currently is this this can now be just a comment. Okay. Then cool anyone that would like to pick up this issue. Okay, and run out at this one here. And then someone can pick it up. We have the time. Let me see any PRs we haven't discussed yet. We discussed this one. Oh, wait, we didn't finish this one. But I think. Okay. Then I think we can get this merged. Can you resolve the conflicts, Artem? Oh, thank you. No, not this one, this one. Any comments on this one do we need to discuss anything about this PR. Yeah, well, I, I, I did a branch to address this. This what we discussed last week. And maybe you can open open there this link. You will see the changes. So, what I don't like about this approach is that we are. I mean, the code is quite straightforward to read and to, I mean, it's just a few lines of code. But what I don't like is that we are, we are, we are having the non credit API. And it's config as a dependency of the services. It's not something that I mean, it's not something natural, I will say, right. And also, the, I, I think that it's, it would be more straightforward to, if, if we can have this, this auto create link secret configuration as a configuration of the of our non credits a race or in the SDK directly. So in that, in that way, we will not be dependent on the, on the non credits module, but only on our own configuration, because we are using a config parameter from our non credits from another module. So, if, if our non credits module config is say something and we are, it's up to us to, to implement it or not. No, no one will force us to, to do what the config. The non credits module config says, I mean, we, if we, if we create another implementation of a non credits. I don't know, I don't get anything C, C++, I don't know. And we create another module. And we are not following this. I don't think it's out in secret parameter. Nobody will know about that. So, I don't know. Yeah, I think it form a user perspective I would say it makes more sense to have it in the honor credits module. Do you also think that's or I, for me, it will be the same because we will need to. To instance, both an uncrest module and an uncrest errors module. So, using the configuration in one or another, it will something that will be always. It will be on this on the same constructor in the end. Yeah. Yeah. I think the default value is true. So probably most people won't have to deal with this config option ever. Anyone has an opinion on this I see we're over time so anyone has like strong objection or like agreement for either of the two. Yeah, but again, we identified this is really, I don't think we're to opinion where the need to just you go it's just a matter of should be work out of the box. But if you have any orientation guidance yeah please provide as a comment and I can talk to Jason about it. Okay. I think, yeah. Both are fine for me so I think your approach is good to me as well. Okay. Let's. Well, yeah, we're out of time. I think we almost got to all of the PRs. Except for the. The memory creation. It's a very simple one. It's okay. It's just to to fix the issue that Charles found some time ago, that we cannot use the in memory wallet for Oscar. Okay, I'll take a look at it and review it. Okay. Perfect. All right, thanks everyone for joining today, and I'll see you or I'm at a vacation next week. So, yeah, I'll post in this court maybe somebody else will take over but I think we'll just cancel for next week because there's like less going on these these weeks, either way so that we can just skip the meeting for a week. All right. Thanks everyone. See you later. Bye bye.