 Hello. Hello. Seems like we're having a small group today. I think the whole, the whole, it's, it's King's day here. So we're setting the rating the King, which means it's a national holiday. So in the, in the Netherlands. It's a, it's a day off. See, right. I think we can just get started. Maybe we have a light agenda for today is we have a small group and I don't know if there's a lot to discuss but let's just dive in and then. Yeah, we'll see what happens. So welcome everyone to the AFJ one group called April 27. I need to remember you to abide by the high blood code of conduct and antitrust policy. Anyone new here today I think Alexander, have you been at the AFJ club for? Yeah, yeah, I'm from the user. Okay, cool. Yeah, I knew there were Alexander's but I, I didn't. You multiple your last name. So it's hard to tell which, which one is which. Yeah, I think our last names are virtually the same for you guys. Okay. So, for today, we can do some status updates. Yeah, is there anything anyone wants to report on from these things. I think I have a question about shared migration. This is by fault migration to shared components or request. So yeah, and the question is that I actually cloned this branch done some testing. And also I'm wondering. So in areas by fault recently community added verify verify capabilities. And as far as I saw the most of the implementation depends on in the SDK, or at least its API. So, do we expect some issues with migrating this functionality to shared components or everything should be fine. I think it should be fine I've been working on it today, because I was pulling in Maine and there were a lot of things changed. But I updated all I haven't been able to test it yet, but I have like a version working version of main that runs and can receive credential I haven't fully been able to test out the verify capability so I just like fixed the code, because I didn't have two devices at hand. So I think it should just work fine there were some imports from like the in the SDK in the SDK reignitive, but that we're mostly types and I just updated those two types from other packages now. Yeah, got it thanks so yeah it seems that the PA is compatible so yeah, I was just wondering about that. I generalized it a bit because it was focused on indy and now we just have like on credits. So, it should also work with the like the new on credits stuff in addition to the indy stuff. Yeah, great sounds great. And actually I don't know if you guys know, so I'm wondering what is the minimal support version for shared components for iOS. For example, I just tried to create a bundle with these packages and it seems that info files to not have this information and I checked it in bundles says something like 16.2. I see button. Yeah, so I just got some errors with bundling this build targeting is 12. So I'm just wondering, does anybody tried it before me to bundle some application. So at some point and set it to 12 but we have like the three shared component libraries and it's sometimes like updating a Rust version or something can certainly break stuff. So, yeah, we would need to look into it again, maybe if you can open an issue in in like the repos of what's happening in which version. We can try to to fix that it has worked in 12 at some points. Yeah, it actually works in development build so if I just run the app locally on the device. It's runs without issues but if I just trying to create a bundle and validate it. It says that all shared libraries so and uncreate areas as car and in dvdr. It just says that they do not support my target version which is 12. Well, I just need to investigate further I think. And yeah if I generalize some info I will just create an issue then. Great, yeah. Yeah, it's been a while since we tested it so that would be good. Does it mention like which version it does support or no actually no. The first thing that Xcode was complaining about no minimal OS version specified in in for police files. But yeah, after I added it, it was not resolved and it seems that somehow in bundles itself. It just says to me that it requires 16.2 version. I can test it with 16.2. For example, after the call I, I think I will do that. And if I get some more clear understanding what's going on yeah I will create an issue. Does the CI clay show does the CI of by fault builds the app for production or I think there was something set up like that right or actually let me double check quickly I don't remember if it build a debug release or it was a production release. Okay, yeah. That would be interesting to know because I think then that should also break if it makes a production build. I do know we had like there was a small issue in by fault. Where I think the target in by fault is set to iOS 10 currently, and this mentions 12 but actually it throw it like it gives a warning that hey, your dependencies have iOS 12. But it runs fine. I think that's the case in my situation to because build itself is successful, but validations that, for example, Xcode does to sign the bundle, for example to upload it for the test flight and so on. But validation says that there is an issue with specification of versions maybe maybe in runtime, it's all fine at all. But yeah, maybe it's specific problem with Apple validation. Okay, yeah, would be good to look into I think we're we're not really using any fancy things in any of these rappers. So, yeah, should be able to support. Thanks. Yeah, and maybe another issue that I saw recently. So I was trying to install, for example, areas as car package for Node.js on Windows. And it seems that it just tries to download binary from GitHub releases. And in GitHub releases, it has a name something like Windows x86 64. But in runtime, when it tries to do install, it takes platform name from node and platform name for node is actually win win 32 not for Windows, and it says not found in this case. Yeah, so we have this. We don't have like an, like we only have an x86 build for Windows. Are you on x86? No, I actually on x64. But I think the problem is platform name, not architecture. We have it. Because I think that the one when no, the arch script, my thing, you remember, expects, I think windows. Yeah, I mean, it takes the platform name from Node.js and it seems that Node.js is returning win 32 instead of Windows. Exactly. So maybe we can, we can, yeah, we can either change the script or change the name of the file of the artifact we are generating in Ascar. So instead of calling it Ascar windows x86, we can just call it Ascar win 32, I don't know. Yeah, exactly. So for example, to install this on Windows, I need to go to packages on and manually change binary name to Windows, and then it works without any issues. Yeah. So, binary uploaded to GitHub release for Windows has And this means it can download it when you install this package for Node.js on Windows. Is this also the case for like Eris Ascar or like IndividuR and AnuKratz RS? I think only for two of them. Okay. Yeah, I think maybe for IndividuR too, maybe I just haven't installed it in my project. Yeah, probably yes. So these are similar, so I think it's highly likely. Let me see releases, where's releases? It's the tags. So we have probably this will have the same issue. And if we look at IndividuR, then we have. Okay, yeah, so it seems that it's probably the case for all of them. Yeah, it doesn't make sense for me to create an issue in every report. It's not really needed. Yeah, I can create this issue and I think we can just reuse that for all of them. I think it's quite an easy fix. Okay, thanks. Or like, modify the script already used by Node.gib to. I think last time Berend had an opinion on how this should happen, like he would rather like keep the names in the release in a certain way and change the script, but I think both will work fine. Okay, thanks for raising this. This is like we don't really have a Windows. Yeah, I see. We don't test that every day. Okay, that's it for me. So yeah, no more questions from my side. Okay, cool. Thanks for raising. Let me add this issue to here. Cool. I can give an update on the like the status of the migration is I was working on it today. I have updated the pull request with the latest change for main and that all works. And I just ran the migration from Indie to Ascar and that also works. There's only one issue I'm running into. I think you have some thoughts on it on what would be a good way to solve it is we're, we're going into the wall, like right ahead logging. I think Ariel has also run into this but basically what the wallet does it, it like you have the SQLite database and that's a dot db file, and then you have a dot db dash wall. So I'm just testing it like to migrate it. And I noticed because I, I launched the bifold app in like the previous like the main version with AFJ zero three and in the SDK, then I filled it with a lot of like credentials and like finished exchanges just so I can test like if we migrate it can I continue with like sharing the credentials receiving the proof on and whatever, but the migration went fine but the Oscar wallet was empty while the Indie wallet wasn't. I was uploading the file like to my PC so I can like look in it and what I noticed is that the wallet, the dot db file was actually empty, it had just the key and the table structure but it was empty, and there was a dash wall file that was a lot which probably it hadn't committed yet and that's probably because if you suddenly close the app, I think it maybe doesn't get the time to save it, but it seemed like it had stored everything in the in the wall file. So, I'm not too sure what to do now because in how like the migration is implemented is it checks on startup like have we previously used in the SDK and are we now using Oscar well it knows it now using Oscar because in the latest version it will, and then it will do the migration. But that migration is done before the wallet is initialized within the SDK again because we don't have it and it makes that the wall changes don't have effect anymore because we copy the database file, then we do like the Indie to Oscar migration and then we do the AFJ storage update migration and then it's placed in a different, in a different file, or a different location where Oscar expects it. And even if we were to copy the wall file, the structure for Oscar is different so we then apply those wall updates that that that will break so somehow we need to first apply those updates to the database before you can migrate. But curious if, like, what if people have experience with this or like what I think would be a good approach here because otherwise it can mean like, now it's just that I opened it for the first time and then added a lot of credentials and I lose a lot. Like basically everything in the wallet but I think it could just mean that you may lose some data that hasn't been finalized yet. Any thoughts. My thought is that it's so hard. It's very difficult to manage because so I'm not very familiar with the Indie SDK migration script but my understanding was that the wall file is mechanism is made in a way that when you open the database it will automatically get those changes from the wall right or isn't that the case. I mean, if you, because if you open the database, suppose you copy not only the SQLite file but also the wall file into the destination directory and you open that DB. Wouldn't it take all the changes in from the wall and then you can simply do the migration from there or isn't that the case. Yeah, so yeah we are now copying the database to a new, like we're copying it to a temp file, a temp location and we don't remove the Indie SDK database so if we are going to mess something up we always have still the backup but we do the temp and then we do the migration and then we move it to its final place. But yeah maybe we can try to I hadn't thought of that that we just like also copy the wall file and then it will write it on open. What I am curious about then is like why because I added like multiple connections multiple credentials and the wall file was basically the whole database and why doesn't it commit the data until the next time I open the wallet. Yeah, I'm not an expert near that but but something that something that we should change in the in the management is the is the way we created transactions, because we are not actually using the transactions currently we are we are simply creating a new session, which is open the whole session, let's say, and we never do a specific commit before closing the wallet. So maybe that's one of the reasons why this is happening. And it usually works because because, as you say, the information is there in the wall file, and the next time we open the wallet, the commit will be automatically done by SQLite. Yeah. Yeah. Yeah. Yeah. Okay. That's, yeah, I think it's just weird that I thought it was like my issue because we're also having it with in the SDK now, which makes sense maybe because we don't really use two sections with Indy, or maybe we, we do, maybe with Indy we use like one big session or transaction, and that's the issue. Yes. Yes. Because I also in the because my understanding on how that's work is that we are doing all the rights are done on the on the wall file until a certain point, a certain amount of data, and this is mainly done in order to allow to have multiple readers on the SQLite file that that's the reason of this wall file actually because otherwise you will have the file handle locked and you wouldn't be able to access to the database from another thread. Or that's how it's supposed to be. So maybe we can, we can do, we can do transactions and commit explicitly in order to make sure that that everything is in place. Or, I don't know, or maybe we can do that before closing the wallet. Yeah. That might be something we can do that we it's just like yeah it's in a mobile environment it's quite hard to intercept the closing but I think you can probably like you can probably have like a who can like get a bit of processing after the wallet is closed right so maybe we need to do some just try like we can never be sure but like have some or like at least document how you can like hook into an event from the, the native system that the app is going to be shut down and then we close the wallet which will try with which will commit the data. Yes, yes, I think, yeah, I think, I think it's possible to do that there is an event in both. Maybe you should know more about about this but I think it's possible to catch. I don't know from react native how it works but maybe it's there is some module that hundreds that and we can we can do the closing there. They're gracefully closing there. Okay. Yeah, is there a a API call that we need to be caught. It is to be called to the FJ provides that call. I think it's the problem what's happening here is in a FJ we open the wallet and I think it apparently it will create right everything to a right to a wall file with the in the SK until the wallet is closed. That's an assumption I think but it sometimes commits it. And that way, it will be committed to the main database before you open it next time, which we may be able to like I think it's more of like you can just like if you do agent shut down on before, like, instead of like just killing the app, and you may be able to hook into that like if there's a close event that you can just call the agent shut down method which will close to wallet and stop everything. I'm just doing a quick Google search in the meantime but but everything's telling me that the the wall mode will write all the transactions including committed transaction to the wall until there is a checkpoint call to kind of a process the wall files and bring into the main database structure. So that's true. I don't know when that checkpoint there is cause done. Yeah, I think, I think that there are some configuration parameters on, for instance, in a scar we can we can send it to the SQLite engine to define when this checkpoints should should happen, but I think it's possible to force it to for the right thing. Yes. There's two things here in place. So one is one of the obviously upgrade path. The upgrade to ask her. But the other thing is how I think like your identify something that is happening that we didn't notice. Maybe when opening the wallet through through AFJ API, you should always run the checkpoint. And to before you run your migration maybe are you able to open the database run the checkpoint. And then you continue with the with the upgrades with the migration. I think that's but I think I think we can't like manually force the checkpoints I think it's just when you open the wallet, or maybe close so close an assumption but it definitely doesn't when you when you open it, then just reading the doc. So the closing connection runs a checkpoint while holding SQLite block exclusive. Yeah, okay. So a direct or explicit can close at the connection will do that but I don't think we ever do that. I think currently no but it will do that when you call close wallet I think then right because then you specifically lock the wallet and close the connection to the database. So, so the one thing that does call close wallet I think is when you turn off biometrics on and off. So maybe just a walk around maybe you can try that. Yeah, to see if like the file size changes. Yeah, yeah, and I think the other. I don't remember if when he times out it does a call a call to the close. Just leave the wallet open for a few for a few seconds it will time out. Yeah. Okay. For a few seconds or few minutes. It should be a few seconds, which is almost a minute or something like that I don't quite remember the time. Yeah. Okay, I can also check that yeah. I'll play around with it a bit with like the migration script. But at least the issue like with having issues with like decrypting the wallet is now gone so I think I just had some corrupted database then or something so yeah I'll hope to have this done and then I think this is the last thing we need for it to be fully done and actually the thing we were waiting for with releasing the next version of AFJ so then we can finally release. AFJ 040. Yeah, we can go into it. It's more in a bit. Cool. Okay, that was on bifold then anything else on bifold or the shared component stuff or. There were issues like the. How is it? Clacial with like the issues with older Android versions and the new missing symbols and stuff is any progress being made on that or. So we fix all the issues with VDR. So that one is all fixed and it's working from Android five all the way up. I think there are issues now with other library think was a known credit or ask her that we need to update the same way. Okay. So I have I have the commits in my fork on my branch. It's ready for you guys to just take over I don't know how because you already have a branch in progress I don't know. If you want to PR to your branch or you can just go and take the commits from my fork, that's fine. I think so is it like fork of the analog rats or as any VDR repose and such or. Yes, it's a fork from you guys work on that. I'll share the links and I'm a bit out of the loop on exactly what we had on this. Okay, one second. In the in the VDR there's a branch. Okay, so maybe it is. Okay, I need to double check, but I'll paste the link. This is where it is the changes. I just recently commit some changes, because I thought there was a PR from there about it. Okay, yeah. Maybe it was in his like his brain probably of his fork. Yeah, so the thing that fixed it was to use another rust version or, or some other stuff also okay. And, and do we need to apply the same patches then to an on cancer as an Oscar or not. Yeah, I think so that's a conversation we had here. And if there is potentially a way for us to create an action that we can share among all those components because we need consistency support. Yeah. This is great. Thank you. I'm going to pick this up with parents and. Yeah, so there's only those two commits. One of them, it does include GitHub action changes, because that's how I was testing, but happy to have a call and we can talk about it. How to integrate those changes. I think I fork from very fork, because there was a work in progress. That's why I didn't submit any PR but we can get some clarification there and how you want it back. Perfect. Do we think this needs to hold up the release of a j zero for zero or is that something we can release in a patch afterwards. So we won't be able to update by folk to use zero for zero until that one is done right so from areas JavaScript perspective, go ahead yes you can do a release. And we can that means the bifold we can't really pick up zero for zero we probably pick up the next one. Yeah, yeah I know it can actually be like, because it's just something in the underlying libraries. It's it's just like a patch we could release to the in the video or I don't crash for us and Oscar libraries without needing to do an update in a fj really. But okay, yeah. Yeah. The fj defines what the version of those rappers. Or does by fold has to also define and we will override is it a peer dependency. I don't quite remember the shared packages dependency. The non shared package, like the react native specific is is dependency because you can install the node jazz and the react native one. And we have like, we specified with a carrot so if we release one dot zero dot zero, and then we release one dot zero dot one, then it will pick the latest package. And that will automatically be applied then. So that should work. Okay, I do not know. So I'll take your word for it. Where have my notes gone. I changed the. Sorry, maybe. Oh, well, can we get them back or. Okay, well, um, That's, that's nice. It's in the community. If you have to like next like create, but is there not a draft sir. Where is it that data or is it. No, sorry, maybe it's in the bottom right. Okay, so those dots. Last published version or I think but I made all the edits. So, okay, let me see changes, few changes. Nope. I think this does the same as we did. Oh, yeah, never mind. Yeah, so I think. All right, that's okay I think what we need. There's a few there's just a few things we want to also copy the day but while before Oscar migration updates on older Android versions. Yeah, fix in this branch or in the video. And need to make some changes. All right, then we have this issue that was raised. All right, I think this is the most important stuff we had written down. Okay. Cool. Awesome. Then, let me see anything on the other calls. We want to discuss. Okay. So where were we left off with this cycle like bits and checkpoints thing. This bifold needs to do explicitly close in the wall or is that, is that something that the FJ is going to handle. I think that's FJ we can't really handle it easily because like it's FJ doesn't really know a lot about the reignitive environment so I think it's ready to do that in the reignitive app. But yeah, I think probably I'll look into it like with the updates and see like how it a bit more learnable bit more on how it works. I think what will probably be the fix here is that we're going to currently we create like one big session with Oscar, but it now support like transactions and everything, and well, we are going for the next FJ release we want to refactor it to have more like batched transactions. So if we process and message and in the process of it, it, it goes wrong, like we want to commit anything that happened during the processing of that message. And if it does like everything will be committed at the end and not like well so we have more. And I think that will probably fix this right ahead logging because we'll have like a lot more in between checkpoints. Okay. Okay, I guess something to keep an eye on it, because I have not noticed. Okay. Yeah. Okay. I'm wondering now now that this has been raised I'm wondering if that is causing some, some potentially startup issues delays that again, maybe that right ahead log files needs to be processing every time it's opening the wallet. Let me see. I heard that did comfy to interrupt on connected on went great. I didn't see the demo myself but I heard there were like six companies or something that were involved in it. Yeah. Yeah, it was pretty cool. The last cool part is that we are not using the culture. Yeah. That's definitely I mean PR open we need to get it fixed in a jail so okay. Yeah, so it is that coming to zero for zero is a future release future release basically we need someone to pick up the work. The end that wants to invest the time like there's a lot of it is done. But there needs to be some work to finish it off. Okay, so, so there's no one actively working on it so then. Not at the moment but my idea is to work on that in next month or so, because I would like to to to have it in our in our first launch of I mean, to launch our app with directly with the computer so I would like to implement it in for the for the let's say five zero let's say. But before before that we will have to to work a bit on the refactoring of the wallet API as discussed with team or that's weak. But it shouldn't be so hard to do that. Now, especially now we are using Oscar. We can we can mix all the concepts done here in the in the branch in a program branch from SIPA. I think that's corrected with Oscar. Okay. So yeah, so we probably don't need it right away so that time like probably works for us as well. So we'll see how we can maybe help with possible. Thank you. Okay. Then I think let's continue. With are there anything any other things we want to discuss today, I think that the discussion we had are really valuable for me at least so that's great. Maybe I have one thing. Let's look at the release. Because it's been out for a long time. And are there any things we really need to do like for me, what I wanted to get fixed was the migration script in react native. I'm working on it today. I hope I can wrap that up. And so I think maybe there needs to be one small change in AFJ that we also copy the wall file when doing the migration. Is there anything else like what was your ID for for for this Ariel, can we do that in a zero for one, or can we do that in a zero five zero or but what's the. Yeah, what's the thinking behind you. I think it's possible to do in the in a zero for one if you, if you want, yes. But there is, there is something that is, that is part of this PR that maybe can be important for the zero zero four zero is that there I integrated the support of this non how it's called the. All right, the time, the time sub all right, the time sub all right and in the, and on credits. Yeah. So, I don't know if I can, I can also probably separate that and do a smaller PR. With only that fabrication of rights and time time of rights for the week. Or we can just wait to this, to this PR. There is some why I integrated that here is that it was easier for me to test it because when I do something I want to test it, because you know this is. It's good that this is recorded. If it's not tested, it doesn't work. You see, I mean, we didn't test the Oscar in Windows, it doesn't work. So, so we, we have to test before. So, and now with this revocation support. It's easier for me to check that actually, it works and actually I had to do some, some back fixes and on the unknown credit side. So now that I know that it works maybe I can, I can separate that and include it in the in another PR if you want. Yeah, yeah. It would be good to include it, but if we can add this soon in a in a like a, yeah, probably would be good to include it. Because otherwise we're going to have like checks that will fail. Well, they're actually valid. So if we include this PR into the whole PR into the zero four zero, we will need also to update. Well, it's, it's a minor update, but we will need to update also the check interface and in the, in the video is already there. So here we, I am changing the, the issue in service interface to include also the, and the unknown registry interface to include also the register. So it's a professional, the pressure to definition and a set list. Yeah. I don't know. Yeah, probably good to you if you if you if you want if you want to do. I can I can, I have to update it to use the latest release of an on credit the rest, because I think that once it's updated to that it will work. If you want to review it and include, I mean the whole PR in the zero four zero, it's, it's fine. Otherwise, we can, we can waste, we can wait until. After the, the serial for your release and, and do it for a zero for one because actually it's not, there is not any. I think it will not any breaking change other than the fact that we added the methods for registering objects in the unknown registry interface. Yeah. Okay, but we can already add those. I think that's fine if we just add those in, and we just like do it like this, I think that's completely fine. Then we just say like it's like not revocable issue issuance of revocable credential like creating these objects is not supported yet in any of the registry implementations but it allows us to release zero for zero, but not have to make a breaking change right after I think that's fine. Okay, then I'll give this a review. Yeah, I think that I'll give the review and leave some comments. But cool. Okay. Um, so we're location PR merge for zero, but don't implement the indefinite support. Please. Okay. Anything else. Cool. Okay. Cool. I think for us like one thing we really want to fix but we're going to do that after the initial releases is like still expose support for the different shared components. Because Ariel, are you, you're using plain react native in your wallet app. Yes. Yes, we are using. Well, what's the problem with with expo. It has a different way of registering stuff so it's Yeah, there's some issue with how it loads the native code and for iOS you can bypass it by manually registering and loading it again, I think the parent has got something working there, but that doesn't work for Android and we need to make more changes. But yeah we need to look into it bit like they also completely again like changed in how it works in react native zero dot 71. We also line it more between expo and the none. So we may we thought maybe we should just like focus on the latest react native version for for this but then we lose like we drop a lot of the older supported react native versions. And yeah, or you need to support both but it's like it's kind of a mess if you also look at you have some of the open source things it's Oh, maybe. Oh yeah, that's just migrated but like basically this was like a thousand line file with like if react native zero point 66 or if zero dots 67 and then like all different behavior for all the react native versions which is a bit of an annoyance. But yeah, just something in how it loads it is different. So you, you want to fix this before the 040. No, no, no, no, no, no, we want to add it. We want to do it as like a future patch or. No, no, we shouldn't hold it up. It's just like, I think the easiest way to get started with building a wallet is expo and just being able to add to the penises and getting started I think that that it would be great and I think will majorly improve the experience of getting started with AFJ in a mobile environment. Yeah. Yeah, so you see you see that there are plenty of people asking in the discord channel for instance they are asking about that so yeah. Yeah. Okay, so what about the demo is it fixed right now. What about the CLI. Yeah, yeah. I made the fix here I think did. So it's, yeah. It's not fully, I think there's issues again we're with the lib SSL not sure what's happening here maybe because the well but but now we can, I think, we can now downgrade to one to 20 ready because you very not ready has already done the fix in the address so when we can, we can do it. Okay, and that's released. Yeah. Okay, yeah. You'll make up your for that. Yeah, I will. Yeah. Okay, then. Yeah, I think that would be great. Because then this PR fixes the, the CLI demo and also make some change to the checked thing. Basically what was broken is, well, quite a lot. So like, weren't creating a link secret jet. And we were calling in port on the. We're also using like still soft instead of indie but we were calling import without overwrite, and we called create key which would already exist and then it would throw an error. So, it now imports the key and it overwrites it so it won't error, and it works with both checked and indy now. Right. Yeah. I think that's most of the changes I did. Oh yeah that's maybe an interesting one. I did change it to Oscar by default because I don't know where that changes these things are related to checked, because if we want to do a check end to end exchange between far and Alice both sides need to be using on and credits for us. And there's also ask her question is, do we want to keep supporting in the SDK in the CLI demo like is there a good reason to do it one side with ask her other side with in the SDK or can we just like start using Oscar in the demo and leverage all the new features that are available. Maybe we can just use ask her because actually the, the, the goal of using both was just to to demonstrate that it works, but now we know it work. We can just move on. Yeah, okay. Yeah, we have some tests I think still that run like where as cars to issuer and in the SDK or like the vis versa. Okay, but then I think then then that's that's great then we can leverage more of like the new features and we don't have to worry about what's, oh yeah it's like I removed this one. It's so it's now always Oscar. Okay, that's the end of the time of the meeting. Thanks everyone for joining again. Small group, but good discussion. And we'll continue. Next week, I think cream is going to give a presentation and I'm not sure if next week, but unlike arise and other standards and how it relates and that stuff and I think we're also still getting a demo from death. Dave from checks on like the checked integration. And yeah, maybe the wallet API redesign from Ariel. When time permits but I don't know I don't know next week. Yeah, in the coming weeks somewhere. Just a quick note, maybe a quick agenda item for next time is I've noticed that the FJ interop tests are not running complete on a IP 2.0 so you'll be interesting to to have that interop test enabled so we can track what features has been developed or not. Yeah, good point. I think Stephen also opens an issue about it. We need to, we need to look into it again. I think the API stable enough now so yeah, either me or Ariel is going to take a look at it I think. Yeah. Awesome. Thank you everyone. Thank you. Bye bye. Thanks. Goodbye.