 All right, welcome to the July 19th 2023 Aries working group call. We've got a full agenda marketing update. From Alex and Helen overview of areas VCX is the highlight today we've got the team here Patrick has joining us to give an overview of areas VCX where a ton has been happening lately, lots and lots of stuff going on. And then if we have time we'll have a status of the SDK discussion at the, at the end, and again only if we have time for that one. Reminder that this is a Linux foundation and hyper ledger foundation meeting so the Linux antitrust policy is in effect which is on your screen, and the hyper ledger code of conduct is in effect let's be good to one another. Feel free to join the attendees list. I put the link to this page into the chat. If you jump in. Please add your name to to the attendees list. Is there anyone new to the meeting. We, if you are new we welcome people to step up to the microphone and sort of say why you're here and, and what your interest is in and how we can help you get oriented in the areas community. No takers on that. All right. As far as announcements. If anyone has announcements I'm going to start with acopi we've got a release is zero nine zero pending we've got one more PR to go into that it will have a new release of credits which has is the an on credits. Which has some performance improvements and some fixes in an on credits and seal signature libraries that's the big thing going into that. But there's a number of other things including we're moving to Python 3.9 with this release. So the base will all be 3.9 in the in the various images and so on that are released so that's the news happening in acopi. Any other announcements from any of the other groups. Right. Alex. You've got the mic. Do you have a do you want to share. Yeah, I'll just share. Thank you. Okay, folks. I'm five minutes. I want to give you an update on two things that I've been working on a survey we set around that many may have seen about areas comes and then an update description of what areas is that we want to put on to the wiki as a starting point ASAP. So rather than the great detail I'm going to go through them briefly right now, share them on the screen but both links are in the meeting notes. So please review them at your leisure. They should be very in line with what we've been discussing last few weeks has no surprises so on that basis what I'd like to propose is that we'll give it a couple of days people to digest and follow up if they need to. Otherwise we can do an update to the wiki landing page with new description on the basis that we can always iterate it and make it better going forwards. So it's not set in stone it's just much better than what we've got right now. Yes, so on that base I just goes as briefly. There's a presentation link again is in the slide notes in the meeting notes. We got 16 responses from the survey we put together. We probably publicize on the high pressure discord. I'm here in the working group within a few organizations as well. And the summary of the results is mostly in line. You can go into these are these questions that you're on time but mostly in line with what we thought before with a couple of interesting insights. People didn't really care about areas being front and center saying he don't require blockchain that wasn't important to people, both in the dev and exec site. And there wasn't massively strong support for being shouting from the rooftops about creating wallets and agents being the thing you have to say upfront. Of course you can do that but it's not as important as we thought it might have been the rest of it pretty much in line with what we thought like privacy preserving everything else. These are the business results and these are the developer results on the next slide so you can even look at those as you wish. We got some great suggestions of other things you might want to mention in our description from government level identity and KYC very critical or cryptography status and whether it's better than so forth conform with his standards and great recommendations from people. And we also got a big laundry list of starting materials. Lots of courses repose videos that we're going to put into that wiki page as well as starting points. People coming to this fresh. Here along the line with what Steve just said as soon as we can get update the hyper ledger period pages by Aries the better. And we're going to update that when we can because they're doing a site refresh now and was going to update the REITME file for the main Aries GitHub page as well. So with that said, again, I'll just give you a quick summary. We've got these two descriptions in the other document that links also in the meeting notes in line with those survey results. This is building on the draft we had before. And with a few changes and a bit more scannable and a few things deep prioritize to make it clearer. So on the first page isn't it is a general overview and this is the one that will probably form the basis of the wiki page. And then probably to be adapted for the hyper ledger areas for the hyper ledger site is this higher level, more exact focus with less terminology. And we can have this in our back pocket for future users anyway. But there's this version as well which is the same as the top one but less techy. That reaches my time so but yeah go ahead Steven and welcome any initial thoughts right now. This looks great. Yeah, I think we've got a good starting point and again, I would suggest if anyone's got concerns about prioritization what I'd like to recommend is that. Let's get this up I mean if you feel as a showstopper please say because this is a community effort but what I'd suggest is let's get something improved. And if we need to iterate it. By all means reach out to handle myself our email addresses are on the meeting notes. I'll also chime in here that we, I'm still putting together the list of links that folks sent, which is fantastic there we probably got at least have a couple dozen at least. But if there are any links to white papers reports blogs. You know your company might have a podcast or whatever anyways any any type of links that you think are helpful and beneficial to new folks in that that approach areas. Please send them my way because we would love to have a, you know, a quasi comprehensive thriving list of community sourced places for people to read more and learn more and see the growth of the community. Absolutely. Awesome. Thanks so much. Yeah, thank you Steven thank you Patrick for a short inter interjection there and any feedback send it away much appreciated. Alright, if no one has any other comments let's go to areas BCX. Let's get an introduction to that for those that haven't looked at it in a while and learn about it and hear from the team so over to you Patrick. Thank you thank you. Alright, I'll share my screen and report some sort of improvised presentation I like to draw it all so I just skate something together. Right. It's very flexible. All right, let me maybe turn off the camera for now. Okay, so hello everyone. My name is Patrick stash I'm one of the maintenance of maintainers of areas BCX and I came came here, we me and the team came here today to talk a little bit about you know what it is who we are and why we are doing what we're doing. So, starting with some general info then we'll go into a component overview from mainly from perspective of where we are currently and where we are going can maybe where we've been before. So that kind of should give you idea of the trajectory of the project not only the you know status quo at the moment but also where we are headed from where and so I'll talk about talk a bit about the components we have deprecated components which are sort of stable new components we created from the scratch and stuff we are planning to do. So, some, some more intro here. So, first like elementary question what is actually areas BCX so. So the general approach we are like philosophy we, we take is that we rather consider ourselves as a library rather than framework so it's not that kind of a batteries included approach. We are already ready we are trying to provide the building blocks for creating areas and also known areas applications. So we have a sort of a. Obviously the kind of first class citizen right now is the library itself implementing the areas protocols, but also the repository contains a lot more is also a set of areas and supporting components written in the rust like the resolver the parser. This is a project maintained by three people representing ups I just saw the Frequent Bank, me included, and George Mulhern as an independent contributor. We have him on a call right now as well, we have everyone on the call I believe. So, and then maybe the question is why are we here now suddenly we've been kind of working in the shadows for a long time didn't really engage a lot with community didn't join these calls. Thank you very much. So, one of the reasons just just from the nature of, I guess evolution, the library and experience of ourselves as developers as well. So, some of you might know that the project was fork originally from something called lead BCX, which was part of living the developed by every name. So just from nature of like having different philosophy before different priorities. Given what we are we're trying to achieve. We considered, you know, there was a, there was some amount of technical depth inheritance. We wanted to do like a bunch of cleaning and trying to trim it into our, you know, our kind of shape, we wanted to have. So for a long time. We didn't really feel confident to like invite people and engage like widely, because there was lots of, you know, our own work, we felt like we need to do first. And it was also difficult to onboard people, the setup to get the whole thing running was quite difficult. And maybe for for sometime in the past we didn't even have like clear understanding of our identity like who are actually who we actually are in the framework, should we try to build things conveniently batteries include kind of way, should are we trying to build an agent eventually, you know, we were not sure what we are, and this kind of shaped over time and we understood that we are building as I mentioned rather like components and library than like agent or or framework even so and also additionally, we are looking to kind of start just in general we would like to engage more widely with the community perhaps have more contribution outside of areas we see as repo, and also, given, you know, given the previous points, we feel more confident welcoming new contributors who would like to, you know, work with us and, and, and create something there's there's plenty of work. So, I will move to the component overview, but I just thought maybe it's good idea to stop for a second and just like give us space for a shorter. If there's any questions, although there will be time for Q amp a afterwards so, but anyway, if there's any comments or thoughts before I move on. Now it's, now is the time. I'll ask one quick question. The series of agnostic supporting rust components. Do you see it as a good idea that things like the did resolve or I did parser would would be useful to use in other areas frameworks. We'd be looking at replacing a did resolver and occupy say with the did resolver component that you have. I believe it will be a good idea that's that's eventually our goal to basically not only build like areas library, but there's lots of stuff we just like the did resolve right which is really independent from areas and can be just used anywhere so it will be pretty not to try to modularize it so that's what we did and well if you know if somebody uses will be more than happy because then more people will be incentivized to make it awesome and great and reliable and safe. So, you know, it will be amazing if, if, if, as I mentioned last point if there's new contributors will decide to let's say even just reuse some components. And then we would have, you know, a reason to work together. So that would be great. Thank you. Any, any other thoughts or comments. Yes, I have a question Patrick over to here. We've been speaking for a couple of weeks on the discord channel. I just one generic question here and I have some follow up question but we can wait till the end. Why rust. What are the advantages of this programming language and what would you tell someone who's thinking about maybe going down this route learning rust to get into the, into the space of contributing into areas VCX. What would you tell that person. Yeah. So, so historically like we had just like a reasons to go with the VCX and improve it over time but, but now, like, you know, I guess additional reasons like emerge for us or like strengthen our convictions mainly the ease to integrate with other rust components, given that most of the areas, you know, basic components are written in rust we find that it, it makes sense and it's easier and safer to just, you know, stay in the same ecosystem. Use the advantage of all the typing and all the good stuff done in this, you know, core core libraries. And well, in general, you know, like the typically pitched like rust advantages about the safety typing and like, you know, costless abstractions. Well, we find it like, you know, it's, it's, it's, it has also advantages to stay in the ecosystem and basically implementing areas in the rust, we can propagate the advantage to possibly other applications. Whether it's, you know, mobile or whatever rust in, you know, every infrastructure you want to build issue or verify mediator. We are giving that option to stay in that ecosystem, you know, not having to reimplement areas like it's there. So now it's possible to actually build issue or verify mediator, or whatever else, you know, from these rust components. So we like to consume this, this, this components natively and we kind of want to propagate these advantages further to other applications and see see thriving. Okay, thank you. All right, I'll move, move on, and we can get back to some questions at the end so I basically only one more slide left. So component overview. Maximize this maybe. All right, so this can go away. So here I wrote, draw like a kind of high level overview of all the components are the really holistic overview of the repo. It's detailed and detailed in some parts, but I find those, those important. So for the like, you know, coloring schema. So there's like the red ones are the procated blue one are somewhat stable doesn't mean there's no changes but I know they've been around for a long time and maybe there wasn't so many changes recently. And then we have like new components of green which are pretty much written from scratch like really new new green filled components. Then we have yellow which is in progress. There's a few of them. And then orange is kind of on the roadmap, you know, or something we are thinking about or possibly planning or hoping that somebody else might do it maybe. So, let's let's dive into it so I'll start with like the, the main part of the core components where we have you know the areas VCS trade itself so this is for us kind of a first class citizen. So this is the integration layer of all sub components we have, and it's a main building block for an, and you know, a third party application which wants to use areas protocols for something. And so this is purely rust. So you would consume areas VCS from another rust project. So VCS itself. It's as you see it's using like a number of sub components there's some deprecated the dog. And but we have a whole bunch of new crates actually written from scratch. The rewritten are like every messages data models from scratch. We have recently wrote a deity resolver, the, you know, kind of a deep dock data model and builder, you know, and all the stuff you might want to have to kind of work with the and then some, some deep methods we have the itself the web the peer hopefully like, I don't know the state of the dindy but they'll be coming as soon as it's possible to implement. Yeah, and then we have then we have as you see I split it out areas VCS credit kind of actually into two sections. So we have like a kind of old person, a stable, and then we are now in progress of essentially rewriting our state machines in a better, more testable and reliable way to make sure that are, you know, there are, they don't really contain much like contain as little IO as possible. And we are starting now we did exchange protocol actually with this approach. So we'll be adding more, you know, we'll be applying kind of, we are in a pioneering stage where we are kind of discovering how to write this every state machines in a better way and so the first one is kind of the most difficult just still learning. And then we'll kind of reapply the same approach and all the other ones. Then we have also, I would like to mention this whole big green blob of components here, which is also written from scratch recently. That's about interfaces to to the ledger. So we have like generic, like general interfaces for simply reading and writing to like to writing on on credits structures, and then separate interfaces, which are specific to Indy. And then what I really like are the sub sub sub components underneath that. So that for example we have like just transaction submit or interface which can be implant for which we actually have I believe three different implementations. So we can submit your transactions using Indy VDR, or we can easily be in the, or we can even use VDR proxy. So this is super cool when you want to actually run, you know, some kind of issue, some kind of issue or very far service in club in restricted cloud environment where you might not be able to use zero and cube because of security guys and stuff like that. So, so then in that case you can, you can use VDR proxy to kind of offload, you know that burden of dealing with zero and Q, you know, from your issue or very far service and you don't, you don't have to deal with those security compliance, you have offloaded somewhere else, maybe two different VPC or something. So I really like this one. And then we also have like, you know, you can you can inject your own transaction caching. So we have like separate signer for transactions, which is basically only only you only need that if you are right, if you're ever writing on the in the ledger and some response parser which are picked from from actually living the as we found that VDR didn't have modeled like a data model for ledger responses. So we found this piece of liberty pretty useful. Well, and underneath that, we have like our the engine of this whole thing, which is like the ledger implementation and credit implementation and wallet implementation. As you can see we are now deprecating VDR tools, aka Libindi ledger client implementation. Next with an uncreds you are deprecating VDR tools implementation VDR tools, especially been the implementation of uncreds in favor of credits which we have just implemented recently including migration from VDR tools to credits. And now we are kind of slightly struggling to move on to unencreds RS it's kind of one of our challenges at the moment. And then with what we are pretty actually pretty happy with VDR tools, aka Libindi implementation of the wallets, which provides my SQL and SQLite implementations. The plan kind of is this is an orange color, which stands for like roadmap or plant. We are definitely thinking of implementing the storage interface with with Ascar as well. And then I actually move a layer up which I skipped initially I started from core components and went down to the to the underlying engine, but looking up, we also have like FFI layer on top of that and some application layer. So for the FFI, historically, there was something called libvcx and that used to be actually the main value proposition in the old times when when this code resided in the SDK, the libvcx provided a way for people to build mobile applications. Now that's being deprecated as the approach itself how to do these FFI is kind of outdated at the moment and there are better alternatives to do this. So instead, we are and we are kind of in a prototyping like initial phases of building alternative to libvcx so people will be able to build mobile applications using, you know, basically providing areas V6 APIs to Java, you know, to Android and iOS. So we have we have started Hyperledger mentorship project which got approved and we have a mentee right now we are mentoring working on uni FFI based wrapper around areas Vcx, which auto generates, which we will, which will be, or is auto generating Kotlin and Swift wrapper wrappers. So it should be a lot, a lot easier to maintain and should be a lot more reliable safer, all the good stuff. Now moving to the right side, this is, this is, I mean technically these two are equivalent it just like some these two boxes, FFI and applications, it just some rust libraries or applications, which consume areas Vcx as a, you know, the kind of a main trade. And so, but the difference here is in the application section I put here projects which are like natively in Rust and will stay in Rust. So we have, we have within the repo we have something called areas Vcx agent which is like really simple areas agent library, and it makes it a little bit easier to build the agent in Rust, it provides persistence and some, some, you know, like default processing of messages, which you would like, which is like likely desiring like agent implementation, and then on top of that we have implemented an example for areas agent test harness, which is like running. By the way, here I have like the latest result I found, this is the, you know, Vcx interrupt with the other frameworks we have like this and coverage with acupy. We have coverage with AFJ, not full. I think some tests are like skipped, or maybe something is failing, we'll have to take a look at that. We have obviously good coverage with ourselves. There's other frameworks. We don't have coverage, but they also don't have coverage with other ones, for example, the .NET or AFJ go, they don't have actually much coverage with the other frameworks either. So we try to cover the kind of the main, we consider main ones, the acupy and AFJ at the moment, lots of big communities around these. So that's what we kind of care about the most right now in terms of the interrupt. And yeah, moving back to the other, moving forward to the other applications here. So we have another mentorship project under Hyperledger, which is Aries Mediator, you know, or Ditko Mediator. So it's just like standard stuff, pickup protocol 2.0, you know, it's kind of experimental. I know there's a talk on Discord about mediators and we are not very active there, just kind of trying stuff on our own right now, you know, and see where we get, I guess. And maybe, you know, we can, if we run into challenges or some like learnings, we can share that, but right now it's in a very initial stages. So we don't really have like much to share yet. And then in an orange color as a kind of a plant or, you know, thought about at least is some sort of enterprise issue very far. You know, it seems like a natural evolution that lots of people is interested in, in, I would say, FFI people who come into Aries BCX are often asking about are often looking to build native applications. They're asking Libby CX, we tell them that it's deprecated that there's UniFFI, you know, it's kind of hard choice. It's kind of difficult moment right now, because like this is deprecated and this is not yet mature. So it's kind of either build something kind of on your own or you contribute here or you just stay patient. But in terms of like on the other underside, you know, of the of the issue and very far, you know, given that it's kind of crucial service I would find it as a natural evolution that we want to get here and have, you know, take advantage of all the performance and the safety and in like issue very far landscape as well. So, yeah, this is kind of what it is, what do we do, and I guess I'll just leave space for discussion now and any questions. That's an awesome overview that was a lot. One question came up I had the same Colton asked it as well. In the DIT peer, have you been following the DIT peer 3 and have you got support for DIT peer 3 in that? Yeah, we have implemented DIT peer 2 and DIT peer 3. Excellent. Okay, good. If we are synced up with like the latest developments, I know there was like some edits in the RFC. We might have to catch up on that, but we haven't yet actually integrated the DIT peer itself with kind of the state machines and the, you know, the areas kind of core component. And it's more of a plan to be part of the new state machine and the DIT exchange protocol we are just implementing now it should support the peer so we'll definitely, you know, be careful there. And make sure that it's like ready once it, once this kind of turns green or blue. Yeah. I had a question. Yeah, in regards to Unify. So these wrappers you mentioned with Kotlin and Swift. Yes, this will expose the areas to be CX API and engine. And what would you be able to do with those wrappers? Would you be able to, for example, create like a wallet implementation on the mobile side? Yeah, so you'll be able to do anything. I mean the end goal, it depends what we know how much this will be matured, what kind of, how much integration it will have with areas VCS, but technically you can propagate all the APIs we have in areas VCS, we can propagate, you know, we can enable in those Kotlin and Swift wrappers. So you could be, you'll be able to do anything in those what you are able to do in areas VCS like Rust trade. Right, well, thanks. By the way, I believe that, correct me if I'm wrong, if somebody more familiar, I believe that Unify also generates Python bindings, but I'm not 100% sure about it. We mainly do it for the Kotlin and Swift, that's kind of the main goal though. Hey, Patrick, could I jump in real quick? Yeah, for sure. So on the Unify, just a quick shameless plug, I've written some tutorials on how to use Unify and what that means in relation to FFI, I put the link in the chat if you guys would like to take a look. One of the things that I've also done so Unify natively supports Swift, Kotlin, Python, and Ruby. I think it also does some other integration with CC++ although that seems redundant. One of the tutorials, the latest one I wrote, I needed to use a Rust library in Java. So what I ended up doing was creating a Kotlin wrapper and then going through the process of how to create that and then importing that into Java. And so some other guys have done some work integrating with C sharp.net. That's not part of my tutorials, but that's also out there. So all of this is growing, but if you'd like to take a look at my tutorials, they're a real super simple way to get started in that. That sounds great. I think this can be a great help for our mentee working with the Unify. Thanks for that. Actually, Patrick, on that note, will this mentorship program be open again to the community? So I think that Hyperledger, sorry, Hyperledger is organizing this once a year. And it's been happening for the past three or four years, I believe. So just extrapolating based on that, I assume that there will be another one in a year or so, but until then, you know, this mentorship lasts until November. And then, yeah, I don't know what's the Hyperledger plan for these mentorships in 2024. Thank you. Understand that mentorship, or sorry. That, that uni F, uni FFI. Basically what you do is you define what the interface looks like, and then you can generate. And then it's just generated from a single source for all of the different things you want, like you just say, oh, I'm going to do Python as well. Is that correct? Or is there got to be customizations when you do Python and other customizations when you do Kotlin? Yeah, precisely, I believe there's no need for other customizations, but maybe Steve, Steve might know better. Yeah, that's true. You, when you create the language wrapper, once you've, you start with creating a UDL, which is kind of like Web IDL representation of the interface you want to create. And then it's a single, single command line command to create each individual language wrapper. So once you've created it for Python, let's say, when I create it for Kotlin, it is literally one, one command line command to do that. Okay, so it's more you're, you're maintaining this. I can't remember. You need this, this definition and then, and then just generating from there. Okay, good. Yes. Seems worth the effort. I've enjoyed it. So I'm a strong proponent. We, I looked at doing this without Unify a couple of years ago, taking the Ascarb library and porting it over and taking it to the FFI based Swift implementation that we created because it felt to Swift developers like C and Swift developers don't like that. And so this makes it feel like the native language. Mozilla has done some really good work on this one. And then the other comment I made in the chat Patrick is definitely as, as you're looking at that meteor project. And if you're looking at supporting Web sockets definitely look at the work and DC has done and contributed to Aries in the Aries socket dock repository. I heard about that. But thanks for additional heads up. I'll see how we can harness that and try to save ourselves some work with the Yeah, and the other thing is I think this is the most active. Well, I'm sure there's other stuff going on around socket dock but right now. Yeah, if you're doing mediator and you've got a project like this I think it would be worth taking a look at it. Thank you. Any other questions. This has been a great summary. That's that pictures. Awesome. Thank you. Excellent. All right. Anything else you want to share. No, I think, I think that's it. That's all I had. Thank you. I'm just going to start grabbing the sections, the intro and the sections out of the recording so you've got those as well. I think it'll be, I suspect it'll be a YouTube so it might be just links into the starting points but I'll let you know when they start. Thank you for those for other purposes. Great presentation really appreciate it. Thank you. Thanks for space to talk about. Okay. As we talk about more general areas things we definitely would love to have you folks if you can make this time time slot. Have you joined in because obviously there's lots of things we can learn and share and make decisions about together so that would be very helpful. Status of the Indie Indie SDK basically. I did a short presentation and I could probably bring it up again but on the Indie contributors call yesterday, but talking about the need to deprecate. The Indie, a lot of what we've been talking about today or a lot about what Patrick mentioned is the transformation that BCX is has done. But we really need to more aggressively in the community deprecate and perhaps archive the Indie SDK repository. I mean, in the Indie project we're talking about that. And I wanted to make sure the, the Aries community knew about that and was taking steps to do it because part of the work is, is for the Aries frameworks and libraries to take into account, you know, make it so that there's alternatives to you from using the Indie SDK. But then there's the those that are using the frameworks and using the libraries to do that transition as well. For anything new, nothing, you know, nothing new should be starting with live Indie as the basis. So if you're starting new with Aries projects should definitely be on the non not using live Indie. So those that are using it there are conversion and migration tools and we're going to be highlighting those in the next little while to make sure as much as possible people are moving away from the away from Lib Indie and and over to the newer tools the both more more stable and better maintained shared components or the tag that's used for all of them is just ask our based right now but it it encompasses both Indie BDR which is the interface to Indie. And then ask our which is the storage component, and then either credits, or an on credits hyper ledger and on credits as the non credits implementation. Those are the three components that make up the Indie SDK and, and those are the new components that we're transitioning to. We just need to push that transition along. We just need to get that to get that word out there. I don't know if anyone has any other follow up or comments on that. I believe if you're using VCX AFJ or acopi it's it's pretty easy to use the other tools instead of Lib Indie and, and as I say definitely start doing that because we need to deprecate the Indie SDK. That's all I had I guess we do have a little bit more time than I had expected. Sorry for for making you compress Alex, your session for given. All right, thank you. Any other topics people want to raise I see there's something in chat. I have a question from Daniel Daniel you want to jump on and ask. As just as a follow up to the unified discussion. Does it support generating like idiomatic async in the rappers that it generates. Pretty straightforward question just curious. I know that there was a last time I checked those some issues about you know using async. In the community and there was some PR PR addressing that so I believe if it's not already there, they're definitely working on it, but again maybe Steve know my no better here. Steve, do you know. I haven't used the async capabilities. Maybe that needs to be part of another tutorial. I do know they're working on completion handling and that's the codes been rolled into the database already for the next release so hopefully the future completion stuff is. Is imminent. Yeah they have some fixtures for async handling and Colin Swift. But I don't think they've officially released it yet because it's not in any of the docs just yet. But it seems like soon. Okay, interesting. I would read a tutorial about async interfaces generated by unified so I definitely be interested in that. Okay, I got one reader. I'll get right on it. Daniel's point is that's a pretty core part of what of what we're doing in areas and pretty crucial feature is that that's the motivation for the question. Yeah, yeah. Yeah, so when I when I looked at it. When I was working on one of the first things I was working on with Unify was areas as car. And there's, there's lots of the lots of those futures in there. And so what it caused me kind of an architectural introspection, if you will. Do the futures belong in the library or in how the library is called and I know we could debate that back and forth and there's probably no right answer. For for now what I've been doing is putting that kind of stuff in in how the libraries called versus in the library itself. So once that capability is, and the reason for that is how certain things are handled crossed language kind of matters. And so, Kotlin, or Swift or Java or whatever might have some nuances that are different than rust. You know, how do they when when you go cross language programming like that part of what you need to keep in mind is how the differences synchronize. And so that's what I've done so far. But with with these futures emerging from Unify. Maybe that'll smooth all that out and it won't be an issue but that's, that's where I've done things before the other thing that I've done is, well let me just leave it at that so I'm following that and as soon as that becomes GA from Unify, I plan to write a tutorial specifically on that. Excellent. Okay, any other questions comments. With that we wrap up. Sam is away for another week. So I'll be back again next week if anyone has topics they want to discuss. Let me know. Otherwise, I will plan on probably getting us back into issues related to transitioning the community transition of unqualified kids, and some other areas are FC things that are coming up so sort of issues that are across the areas community. I'll welcome other topics just shoot me a note on discord. And let me know. And with that, I will wrap up this meeting thanks all for joining. And thanks especially Patrick great presentation and the team with areas VCX looks fantastic work. Have a good one. Great presentation. Thanks all.