 Good afternoon everyone. Hi Timo, how are you? Hello. Doing good, how are you doing? Fine, let's say we are fine, yeah. That sounds positive. That's right. I created an agenda before, but I think I may have not saved it. Can create it again. Just leave the mother. All right. Okay, I think we can get started. Let me save it now so we don't lose. Progress. Awesome. Okay. Welcome everyone to the Arizona JavaScript meeting of May 11. I need to remember you to abide by the high pressure code of conduct and antitrust policy. Is anyone new here today that would like to introduce themselves or share what you're working on. Right, then we can get started right away. As you can see for the gender for today, I had two items. One is the new wallet interface, which we had on like our wallet API redesign, which we had under your name. Ariel don't know if you have anything to prepare but I mean we can at least have a discussion on it maybe. We have some V2 stuff which an issue has been opened from DSR and that they can continue to work and would like some input first. Any other topics we would like to discuss today. Yeah, hi guys. Let me check on status of India shared components, libraries issues regarding iOS version. So I solved the PR and some discussion, but yeah it's just interesting. What we do next. Yeah, good one. I think we can quickly discuss that. Okay. Then I think we can get started. I think we can pick this one up as part of the shared component stuff. Anything any updates for bifold over the last few weeks, and anyone that attended the calls. Okay. I think we can go for the errors working group call. Did anyone attend that. No actually I joined later, but no one was there so I don't know if it was very quick, or it was cancelled. I tried to join as well and there was no one there. So I. Okay, so we are in the same page. Sam Curran had asked for somebody to take over the meeting and he didn't get any volunteers as he was unable to attend this past week. Okay, cool. And I did attend I think the last bifold meeting, but most of the discussion was I think around mostly around the implementation of AFJ 4.0 and shared components and stuff so a bunch of this stuff that's on similarly on the agenda here. There was also a fair amount of discussion about mediator changes in acopi 8.0 and 8.1 and the performance improvements that are being seen and reliability improvements by using that mediator. Cool. Okay. And for the shared components and new updates, like integrating the new version of AFJ anything relevant that came out of it for us like things we need to change or do or we don't recall exactly and it's a little bit difficult for me because I'm not really involved in either of those activities in any meaningful way. So trying to understand exactly what they're talking about on that I'm probably not the best equipped to respond to that. However, my feeling overall is that the Aries projects are in a pretty large state of flux at the moment, given all of the work to try and migrate to shared components and that's not just AFJ and bifold but also acopi and that it's taking a lot. There's a lot more effort in getting it going than I think people expected but it's moving along but it's taking a lot. Yeah, I don't know. I think the more I agree with that. Yeah, nobody I think it is taking a lot more time and effort than nicely thought and like having it implemented but then also starting to use it in production use cases opens up a whole another like area of things that can go wrong so yeah I think one other one other thing that's coming that you're probably in plugged into as well is that the it was fairly sudden that the Ursa project is getting shut down. There's been some scrambling to try to identify the pieces of Ursa that the various areas projects are dependent on and pull those out into their own libraries. So there's work going on there as well and that's going to kind of add to the this load because again it's all down in the native layers so. I think, yeah, we've like heard about the whole thing. So, yeah, interesting to see how that will develop but but I think they have like a good solution of where everything should go. And we can still use what we need from the Anomkratz project. Okay, that's it for me. Sounds like a good discussion at the bifold call. Then on the shared components. The latest updates is migration script now fully works. So basically everything is done code wise, and it works for like 040 and I think we're. Yeah, as good as ready to go with that I think the only thing that was still left is the issue with the iOS version. And you took a look at that right. Yeah. I pushed a new version to MPM which I think I'm fairly sure that's the correct fix to make it work with lower versions. But I actually haven't tested it yet like from MPM I tested locally and it works with lower versions. It's not yet from the original MPM but I can do it after this call. Or it's, is it this one. Oh no, something went wrong I think with the item release. And it might have stopped the MPM release as well. I would have to check double check it. Yeah. No, I think the. Yeah, JavaScript did release. Yeah, okay, then I'll check it after this call, just Python we have to fix something there because apparently we don't have the rights to push to. We don't have the rights to do that. Yeah. Okay. And so if this works like this lower iOS compatibility stuff. We need to do this for also for Oscar and in the video right. Yeah, yeah it's a net this is the whole fix it's not a lot. No. Okay. And I think another. item is the version support with like cross building. I think states of that parent is that we need to build like the custom cross images right that's the for Android. Yeah. Yeah we we I think we have the images or place you got us the values for the Android versions that we can use. And I probably should have done it a while ago but I will make it into a Docker image. And then I think we said that you would find some place to dump it online so we can reuse it. But yeah once we have we have the value so the rest is like very simple spin it at the time to do it yet. But also put it on my list of things to do. Yeah. Okay, cool. Yeah, because I think if we have the stuff for iOS and then also the older Android version support then we can make like the first stable releases and and merge to work in in bifold and make the FJ release. Yeah. Cool. Finally. Yeah, finally. Okay. Does that answer your question Alexander or. Yeah, thank for the updates. Sounds great. Okay. Cool. Then let's do the did come fit to stuff. Oh wait no cream added something to the chat. Do we need to discuss the ask our CI issue. So ask our CI issue is that the CI sometimes randomly fails. I think we got like back to a pretty stable CI but I think like this is the one that happens the most now. Is this the same issue or is it a different issue. No, it happened with the JWT or the open ID thing. Okay, so. Last one that fails. Yeah, the scope check. scope check. This one. Yeah, that's probably it. It was in the end it succeeded so I think we have to look at the old one. Oh yeah, we ran it. That's why. So, thank you. Can we see like previous. Wow, why is this so hard. Let me see it's merged and then we can probably see it. So on this PR. canceled. Yeah, rerun the job, maybe that's why it's not showing up. Yeah, okay. Well, anyway, there was an issue with the Oscar. Yeah, because we can we see that. Yeah. There we go. Wow, it was so hard. Yeah, so. This one I think we've had it before. Yeah, it's on like error returned from database disk images malformed and I also sometimes get like random other errors with escar when running the tests. I'm not really sure what it's about like what does database disk images malformed. I had another one like that it couldn't find the conflict table or something but it sounds like database broken. So could it also again have to do with like, like the wall files and that for example if we delete a a, if we delete a wallet, that it doesn't remove the wall file for example and that we then like create a new wallet and then it does like apply the things from the wall file but it's like it can't be applied anymore like could it be again something to do with that. I have no idea, but it does sound quite likely. I think it's a good explanation of why this would happen. I think what Karim mentioned the conflict thing is I encountered that a couple of times before. And for me the reason was because I had a in the SDK wallet that I tried to open with escar. So with escar if you open a wallet it tries to look for a specific table the conflict table. And if you create the wallet with escar then the conflict table should be there. And if you create it with indy then the table is not there. So if you get the error of like it cannot find the conflict table then for me it was always the case that I created it with the in the SDK. Or I created it with in the SDK and then moved to escar and then I didn't change the wallet ID or something. And then it tried to open in the indy wallet. So you encounter that one that might be the reason but it shouldn't be non deterministic in a CI. That shouldn't happen in test though right because you destroy the wallet after every test like I am using the indy wallet and think in those. Well this was somewhere else also this was not even my test I think. But it shouldn't happen in test right because like if the tests are well written the wallet is closed and destroyed afterwards. Well maybe it's something to do with the test running in parallel. But the IDs are not unique or something like that. But I think Arjo and I we checked it once with to see if all the wallet IDs were unique. But yeah it might might have something to do with that. Yeah it is lazy. So it happens sometimes so that would make sense. Yeah. And then this might also be the same thing that what what team has said that if you have some wallet and you don't remove the wall file but you remove the wallet. And then someone else creates a wallet with the same ID or something. Then yeah applying the wall file probably there is a difference in the in the way Oscar managed the wallet is that it doesn't delete the directory of the wallet. So if if a previous wallet was was created with the same name. Even if you delete it. I mean you delete the file the SQLite file the the directory will still be there so maybe it's attempting to open something that it's empty and that's why it returns that. No such table or malformed. Is there a reason for that doesn't sound like a feature. I think it's because Oscar doesn't. I mean Oscar only handles the files but not directories. I don't know if you remember Timo that I had to add. I had to add a create directory method to to the file system interface because of that because when I create a wallet. I can return an error if the directory is not created for that wallet so maybe it's something related to that. Yeah, yeah I think it might all just come down to the cleanup that we have to do manually so removing all the shame the wall, the directories and all that stuff and then that that might be a good way place to start. If anyone encounters this again or like wants to find solve it. Yeah, feel free to do so. It's probably a nasty issue to fix. Cool. Then, let's move on to the did come stuff. Do you want to give an, an overview, Artem on like what you want to do when you're planning your outstanding questions. Yes, sure. Hello, everyone. So all this ago created the stick it. We are having an intention to continue this work and to finalize the contribution of it come with two. I already did some work regarding the updating the branch. And it was a big pain there were tons of conflicts and difficult to solve. Hopefully, I managed to solve them and now tests works on my branch. I mean not did come with two but the rest of the coverage and I pushed to my fork. I think I cannot push to seek by anymore because we do not work with them. I'm going to create a new pull request. To the did come with two branch with solving conflicts and I'm thinking. And I spend some time looking how now we can integrate it come and after the architecture changes it fits a structure even worse than before. Now when the wallet is independent packages. I think the did come approach doesn't include inside much more as then we won. For instance, now core package builds forwarding. What does JVA packing, but sick by library does it all inside. And don't really fits. Currently, the approach I don't see how it do more or less well. I reflected some my thoughts ideas and questions. What can be there as the best approach I see is the contributing to seek by did come library in fact to make the API more granular. Explosive methods methods which does just JVA envelopes parking, but not wrapping as it's now just by script. And once we have these methods, we can update wallet. Plug-ins seek a scar and the indies decay to call them. But I do not see a way how make did come package independent. Remember, in autumn, there was an idea to make it come implementation pluggable and make it is independent package. But if you want to make it independent at all. We need to an API to get private keys anymore from the wallet. But it's now it's totally bad in previous we had the wallet inside of the core and it was hidden under the public API. But now it will be available for users. So we now we are interested to get some design panelized design to come up with a agreement how we should proceed. What components should be there. What package is responsible for. And once we get it all finished. The design document I'm going to update the ticket or maybe even create a separate document. We are going to do it to implement and finish, hopefully finish the contribution. Okay. Yeah, makes sense. And so your, your preferred approach would be to implement it in the Oscar wallet directly and not supported comfy to like, yeah, they're not supported comfy to for the indies decay, right. Yes, this is my initial thought just if you're going to implement in both wallets it means there will be duplication of the code if it's not independent package. And this is why I suggested to exclude indie wallet from it. And once I looked more. Putin did comma SQL library inside of Oscar also cause some difficulties issues with the engine context, because it's sick by request the idea is over, but did resolvers right now they sit in the core. It's a nice agent context, but in areas Oscar wallet we do not have context so there was issues with it as well. But this path for me will be the simplest and the fastest and once we get it done we can continue on evolving it and making more pluggable and generic. Yeah, okay. I have a mostly a question regarding that because in your in your post you you mentioned that the secret libraries uses areas Oscar right something that I didn't I didn't know before. Yes, they use crypto from Oscar but they do not use storage from there. Okay. Yeah, I'm wondering. What would be the, the added value of using the secret libraries over directly calling Oscar like we are doing right now for did come be one. That's a good question. I also thought of it just in the view which sigma right now, like implement the crypto implements the structure of jwe implements forward in wrapping the provide the general structure of did come message. If you there is value, and it also supports different key algorithms, not just x 25 19 but a couple more types. Of course, it's possible to implement everything. Yes, like in areas in areas. But yeah we will exclude you and we can exclude secret dependency. I think one of the things and that's why I would lean also to do it using Oscar I'm fine with doing it with the did come library can also like migrated later on but I think we already have an implementation for like did come and and like putting forward messages around it and we have separate that more from like the crypto layer. I do think if we, for example, integrate the did come library into the wallet, it would, would mean like the wallet is going to resolve did and like we put all the layers we have an AFJ we just like throw away because then on the lowest layer that doesn't have access to the agent context. Well, like start resolving this. And I think, or like the other point on agenda today was the wallet interface and I think I would like ideally would want to remove the pack and unpack for did come v1 from the wallet interface and make the wallet really focused on providing a generic crypto interface where you can sign and encrypt stuff, but it's not like it doesn't have a pack method that makes assumptions about how you want to do it but it focuses more like helping you encrypt stuff and that's like we built a jwe layer on top of it. We've been working on adding like jwq support jwq support jwa. We have a jws service. I think I would rather move that up. So maybe we can look at a way where we like not adds did come to the wallet but rather we can move all did come logic from the wallet and just make it more encryption focused. If that makes sense. Who is in this case, it will be much easier to integrate. We will need the library but we will need the method to get private keys from the wallet and we will need it in any case not only in the library approach. If we move back outside. What did you say it lasts like you need. The method to get private part of the key out of the wallet. If you move pack, that's somewhere else. That's going to be a problem with indino does like does it make sense to have a unified. And now this is going to be a lot of work but does it still make sense to have a unified API for nice cat for nice car since they are like they offer the fact that you can pull your private keys have this is that's a huge different. I think if we keep the abstractions in place. It makes sense to have the same interface but if we want to do like what we've always said now is like you move stuff to the wallet and nothing like a key doesn't leave the wallet. And I think if we keep that model, then we could just build like a wallet interface that does the crypto and we build layers on top of that that use crypto for Jason Web signatures Jason Web encryption for JWT is for like everything like I think if we keep that model in place. The abstractions make sense if we want to do it like in a different way then probably the abstraction doesn't make sense anymore. Yeah, now I agree with keeping the keeping the keys in the, at least in the wallet class. I think that is a general security design pattern that is that's good. Because Artem, have you looked at like what would be like the effort in using the did come library versus Oscar directly now that as cars also fully implemented because I know we have like in the did come design there's like a class for representing a did conflict to message we have logic related to routing did resolving which we may need to tweak a bit for did conflict to but I think we have a lot of that already in place. And most of the work will go into like constructing the Jwe and the Jason web encryption payloads right and signing those because I know, like there was like an initial implementation done in a copy based on Oscar. Do you think like we could duplicate that because then if we come up with a more generalized wallet API. Like we could have like did come is something we built on top of. Yeah, we did something we built on top of the wallet API then and we don't need to get the keys out because the wallet handles the encryption and the signing. And I'm happy with this approach. I just was worried a little bit that we omitted secret all but they tried to contribute it initially. The random thought here but like for some implementations I've been working with over the last last month, with especially with external libraries like for instance the open ID for PCI client. They, you have to provide a signing call back right and like we then we take something that uses the wallet isn't that a an approach that because it really decouples the wallet from the other logic isn't that an approach we I mean it is it's not the most beautiful thing but it makes it really separate from from the actual crypto stuff and that might be something to look at. But that's what the veramo library does as well it's kind of a KMS and there's different KMS types and by default it's local which is to use the local database to manage those private keys. And so the idea is that you'd be able to replace that with one that for instance used the secure enclave or something else and again they use a assigning call back to to the KMS to to handle the signing functions. Yeah, I think that makes sense I think it's, it, it feels like a limitation after the did come library that they require you to provide the secrets to the library, instead of allowing you to bring your own crypto. Yeah. I really what do you think of like because you also wrote this of like where to put it and stuff. Actually, I shared that link because you were most more or less saying part of what is explained there right I mean extracting the backing and unpacking to to add to another class. And because of that, but but yeah, I totally agree that I will, I will prefer to have a separate layer for for the, for the envelopes, I mean for the shh w envelope handling and, and just using the wallet as a as a crypto provider let's say. I think the specifically functions instead of classes or interfaces will probably like I don't know how it would work right now and if it's even possible to use a secure enclave but I mean the good thing of, of having to provide functions instead of like a crypto provider interface is that it's, it's much more generic right like you, you have a certain, a few input parameters and you, you, you have an output. And that's it and, and whatever you're using like you can use ask or you can use Indy, but you can use whatever other stuff you want. It is possible currently to use a secure enclave because you can just implement the wallet interface and if you implement your own wallet that talks to a different crypto interface. You can have a, but you can use a secure enclave for example because you never take the keys out of the wallet. No, but isn't that like, if if we're looking at the operations that are there maybe maybe I'm not understanding this fully so correct me if I'm wrong but if I'm looking like at the most, the two most important operations are usually sign and verify right. And they're quite simple, like I don't know if, if, if implementing an entire interface is a bit overkill. I mean if they're just sign and verify if they just have two functions fine. What do you mean. An entire class like that that's the thing I did like about this very own library for open ID for VCI is just I mean you just have to provide to call back. And you don't have to implement an interface you don't have to. Yeah, it's it feels a bit easier. It depends on the interface obviously. Yeah, yeah, I think. Yeah, but I think it's really dependent whether that's like callback works for different use cases I think, like having implementing a class with a single method sign for example or having a, a callback in the end. It comes down to the same you have like a custom implementation of the logic. Right. Yeah, you do. Yeah, you do but I think like for some operations, I can imagine some there might be some things where you want to have an, I don't know, an additional like function or callback. Okay, I don't know, let's say verify revocation whatever like something something that is not needed everywhere, but in some cases in some cases it is like then are you then you would have to either extend that interface and add a new new thing that you would have to, well, edit to the original interface and throw a non implemented exception, I don't know, it feels like it's a bit more flexible but we shouldn't overthink this either so I'm okay with everything. Yeah, I think I'm fine with both I think that's just an implementation detail I think in how you interact with it. I think if you can make it generic enough I think we should just look at like all right what is needed for crypto interface. For which we can probably look a lot at the Jose suite in how they define all the different, the different relations between encryption, signing algorithms. These kind of things. I agree, this is probably a case of you ain't going to need it. And I do think interfaces are more in line with the rest of the architecture so maybe maybe right there. Yeah, I think. Yeah, we could look at it I think like we also had the idea of extracting like the wallet management from the wallet, which I think will also help a lot. And then you have like the whole process of creating closing that kind of stuff, separated from actually interacting with the wallet itself, which is often times different. What is the benefit of that because I mean you would need to open it before you interact with it right. Yeah, I think just set better, like separation of like what's how it works like currently the API. If you want to, for example, delete a wallet. You can't really do that without creating an instance of the wallet, but to do that you need to provide like you need to initialize it first so that you have to open a wallet just to delete it which you don't need to do to delete the wallet. And on an open wallet, you can call open again, and the behavior is a bit funky then so by separating the management. So if you call open you get a wallet instance and you can't call open on that wallet instance again you only can can close it. So I think it makes a bit more it makes it easier to manage the lifecycle of the wallet instances. And if I really want to open the wallet, I would call it two times right. But what what is like the good thing to go from here like what do we see as requirements what do we see as recommendations what is. Yeah, what do we think. Well, I'd say providing the the key material to the library is this that's not a good design in my opinion. So, I'd say either an interface or or or the callbacks but something like that. Yeah, I think so the only way we could use the did come library is by integrating it into the wallet. Because then the keys won't have to leave the wallet but they will leave like the Oscar storage but that's already the case now I think. That's option one. And another option would be then to allow like modify did come library to allow callback for signing encrypting. So we don't have to expose the private keys and outside of the wallet. But the did come layer can be built on top of the wallet. And another option would be do not use. Did come library implement crypto using Oscar and did come logic in FJ itself. If we're going to do option three, where would the library live is that going to be in core or as a separate package. I think this is a bigger discussion, which I think cream can give a presentation on. Next week. But what's the, like, what is the future of this. Like the structure of AFJ going to be and it's gone is did come going to be like a first class citizen compared to other protocols or are we also just making it like another protocol in in the. I think that's maybe something we have to figure out like, currently, when we have like the credentials module, we assume it's credentials for did come. But maybe we should move away from that assumption or that that. Yeah, good one. I was just thinking an hour ago. Oh, people asked me to present something but remember what. So thank you for the reminder. Yeah, just a little background deep like the my thought process behind this that did come was externalized to this like it started in areas and now it's well still heavily a part of areas but it's not like in the areas. Part of the areas ecosystem, let's say, so I think we should really rethink of like what is going to be core what's going to be outside. But yeah, but but but credentials issue credential and proof. Proof protocols are. Did come dependent right there did come from areas. They definitely but they are also like they are the RFC is still in the areas repository. There is RFCs but it's also part of. So it's a part of part of the diff stuff. So, I mean the question I guess is, do we want did come and all the did come base protocols to be part of the core, or should that be an optional thing. And let's say someone only wants to use open ID. Yeah, but I mean this is a question for for next week. So I think parents and so I think answer is not clear yet, I do think like the current implementation had it in a separate package I think that's always I think that's always good. And we can always move around things I think as long as it's like the implementation is kind of separated. Yeah, but we can continue on that next week. So, if we look at the different options. What option are we missing, or are we leaning to a specific option of how we are going to do this. I don't know if we're missing anything but to repeat and definitely leading to what to do. Which means the extent is we then still need to implement crypto using Oscar, because then we need to provide our own crypto logic. Who are some like in option to how would that be feasible like to do it like that or not, because then I think a big part of the did come library stick crypto right so if we don't use the crypto. Would that be an option then or what do you think I need to look closely right now. I'm not sure how feasible is it. Okay, regarding the second callbacks instead of interfaces implementation, just briefly looking seems to me there will not be much difference from the implementation problems which we have right now. We just we change this approach as I will be the same issues and one more issue, which I forgot to mention is that using areas as car we have very safe key handle and we have operation to free the memory to remove it, but we have a sick point of face when we have sick just secrets resolve where it's not clear when the call free function and it will be just leave in memory of JavaScript until the garbage collector clean it. Indeed, come you one. Indies decay cares about it. And rust clear it. And this is one more issue is current sick positive line. And if we switch to using callbacks probably this issue go away, but I'm not sure right now. Okay. Other people have opinions on like which of the options they prefer or I will I will prefer that the option three actually but I have no problem with because I think it's it's simpler for us to implement and it will have this in the short term in the short term. It will represent that we will not need to use more native modules, because if you're going to use Oscar, we only we will only need to to rely on Oscar module instead of having to I mean the Oscar and the stick but it did come to do the same thing but but I, I understand that that approach will be more or will be we will allow to to modularize more or or or make AFC more independent on the did come support. Yeah, I think that was also my point. And also, I think my preference is also slightly towards tree but it's not probably a lot more effort. But it also depends on if SIGPA wants to change their interfaces because I think they have like a good amount of FFI libraries based on that rust implementation and if we change it there with using sign callbacks and everything then it will take quite a bit of efforts for them to change all the FFI libraries and then all the libraries that use those FFI libraries. So I can imagine that it's not their preferred choice to to change like the core interface with their library. But yeah, we should probably ask. And I would also want to ask like we should not I think native modules are nice for the things where it makes sense right like crypto. It does make sense to to use rust for that, but or to have a single implementation. But for this is more business logic on top, I guess, so a more flexible that I mean when we implemented ourselves we are more flexible always. And we're not dependent on another communities or whatever so. Yeah, it is more work. That's why I vouched for two, but you raise a very good point. Any other people have opinions on this like which of the options they prefer or have arguments for or against. Not necessarily. I remember that I still have some partially done did conflict to implementation in typescript without any crypto dependencies which we might be able to reuse partly to move that into a J to make it work with option three. But I have to dig through that code because it's been, it's been a while, and it was almost finished I believe but not finished. Actually, we have two options, let's say we have your implementation and also we can use as a reference. So what we do on a cap I for using ask which was what I used as a base for for doing the implementation of the conv one with ask actually it wasn't so so hard to to translate that code from Python to to J s. We can. I mean, we do have references to work week. I think there's implementation. Oh, shit. Ah, look. But that feed to follows their entire did conflict to implementation. But no just like it's just a crypto for this conflict to so the packing and encrypting and the key wrapping and stuff. But it's quite it's not too much. No, that's nothing at all. That's 300 lines well. Yeah, I think it's 300. And the same is with for B1. If you look at our Oscar wallet code, the pack and unpack, you will see that there is a, it's the same as an inspiration. Yeah. Yeah. So, I think. Like, I'm then thinking like, I think I'm also leaning to option three because I think like it will be hard to do like option two because we need people to change all those libraries of violence as rappers. And I think option three gives a bit more flexibility to swap out the implementations and just also be dependent on like, have our custom did come implementation so then you only need to have like bring your crypto. And I think with, like, we could look at the did comfy to implementation I think from done using Oscar. We already have like logic to create forward messages. We have logic to resolve the documents and extract services. And we have things to have like routing keys. I know the PR that was started also had like a custom did comfy to class and everything so I'm then thinking like for option three. What are the big pieces that are missing that we haven't covered here yet. Do we know if any other just pure touch script libraries to do that come. Maybe they provide some interface that we can more easily plug into maybe not maybe just for reference to like that by implementation. But I don't know that many that are fully working and everything. Yeah, it's just always. There's always crypto intertwined, which makes it hard. Okay, I think we're at time. I think. Does this answer a lot of your questions I think maybe something to look at this right. Would it actually be feasible to do option to and otherwise like look at all right what are we missing for option three. Maybe. Okay, I look in our data ratio. Okay. Cool, then I think we can pick this up again next week and cream if you can gift presentation on the like general structure thing I think that would be a good discussion to have and then we can also probably pick up the wallet discussion, which we didn't get to. Sure, it will be a three part presentation so we have to do it over three weeks. No joke, I'll do my best to keep it concise. Now I'm worried. You should be. Okay, thanks everyone and see you next week. Yes, thank you. Thank you. Thank you. Thank you. Bye.