 Good afternoon everyone. Hi there. So share a link again. Let's wait one more minute. Now we can get started. All right. Let's get started. And log everyone to the earth family JavaScript working group call of June 15. And I need to remember you to abide by the hyperlegic code of conduct and anti trust policy. If you would like to add yourself to the tennis list for free to do so I've shared the meeting links in the chat. Is anyone new here today that would like to introduce themselves or share what they're working on. Well, maybe me. I can start. I've been one sitting on on that meeting but was kind of like a year ago or so. Colleen Colleen Sonoff and we're from the rain company. So we're working on an interesting project related to you. I mean related to exchanging data and information through a did come message. And one of the reason why I'm here just to check maybe later on there is a Q&A session in regards to did come version two. I've seen there is a branch there and just wanted to see if someone is working if company is there is someone assigned it if there is a defined tasks. And if there is a defined task which are kind of clear maybe we can share some of our great developers to help and finalize that. That part of the framework. Yeah, cool. Good to hear and welcome. I think I added it for the agenda for today. Artem is here to give an update but we can definitely discuss it. Cool. Very good. Flores. I'm here with a couple of my team members. We have a long time on this call. We've been long time followers of the areas community consumers of the work that this great community has been contributing. We are part of entity that we're a social impact startup. In the process of building technology for underserved communities. In this case is a farm worker mobile wallet actually built on top of areas. And we're hoping for an opportunity to present today a demo of a low code wallet engine that is built on top of this great community areas framework JavaScript. Yeah, definitely want to have that demo so I think we can add it to the to the end of the agenda. We do really want to discuss some wallet API stuff today because we've I think already postponed it for like six, six weeks. But if there's still time left and otherwise we can put it first thing on next week's call, if that's okay. Thank you. I will I will suggest if we can, if we can do this demo before because I know that for Jorge is is very hard to to attend this meeting is 6am there so I prefer to just be sure that that he will be able to do the stuff you know. Okay, cool. Yeah, no, cool, then. Don't worry, it will be very very quick as well so don't worry. Yeah yeah no I just want I didn't want to push you forward again but if you're okay with it and cool. Anyone else that would like to introduce themselves. I'm Zdravko. Kalini is my teammate, and he already explained about our project. Cool. Good to have here. Also together with us we have Bobby I think you a couple of times you exchange some messages back and forth with Bobby he's also, I mean, from our team together with Alexia Lune. So, I think you met already, I mean at least virtually. And if I'm not mistaken last week you met in jury. Our CEO, Georg Greve. Yeah, discussion on this conflict to and yes, your team will join this week's call. So, yeah. Cool. Well, I see Yaacup is on the call also again today welcome Yaacup. Long time no see. Yeah, hi guys, hi guys, I'm back after a long time so today just just watching probably only great to be here again. Yeah, cool. Okay, so on agenda for today. We have demo from Jorge. I want to do a quick update on zero for zero release just like we have released it what status. What's next steps. And we have the wallet API discussion. We have a did conflict to discussion if Artem is here today and otherwise like let's see what what's left and how can we get it merged. And then there was some stuff on the replication PR from Ariel and other open issues PRs and that kind of stuff any any important things we need to add to the agenda. Otherwise we can also add them to the future topics or for next week but yeah please shout if you if you want something discussed. Then, Jorge, can you do you want to share your screen. Yeah, so what just do briefly, I'll just introduce kind of the project and just have a couple slides and then I'll hand it over to awkward who actually be presenting the demo. Perfect. So, to begin, just to get some context, what we're doing is. We're building an Aries digital trust ecosystem to facilitate farm worker serving organizations to transact digitally in a secure and privacy certain manner. Historically, here in the US, by the way, we're based out of the United States. I'm in Southern California and awkward is in South Africa. Historically, a farm workers are excluded from US labor laws. And, you know, they're essential workforce. The backbone of our food supply chain. And so we're hoping that it was technology that we're building will allow farm workers to be able to trust trust technology learn to trust technology. And be able to do, you know, transact digitally. This is an example. These are screenshots of an app that we've developed on top of it's a react native app. And the idea for the for the app is to serve as a single channel. From a farm worker perspective, a wallet holder can build a digital identity profile that makes it easier for them to access services. And so this, this, this app, we call it that Spanish for get ready. Prepare yourself. And that's in the context of farm worker or large comprehensive farm worker immigration reform that we're expecting from from our government to give farm workers a path to legal residency or citizenship. And so the idea is that here's an app where you can collect your information, build your identity profile, and then have the means through an areas enabled ecosystem did come credential exchanges that are to be able to transact. And so we have one service that's live in the, in the app. And that is a leave you. It's a pandemic relief. It's a program. Funded by the, by the United States Department of Agriculture. So our client, the United, the United Farm Workers Foundation, and eight system organizations were recipient of a grant from the USDA of almost $100 million to distribute in direct pandemic assistance to eligible farm workers in the form of $600 payments. So that's kind of in a shell of where we're at. And now I'll pass it over to awkward to present the framework that we, we've developed on top of various JS that really serves as the wallet engine for the app. And the idea is that this, we're building on top of a low code platform. And the idea is that we could take this wet wallet engine and allow other communities, other developers to build similar apps for the respective constituents. So, I'll just pass it over to other. Hello, everybody. I'm awkward. Also from into that, and I'll show you some of our progress. Just a second. Can you see my screen. Yeah. Okay. On the left hand side, we have the BC wallet demo. And on the right hand side is the service using every chase in our platform index. I'll just fire up the agent. Whoops. Just a second. Right again. Okay. So agents initialized and we can get started with the BC demo. We're not going to use this wallet. We're going to use our own agent to establish the connection. And with the connection established, we, uh, residential. From base BC college and there's a credential claim student first. So, and then we can go move on with the next of the. We can get a discount at an online store. And we have this, uh, the connection is established with college. And we have a single credential student card. And with that, um, credential and the connection to. We're going to establish a cool connection to cool clothes online and we're going to get our student card. And now cool clothes online wants us to present our student card. The next one we want to book a study room and leave our student card again. And that concludes the demonstration for this. We can also demonstrate that calm. So, on the left hand side, I have another phone that I'm mirroring. We can. Just a second. Start the agent this side. We could produce a invite. Scan it with the other phone. Established between the two agents. And we can use that car messaging in a basic chat. And that's what we have to demonstrate. Oh. I am. I would be curious. Could you tell a bit more on the, like the mandates part of it and the, the, um, the low code stuff. Okay. Yes. That's also relevant. I'll show you. A bit more about the tool. Can you see the screen? Yeah. So this is the ID. It's a very graphical kind of way of programming. You have a database designer where you can set up your tables entities as they call it. In Mendex, you have a flow design where you can design your flows and flows can execute in a client or on the server. The server executes in Java and in the client in JavaScript, JavaScript and JavaScript browser or in, in React Native. And you can extend the stock actions with custom actions. For example, this one is deleting connection by ID. And then you can create your own custom actions. And we're using Aries. I have J to actions. And for the, the Minix also has a graphical page designer. So you can also very easily design pages, buttons, inputs and things of this nature. And we took the most of the Aries library and created custom actions for most of the API functions. Let's talk a little bit more about the Minix tool, the tool that we're using. I'll just add a little more, a little more color to, to, to Mendex. Mendex is a low code platform. They're, they're a leader and in, in, in that particular space is a low code application platform. If you look up, if you go to mendex.com, the leader is in the Gardner Magic Quadrant. And both a thriving developer community of 300,000 across, across the globe. And so it's pretty active communities as a public marketplace, where you're finding functionality that's published by other developers, some of, some of it is for pay. it is open source and that's part of the valid proposition for us as a technology provider serving working with non-profit organizations. It really is a great tool for us to be able to build high quality security first applications and do it in a way where you don't need an army. You can get to market very quickly with this platform and so it's been great for us and we hope to be able to contribute some of the work that we've done to open source it like this this wallet engine that that I could just download. The idea is that any Mendex developer can import that Aries SDK module into their app project and immediately start to be able to leverage that functionality to continue to build Aries ecosystems. Cool. That's really cool to hear. Any questions from people for Jorge or Ocord? Cool. I think there was a question in the chat on what is built on ReignNative. I think you answered it in the thing. It's built on ReignNative with the Mendex platform. That's correct. The way it works is you build your apps in the studio, the designer, and then there's a build capability that allows you to also in a graphical builder, a UI, that takes a native template that's been customized by Mendex to be able to inject their dependencies into a ReignNative framework and so all of the dependencies that you introduce have to be compiled into that native template and then you have the ability to build your apps but it's ReignNative, yes. And then also it has a server-side component which could easily integrate with AFJ running a node using REST. Yeah. Yeah, exactly. Cool. And you're now on the 0.3 release or have you agreed to the 0.4 of AFJ? I think that the... Oh, I'm sorry. It's the versioning... Actually, you had a quick question for awkward. What version of the AERYS JS did you present today? Okay. 0.3.3. Okay. One of the things we've been kind of working on, we introduced the concept of contributing this package to basically want to open-source it and we've been following the conversation around the OpenWallet Foundation and we had been preparing to present this as kind of a project for that OpenWallet Foundation but we've been following the conversation with the AERYS community and just trying to see how that plays out. We wanted the opportunity to present this work to the AERYS community just so you guys are aware that there are folks out there that are actually building on top of your great work and hopefully if we move forward with the OpenWallet Foundation that that's... We wanted to make sure that that wasn't going to be a cause of friction with the community but I think that based on yesterday's meeting, I think that the collaboration there or the interest in collaborating is there. Yeah. I think we can go into the discussion of OWF and AERYS maybe a bit later if we have some more time. Yeah. But cool. I think either one is fine. I think, yeah. Alberto. Yeah. Hello. Nice to meet you, Jorge. Nice to meet you, Timo. This is my first time joining this meeting. Just a quick question for you, Jorge. Is there any way or have you considered a solution to build on top of existing apps? So let's say I have an in-native iOS or native Android. Is there a way I can integrate a Wallet SDK functionality so I can do, for example, send proof requests, offer credential? Is there anything like that that you've thought of? Or maybe not even just for Jorge but for everyone else? Is there anything similar to that? Because I think the community has Bifold, which is a react native project that you can go from zero. But what if there's a use case or a business use case where someone wants to get credentials on an existing app? Yeah. So that's pretty much what we've done. And I think if you can show him the MPM build command so that you can take your existing react native solution and just add the AERYS JS dependencies, I think you just have to add the AERYS framework, the core and the NDSDK. Right. But what if I have, let's say, an objective CF or a Swift app, like a native code? I see. I'm not entirely familiar with some of the other AERYS projects, but I believe I see, I keep seeing an AERYS-Samarin working group example, but I don't know. I think maybe someone else from the community can answer that. Warren, do you want to answer that question or do you have a separate question? I have a partial answer to that question, I think. One is that I believe that the Samarin base is not being actively pursued. I may be mistaken about that. I'm not really plugged into that. But that's my impression. But there was also a project presented in one of the AERYS meetings, I think it may have been at Acropug, which was a Swift implementation that has been offered up to the community. So it's not based on AFJ. It's a completely new, I think it may be modeled on AFJ, but it's a completely new implementation based on Swift. And for the Android side, I don't really know. Yeah, yeah, I think I've found the Swift framework, which is making good progress. Yeah, I think native apps is complex still. And we've got a lot of times also. And every time when also our clients ask it, it's like we mainly answer with like, yeah, it's just not something we really had an issue with ourselves because we mostly either build new apps or integrate it in React Native applications. You can run like React Native and add it to like a native project and let the framework be handled by that. But I think that adds a lot of complexity. So in that case, yeah, other languages, maybe such as AERYS framework, Swift, there's like an implementation in Rust, which allows you to call it from both, I think iOS and Android, I think then other solutions. Yeah, you would need to look at other solutions or come up with a complex thing. I think that in one of the limitations of having this framework implemented in JavaScript compared to something like Rust. No, that's totally fair, Ian. I think those are good answers. We actually dug very deep into this. Yes, and AERYS Go is another option. We have wrappers that build libraries for it, but it doesn't seem active in the channels anymore. I know Trust Black has something called Ballet SDK, which did be contributors to the AERYS Go framework. And yes, like you mentioned, the Rust and then the Swift, but none of them seem to be truly mature enough to consider it as an SDK native implementation. But yes, no, I appreciate the answers. Thank you, Horan. Thank you, Timon. Yeah, no, it's a tough thing. And I think also something to consider is always the question. Do we want one implementation and reuse that? I think if you have very complex stuff, you probably want to do that, like browser engines, you don't want to re-implement that for different platforms. But I think a lot of libraries are okay. So I think it's a bit of a trade-off. There's a lot of complexity involved in exposing things to separate languages. So I think that was also one of the goals of this framework, at least for us, is that like with a lot of these things, if you wanted to change something, you had to go like three layers deep in some very low-level Rust code. And this allows a lot more flexibility by having the logic implemented in JavaScript. But yeah, Jorge? Yeah, I just wanted to add that, I don't know if you consider this or where you are in your stage, but there's also the option of finding a hosted solution, right? And then integrate your native app through APIs and Rust API calls. That's actually how we started. That gave us the opportunity to figure out our framework for app development, but also learn Aries and learn their Aries protocols in the process. And now because of that learning experience, now then we're able to dig deeper into the weeds and actually try to get this function directly embedded. But I just want to throw that out there for you. Hmm, interesting. Can you point me to how much does anybody know what's the best place to go for those API endpoints or how those are managed within the hyperledger community? Is there a specific repo for that? So it depends a bit on like whether you want to use an open source implementation and then you can use something like Aries Cloud Agent Python or you can use Aries from JavaScript, but you would have to add your API endpoints yourself. There is an arrest extension, but it's still from two versions old. So it hasn't been updated that much, so that's not the best. And there's also like paid cloud services that you could leverage for this. For example, Trinjik is one where they provide just API endpoints where you can just have cloud wallets managed for you. Okay. All right. No, thanks. Just one last question. Maybe either or maybe you're a little bit closer. Currently in the development process, we're trying on different things. One of those things is actually creating a WebView in the Native app, right? Create a WebView and that connects to some sort of JavaScript, right? So we're also, and then that JavaScript will have AFJ, but that would be taking like a remote wallet in a sense, I guess. So have you guys gone through that path before? Has anybody tried that or any comments before you dig more deep into this POC I'm trying to build? What do you guys think? Does that infringe maybe some of the concepts of SSI? So are you talking about running a WebView and running AFJ in that WebView or through a remote API? Yes, something like that. Technically it looks like a lot like an API now and I think of it. Yeah. You would have to implement like the current dependencies we have for air swimming JavaScript, the native stuff that handles storage and crypto and all the heavy stuff that is only available for React Native and Node.js. So if you were to do it in the browser, you can run the framework decor in the browser, but you would need to provide your own bindings for crypto, signing and verification and storage. And so those aren't implemented by default. So it's an interesting path to explore. I would like to have like default browser packages available, but we don't have those yet. So there would be more work involved than, for example, running it in a React Native environment. Okay. No, good answer. Thank you. All right. Sorry for hijacking. There is one other thing to look at, and I've only looked at it very fleetingly, so I can't speak to it authoritatively. But there's another framework in TypeScript from Varamo. And Varamo does have at least some support for Aries protocols. And my understanding is that it's attempting to run in React Native and in Node and in browser. And how they're doing that, I don't know and how well it works. I don't know. Like there's a lot of I don't know here. But it's another approach that does at least have some Aries protocol support. And that part of it seems to be growing. But I would expect that making it work in the browser, as Timo said, will be a challenge because if you want to use the existing Rust libraries and stuff for all the crypto, then you're kind of, and storage, you're kind of sunk. Yeah. I think Varamo is a great option. Also, I think they have initially been more focused on derby3c credentials. And so there has been work recently to support DidCom v2 and also have to issue credential and present proof protocols. But you can't use it with Amacred's credentials. They mostly use like web crypto APIs, which allows them to run it easily in the browser. But for example, some APIs like Amacred's, we can't easily run that in the browser. There has been some work going on to get it working and compile it to Walsum. And I think we can do that also with other dependencies, but that is more of like an ongoing thing. So depending on what your needs are, I think Varamo could be a great way if you want to integrate it, yeah, in a browser environment. All right. Thank you. Thank you all. But Timo, I remember that you had a demo or some ongoing work on some browser wallet or something like that, right? Yeah, so I've started some work. Yeah, multiple times on like integrating AFJ in the browser, but mostly the DidCom part. I've worked on that and like in memory storage, but not really the Amacred's part. But Berend has done work on that and someone else also. So it should be possible. I think it's not really used yet. People haven't used the framework a lot yet for browser environments yet. Yeah. Okay, so about... Sorry, but for Amacred's, what's preventing us to compare it to Wasm? So it has been compiled to Wasm and it runs in the browser. And for the holder side of things, it actually works pretty well, I think. It was someone else that worked on that. And they got it compiled to Wasm. And so holder side works relatively well. It goes wrong if you do the other issuer side because the crypto libraries that the browser has are... It uses something with the SSL library, which makes it like if you want to generate a credential definition with a few attributes, it takes a few minutes to generate it. But I think for the holder side, it was actually pretty doable. Yeah, but so it is possible, but it's not something... It was a proof of concept to get it. We would need to have another library that handles Amacred's and then expose the Wasm files and have a build process for it. So I think the missing piece here would be having it released as a package and being installable from NPM. Okay, but anyway, if we can manage to run it at least on the holder side, it would be a very good advance, right? Because that would mean that probably we will not force people to install a native application or react native application. I mean, it can run on a mobile browser. So for some cases, it would be very, very interesting. Yeah, yeah. We've been looking at like Wasm more also because you know, for a lot of environments, you have Wasm micro runtimes, which makes it possible to run Wasm from iOS, Android, browsers, Node.js, react native. And so it would be a really nice way if you can just compile anything to Wasm, then you can run it literally on any platform without much hassle. So yeah, I think generally Wasm is an interesting thing to explore also for other environments than the browser. Cool. Ariel, do you want to do your wallet presentation for the last 15 minutes? Okay, okay, let me see. Okay, I prepared some slides, but actually it's more like a discussion or more questions than answers. So let's see what happens. I can actually my screen now. You can? I will try. Let me know if you can see something. Anything? Ah, I have to allow Zoom to do it. I think I will need to reenter the, to rejoin the meeting. Okay. So do you think, guys, we'll have some time to discuss the other points of the agenda like did command the new version of the AFJ because there is 13 more minutes. Yeah, so we'll do the wallet discussion and if we have time, we'll move on to the other topics and otherwise we'll have to postpone them to next week if that's okay. Okay, that's it. Can you see the main screen now? Yeah, we can. Okay, so I will, some discussion about the wallet API. So well, as you know, as most part of the framework, the wallet, the wallet model is widely inspired on what, on what came from, from the Indie SDK, the beloved Indie SDK. So what we would like to discuss today is a bit, how can we change a little bit the way it works in order to be able to more easily use different wallet types and also to make it easier to handle different wallets and list the wallets and, and, and delete and, I mean, do the administrative stuff with wallets and also to handle the, the, the data that we have in the wallet, like the keys, for instance. So at the moment, as you may know, the, the agent, an agent to be avant-garde needs two steps to work, like the construction and the initialization step. As some modules on the project, on the framework depend on the, on the wallet, because they need probably to fetch some records or do some stuff with them. They need to, to have a, a wallet, right? So we can, for the moment, we can specify the wallet configuration right on the constructor, or we can do it somewhere in the middle and then call the initial, the initialize for, for the agent installation. Something that we were discussing some months ago, I guess with Timo was that maybe we can, we can remove this wallet configuration from the, from the agent init configuration and delegate that to the module that is actually providing the wallet. This is something that would be useful because it's, it's hard to define a generic wallet configuration object because usually it's true that every wallet has an ID and probably a password or something like that, a password or something like that. But there are also some other configuration stuff, like in this case, we have the key, the division method that is not exactly the same, for instance, here in the, in Ascar and in, in the SDK and also the storage configuration. In this case, we are, we are using this parameter to specify if we are going to use an SQLite or or Postgres database, but it's likely that other wallet types, because, you know, Ascar is also based somehow in Indy. So they are more or less similar, but if you're going to use different modules for, for wallet management, it's likely that they are, this will not work exactly, and it will be hard to define at the core level and the core layer, all the, the constants and types to, to be able to be useful for, for every kind of, of, of wallet types. So, and then now we have, I have this here, here, how our wallet module API looks like. So we have all these methods like initialize, create, create and open, open, we can do a key rotation, delete a wallet, it's important and also we have those, these methods to create key and generate nodes. We can see that here we have, we have lots of methods and, and, and probably, and some of them are related to the, the wallet administration and some of them are the wallet operation like this one for create a key or, or generate a nodes. And I don't know if, if the users of the framework have, have noticed that recently since the zero, three, zero, we have this agent context, agent context concept where we can access the wallet of the, of the, the, the, the framework instance. So it's hard to, to tell what's the difference between using the, the wallet from here or the, let's say the, the agent wallet executes. So it, it can be some somehow confusing. So maybe we can, we can just try to separate the wallet API from the wallet interface. I mean the, the, the actual wallet that is opened by the, by this context. So in such a way that for the wallet API, we will only use those methods related to the, to the administrations of any kind of, of wallet like agent, a wallet creation, deletion, rotate key, export and import and leave all the operative methods for the wallet instance like create keys and while signing and verifying and all that stuff. At the moment, if you look at the, at the wallet API code, I will see if I can, I can show you. If you see, if you look at the wallet API, we'll see that we are almost every, everywhere calling the, the wallet object to do everything. It's most, more like an, an expose than, than, than other things. So what we can probably do is to, to create a wallet service. I will, yeah. A wallet service that will be provided by the, by the module that is, is providing the, the, the wallet itself. So that wallet service will be the, the one giving us the methods to import and export and, and, and that stuff. This is a, here, I left a question. Do we really need a, a wallet module and API on the core? Maybe we can delegate everything to the, to the ASCAR module or the INDIS model or whatever module. So, but anyway, I will, I left some, some of the, how, how the wallet API can be simplified. So we can have here the, these methods, methods for, for wallet creation and opening. Actually, I don't see a reason to have it, to have a create and open because we can probably put, put that here in the, in the options. And also for, for wallet finding, to, to find a wallet, to delete wallets, to export and import without being necessarily the wallet that we have open right now, right? And well, I don't have so many, so many things so I will go faster. And for the, for the wallet interface, currently we have all these methods. We have methods for wallet administration. We have methods for export and import. Actually, this is pretty weird because this method does not do not work with an open wallet. You will need to close the wallet and export it or, or, or import it. So for me, it doesn't make any sense to have a wallet object that it's actually more than, that has some methods that actually are more like static methods because they are not actually related to, to, to this particular instance. We have these methods for, for, for key management and, and using like this sign in data or verifying. And also we have these, these methods for, for message packing and unpacking of, I did comment in this case. So, well, here's more or less what we have seen, I have saved. And what can I propose is to, well, remove all that, that is related to the administration from, from this class. And probably add, add a few methods for, for key management like finding and delete keys, which is something that is missing here right now. And for the message packing and unpacking, I know that it's difficult to separate the packing from the wallet module itself, but probably we can call another object or something to, to, to not make the, the class, the, the, the, the wallet implementation very heavy, like is in the, in the case of, I have seen in the case of the did conv2 branch that it's about 1000 lines or something like that because Arten had to, to, to add all the logic for, for did conv1 and v2 and all that stuff. So more or less like that. We have methods for opening and closing and deleting the, the current wallet. I mean, this instance to create, find and delete keys to sign and verify data. This is the methods for, for did conv and also some generic method to generate, generate nonces and, and keys with options. I mean, the, what kind of keys we want to generate and, and so on. Well, I have one minute. So if you want to comment team or someone. Yeah. I don't think we have a lot of time to, to go into detail. I think a lot of stuff you said makes sense. So maybe if you can share the, the link to the slides, then we can put them in a meeting notes and then I can leave some comments. And if people would like to, to share their thoughts on the wallet API, they can do it on the document. And then maybe next week, we can, we can discuss the, those topics. Okay. Yeah. I will, I will do that. And also, maybe I will, I will have a discussion on the GitHub. Yeah. Maybe we can, we can comment there as well. Yeah. Perfect. Yeah. Thanks for this presentation. This, this, this is good. This makes sense. Sorry that we didn't get to the did conflict to topic. I'm going to add it to the agenda for next week. First thing, so that we make sure that we get to it. And also a bit on the zero four zero stuff, then we make that the two main topics. And I'll also ask Artem to, to join and share some things on did conflict to we'll try to join them next week, because at the very same time, we have a workshop in brown shark. And at the very same time, but at least we'll try some, some of us to join and that stuff was important to be there, Bobby and learning as well. We'll see how to arrange. I mean, the only thing is to see how it's, what's the status and if there is some, some way if we can help, that's probably, you know, may speed up the things. Because we really need it. We have some quite interesting project. I want to share yet what exactly is, as I said, is sending data through a did come, but also want to try it with a combination with race framework, go long and mediator. So it's, you see it. I mean, that's why we want to have that. We did that with the version one, the conversion one, but we want to want to have it in the two, because there is framework goes only on version did come is using on the conversion to. Yeah, that makes sense. Okay. Yeah, now we'll make sure to discuss it next week. Okay. Cool. Thanks everyone and see you next week. Thank you. Thanks. Goodbye. Bye for now.