 Good morning. Hi folks. Hi. Hello. All right. First things first, I'm going to remove this bot from the meeting again. You don't like the bot anymore? It's not apparently, I found out it's not a hyperledger initiative. It just, this bot started to join all the meetings. And apparently they even mailed them to like stop joining us, the hyperledger meetings, but they didn't stop or react and, but the, the, the opt-out message works. So that's good. I'm going to do that now. Oh wow. So is it some bot just scraping public zoom calls and joining them? That's my understanding. Yeah. Yeah. There we go. Get my, get my windows ready and we can start. Okay. Let me show my screen and let's get into it. Hey guys. So welcome once again on areas V6 community call. It's third. It's a second of March, 2023. And this is our hyperledger antitrust policy notice, which you can take a look at. For a while and we shall begin. So we have a rich agenda again. Kind of lots of things I was able to fit in here. Again, reminder for anyone you can always feel free to add items here at your will throughout the week before the week, before the meeting or even just, just type before the meeting if something comes to your mind. But yeah, so this is what I came up with. So let's start with a recent, a recent work, which has been done. So we, first of all, we had the minor smaller serialization fix where this is mostly relevant. And this is relevant for like out of band producer side or a role. So in a role where areas V6 was creating out of band, out of band messages. So they'll be typically some issuer or verify. And basically we were previously, if there was no attachments included attached to the out of band message, we would still previously create serialize a request attach field in the message. And that would be empty array. But apparently according to RFCs, it's either this field is not defined at all. Or it has at least one message. So that's what we do here. Basically the changes when we now create out of band, out of band message and we serialize it. If the attachment field is empty, we, we skip the serialization. And yeah, and here. And the test over here, we are also checking that we are able able to able to deserialize out of band message, which doesn't have the request attached field. So it's not required. So this is a change on the out of band receiver side. So whereas previously we expected that basically the request attach was required. Now it's covered by this default macro. So if the, if the, if the request attach field is not present, it'll just get assigned the default value which would be empty array. And yeah, here we are testing that. So this is actually technically breaking change for case where areas VCX is out of band producer. And there's the older version of all the version of areas VCX receiver running against that. Since the new version would stop producing, stop serializing the request attached field, the older version of the areas VCX agent would fail because for the older versions, this field was required and it always had to be at least empty array. I believe this doesn't actually impact anyone. As I know, most, most people are using every VCX on the mobile side. So this is in that case this is just generally a fix, because other other other implementations like a KPI, they would simply not set the request attach, or would not expect it to, to be empty in a message. So this kind of syncing up with the proper correct implementation. At the same time, it's, it's, it's breaking in some very particular, particular scenarios. Any question about this one guys, I guess we're good. So move to the next one. And then when we had Livy CX split. So this relates to the, the, the precation we've been mentioning before so to kind of make it more clear and make it easier to communicate like the overall state. In this PR we have split Livy CX into two crates. That's a Livy CX core and Livy CX. Now basically Livy CX the directory as it was named before. It contains the same technically, you know, it builds into the same binary same trade. But it just kind of smaller. There's a deprecation notice here. And basically this is now built on top of a Livy CX core. It's kind of a smaller, smaller part of the original Livy CX. Here we have also the diagram so basically this is what it looks like we have a Livy CX core. And on top of that we have the Livy CX which with the iOS and Java wrappers which we consider now deprecated. So on Livy CX core, we have built out the Node.js wrapper. And, and as I, as I know, Dinesh from Canada is also building Flutter wrapper on top of Livy CX core similar to V6, not PRS. For my understanding the unified RSV6 will be where on this diagram. I'm sorry, I, you kind of, there was some audio issue. Yeah, for my understanding the unified approach that we will have to replace the Livy CX on this diagram will be where on the core. Right, so that would be again totally outside that would be like, you can imagine there will be a new box here on the right side and that would point to the RSV6. So the unified would be like completely new wrapper around RSV6. We don't have anything to do with the Livy CX core anymore. Okay, thank you. But yeah, like, generally speaking we are, we are, you know, looking for contributors like we don't have like a direct as a, you know, as a, as a company we don't have intention to develop the unified wrapper itself. So we are looking for community engagement to help out with that the people who want to use V6 long term. And, you know, by saying the Livy CX stuff is deprecated. It just because we, we, you know, we don't have a maintainers to take care of it so just want to state like one more time that, you know, it doesn't have to be maybe necessarily deprecated somebody can kind of take responsibility over maintaining it but we don't have the incentive and the capacity in EBSA to support this component anymore. We are supporting the other ones and we strongly, strongly encourage to, you know, for the community members to rather work on the UNI FFI than investing in the Livy CX. We've been with the solution for quite a while and we are aware of the drawbacks associated. And the UNI FFI looks like much easier to develop and probably wouldn't be terribly a lot of effort to build out something similar on a UNI FFI as the Livy CX. And do you have already kind of roadmap or strategy to implement all in the required protocol for UNI FFI? No, there's not strategy. It's really just like encourage, you know, like, I can't find the right word, but Experimentation? No, like something like encouragement, but different word. Well, like endorsement, endorsement to build on the UNI FFI. But it's a community project. So, you know, we endorse community to move over there. It should be much better solution. But it's not to like dictate what people have to do. But at the same time, you know, we encourage it and but we don't have necessary resources to build it out, you know, to build it out ourselves as we are mostly focused on the like internal areas VCX. And then we have we have incentives to build the Node.js at the moment. So this is important for us, but we are looking for the community to help us with other stuff which might be important for them, which they can contribute. Yeah, but I think we can we can we can definitely help and assist, but we are looking for for contributors to to work on the UNI FFI. Okay, I'll move to the next items now. So we had the AATH like testing update by Mira. Mira is not on the call so I just I'll just briefly repeat what I remember so as I know Mira has synced up that the like latest code base with the latest version of the code base with the ARIES agent test harness. So there was some some older tests apparently failing so we kind of fixed it up restore the kind of original coverage and functionality. Additionally, he also tried to to add support at coverage for out of bands in areas mostly with ACAPI and FJ and we and he did succeed doing so for a few tests, I believe, but many of the tests in the test harness. Which relates to out of band protocol. They are they are like the connection less connection less type of message exchange. And that's something we are not supporting right now. So it's described in this RFC 0496. Basically, it's kind of for those who are not aware of it. There's a bit of a text for like transitioning from the old out of band kind of format all the way here this is kind of the final result final conclusion of the RFC so I'll just briefly take this opportunity to opportunity to to explain it. A lightly. So basically, where without with typical out of band invitation message, what you can do. Let's see it here. You can you can attach out of bed for example you can attach request presentation into your out of band invitation. Now this kind of proposes this kind of proposes alternative. First of all format but also functionality so basically you would create a request presentation message. And you would kind of use and but you would include this special this additional service decorator. And generally you would use this entire payload. The same way you would use out of band message so you probably render this as a QR code on a page or you know you embedded into a deep link button. But when the client receives this kind of message. Basically he wouldn't do any connection protocol there is not really any way to do so there's. There is not declaration of what connection protocols are supported. Instead, the client would simply answer this request presentation message by sending the response to the service as stated here. And that's it. So, so the client doesn't have to the connection at all so this can enable for faster. Faster workflows, although like I think arguably a little bit less safe. When this kind of support for this kind of out of band messages like this as implemented on mobile devices, basically don't have any anchoring to the ledger. So you cannot verify like the DID of the producer of this message and the service is just something something someone put in here but you know can you really trust this can you really send your personal data. To whoever produce this code and told you so to send it here. So, so it can be less safe. It's important in this kind of cases is important that the end user behind a mobile device understand the context of like a real world interaction. You know, like scanning this kind of thing on an official, you know, website of organization is probably fairly trustworthy, fairly trustworthy as opposed to scanning it on the street where you don't really know who is asking it and there is not even a way to verify it for the for the mobile device. On the other hand, so it can be kind of less safe, it can lead to phishing attacks, but it can be faster. So, I guess, for those for cases where the speed of the interaction is top priority and maybe security is not so important. So this kind of, I guess this kind of qr code can actually really enhance that use overall and calls and we don't currently implement this. I see the warning my connection is unstable. Can you hear me well guys. Okay. So, yeah, we don't currently implement this. And we have like a bunch of work around the messages create right now as we will touch on soon. So, I think this is this can be really useful. And it's, it's, it's covered extensively in the in the areas agent as harness. In order for us to increase our coverage we should actually implement this. And I believe it shouldn't be too difficult either it can lead to some generalization, I think of our API's. So, yeah, I think we can put this stuff on our backlog, but probably we don't have to address it right now as we are still busy with the messages and messages rework and this is sort of overlapping as it as it's related to messages as well. Any comments about about every status harness or just this RFC itself. Or questions. All right, I think we are good. So now we are getting to the working progress. So, we have messages create by Bogdan. I saw, I saw that you posted a long kind of message with the update. Unfortunately, I did not have time to like properly sit down and read through it. So maybe, and since you're in a meeting maybe you can kind of take us through it and through your latest findings Bogdan. Sure. I'll stop sharing so you can feel free to share. On it. This one. I guess it would be this. Can you see my screen. Yes. Okay, cool. All right, so, like I mentioned in the in the comments on the PR, and I even I even answered to this. We're just commented on this issue. We're just commented so thoroughly George about the message IDs and threading and how it's done incorrectly right now. And it's basically like you mainly touched on the connection protocol implementation but this actually spreads to quite everything else as well. And this is practically, like ever since I worked on the connection protocol refactor and state machines, I kind of realized that things are a bit too intertwined. And that makes them difficult to handle. So, and this is basically just as another observation of why you basically just talked about the connection protocol here because we treat threading as part of a protocol when it's in fact, not really related to the protocol itself. And, like, starting from that premise. It's basically just about the fact that so I'm mainly, I don't know, just for illustration purposes I'm talking about the threading decorator here mainly but it's actually related to all of all other decorators, and maybe just some other functionalities that we want to we want to support and it's very basically about separation of concerns, and how we can achieve that in a consistent manner and I really thought about this, like it's always been in the back of my head and I couldn't really, you know, put my finger on a solution. I think I came up with something that is fairly simple, but something that might help us achieve what we want to do. So, like in the threading, in the threading decorator, it's basically something that can be used in virtually any message. In some messages it's mandatory, in some messages it's optional, like you can have it or you cannot have it. And in some messages we don't even think about it at all, like we don't even need to consider. And I guess a good example of that would be, like when you have a mediator and you're just routing messages, you might not care from the mediator standpoint about threading on the forwarded messages. You might care about threading on the inner message, but the mediator doesn't get access to that, so it's not of any importance. Yeah, so maybe like George pointed out, in the connection protocol, for instance, there is some things that have to happen in terms of threading. So, you get a connection request and that basically can start the thread and the response will have to respond to use, reuse the idea of the request for threading. But the request itself can come maybe from an out of band invitation or as a result of an out of band invitation. I think there was some discussions at some point about the fact that that would also need some sort of thread. So, regardless, the idea is that with these fields being so intertwined with the actual messages, like the protocol part of the messages, it's very hard to have some consistent or generic way to handle them. So, my idea is to basically split the message in a way that would allow us to easily or more easily distribute the necessary data to different parts of the code. So, virtually any message can be represented by an ID. There is a type, but that's abstracted in our code because we only use that for conditional deserialization or serialization. So, it's not going to appear here, but it is present. So, there's the type, there's an ID. There is some content and by content, I mean the actual fields defined in the protocol, like what is needed from the protocol standpoint and the protocol implementation to drive state machine to its next state. So, in the request or response, for instance, you might need, what do we have here? There was some connection data stuff. Well, it's not here. I didn't add it. Anyway, but you might have some stuff that's literally part of the protocol. And then there's some external fields, which I call message decorators. So, decorators that are in the scope of the entire message, like thread or timing. There's that please acknowledge decorator. So, there are quite a few. And they're not really related to the content of the message as in the, like the protocol implementation or the state machine. They're basically used for other purposes. Maybe most of the time, sometimes maybe they are needed and that's fine and we can pass them around. But most of the time, they kind of have to be processed externally. And there's field decorators as well. And the reason this is separated is, I don't know, you can think of the localization decorator where you can have a message scope decorator, and then you can have some field decorators for certain fields. And the idea is that I honestly don't know, I haven't implemented something like that. And I know, I believe we don't have anything like that implemented in every PCX, but conceptually to be able to process everything consistently kind of need the field decorators to be processed along that message scope decorator. So the whole idea is just to be able to pass these things around without having to decompose the actual contents of the message. So, this is a very basic comparison of what this would look like for the request the connection request so this is pretty much what it looks like right now in the current implementation. Again, the type is abstracted away but the idea is here, we have some like actual content and then we have these decorators and they're all part of the same data structure. So taking this apart can be quite tricky and especially taking this apart for all, you know, all messages again can become quite tricky. And this is what the message like the generic message here would look like after monomorphization for the request for the connection request so again you get the ID type is abstracted away you have this request content, which now only contains this stuff. Which is basically what we need for the protocol itself and then we have some message decorators, which would be these and we can destructure these further and do whatever we want with them we can take the thread. If there is one do something with it we can take the timing decorator do something with it, while, serially or in parallel we can do something with the request content itself. Like if you consider something that would need an expiration. And we would use a timing decorator for that. You can basically just have two futures spawned and just do a select on them to get the one that finishes first we did the entire process expires where you get to process the message content as intended. So, that's pretty much about it the field decorators there's not really any meaningful ones here. And this is a type that I introduced I mean, this is probably not going to stay with that name but I jokingly called it that. So this is basically just the type that's going to serialize and deserialize to nothing. So basically just get ignored completely without having to make and give anything fail or make changes like that. Now, the idea of the field decorators. I mean, I don't necessarily like conceptually what the implementations do with the with those I find them pretty bad, but that's just a personal opinion. Now, there's no, like I wouldn't call it a strong rule about defining all the field decorators here. Because, like even in that attachment like in the auto band message you have those, you have that attachment, which is really part of the actual content like yeah it's a decorator on a field, but the, you cannot process the content without it. So that would, in my view, go in the content itself. Maybe stuff like, as I said, like a field localization or I know there's any other good examples, maybe those would go in here. So you can take them apart without touching the content that's required to drive the state machine. And the structuring and recomposing this stuff would be easy. The benefits would be again like you can take the thread out and create a reply to the thread or create a sub thread from it. And you get a new thread object and you thread struct, and that you pass along and generate build up your message and it's going to be built correctly without having to do manual digging through the message itself or anything like that. So it would become more consistent in terms of how we process this. Yeah, so that's, that's pretty much it. Here I pretty much mentioned that I don't really like the field decorators and how I would probably do them differently but in any case, I guess I also mentioned the fact that I guess a good candidate for having something in the field decorators is like a field decorator for localization, possibly along a message decorator, and you would most likely need to process those together so you need to be able to extract them in some way. Yeah, so that's that's pretty much it. That's pretty much what it entails and I think this would allow us a lot of other stuff, even this out of band messaging, like connection less messaging. We should be able to have things in a more. Easy to follow and easier to decompose structure and data structures. And that would mean we can be more generic about how we approach things and be more consistent about how we approach things, even across protocols, because that's pretty much the point to have the protocol agnostic stuff separate from the actual protocol specific stuff. And yeah, that's, that's pretty much it. Another point that maybe we can touch on briefly would be about, can you can you see my ID? I'm not sure if I shared just Chrome or. No, just your browser. Okay. Let me share this again. Here we go. Can you see it now? Yep. Cool. Okay. So one idea that occurred to me is how we would handle these message decorators internally work in the messages that we define and the protocols that we specify in the messages create or the messages for the protocols that we handle. And how most of the time these decorators so we have a fairly static list of decorators that we support. And I was thinking of a way to kind of approach this in a generic fashion, which can definitely be done and it would kind of boil down to something like this. And what this is is mainly just a structure that would take a generic for all the each decorator that we we take. And by default, they would again be like this completely ignored the data type. So they it's a zero size type it would get erased of compile time, because the alternative would be in the message decorators to basically generate one like for requests, one for a response, and so on and so forth, which can get a bit verbose. It's not, I don't know, not necessarily, it wouldn't necessarily be problematic. And in fact, it might have it's the advantage of being clearer, because this will have quite a few generics. And if you consider that maybe new decorators would get added in the future, then this list would increase. And even if we use some just aliases or stuff like that from a user point of view and just to showcase this basically wrote us here. The aliases are not really taken into consideration when you're using your ID or something like that. So, like you have this, we have the structure takes two generics and we destructure it, you pretty much get the actual types. So, in the message case, you destructure this. And this would be, this would have to be destructured as well and it would look like this with some actual types implemented here. And then you have to choose which ones to actually store and which ones to ignore, if any of them are maybe the dummy type. It would technically result in a little less code, at least compiled code, even less code to like from, from a maintainability point of view because it's just this one type. And due to monomorphization, it would result in like common decorator pattern implementations would boil down to the same type. I don't know if it's really worth it in terms of readability though, because then you have to keep track of what you passed here, like what actual decorators are defined to some type, and so on and so forth. I'm not sure if this is an obstruction, we might want to do it. I explored the idea but I'm not necessarily impressed by what we can achieve with it. So maybe in terms of readability, it might be worth just having to just defining types for each message we use, and pass the decorators we need there pretty much just like this, and just use this type. And this can be easily tracked to the actual type implementation, you see you have this, there's no black magic happening under the hood, so you just destructure it to these two things and that's it. And if you add something new, the compiler will yell at you that you need to handle the structuring completely, whereas here you would probably just ignore some stuff, so again, might not be ideal. But I think now that I see this, I guess two solution compared, I also agree that probably better ways to go with a bit more like code duplication rather than one. It would be easier for maybe newcomers to also read the code when the generics can be scary, when there's too much of it. It will make it easier for us as well. I honestly am sure that even if I write this two months from now I'm still going to get confused about what exactly this means and stuff like that. It would just be too little of a benefit for too abstract of a concept. But yeah, that's pretty much it. Not to mention that you would have to sort of handle the serialization in some way and you would need some sort of trait that you implement to basically be able to skip the serialization if needed. You would have to implement that for decorators and if they're optional do it for that as well. It might not be the best thing ever. Maybe even from a compile time. I even forgot about the trait. It might even boil down to more or less the same amount of code. So yeah, I would just go with the old fashioned way of just defining the structure for each individual message, putting the decorators there, everything is clear as day and that's it. But yeah, that's pretty much the idea. Now, on the other hand, I don't know, is it worth like I'm not also too convinced about this as in passing this generic here as well? Is it worth having this separate since we just want to destructure this anyway? Maybe we could just put the decorators together and just handle them like that. It would also be an idea. Yeah, the thing is, I guess we are not really using the, in practice we are not really using the field decorators in any sort of APIs or we don't have the multi language support stuff currently. We just cannot, well the field decorators are, that's one of the main use cases you understand for the field decorators. So maybe it's better to go with like a simpler solution so we wouldn't, I don't know, like prematurely try to generalize too much without understanding and seeing how what would be the ideal API for them and the layout and structure. So, I mean, ultimately, technically we use field decorators. And this is exactly why I think they're just badly designed, like even the attachments and stuff like that, the services, like there's all that stuff that is practically a decorator, but the, I guess just the definition of what a field decorator is, is not particularly great in any case. The field decorator is like you have a some field foobar and then you have foobar tilde something right so we have like kind of two versions. Not even that you, you can literally just have the decorated field without the field and that is present across the code base and across the RFCs like there are multiple instances, even for requests or stuff like that request and then, you know, the attach decorator. So what that attachment decorator without an actual request field. So again, it's really a, I don't know, weird thing. But the point is that ultimately it all boils down to things that we want to have inside the message content as in the protocol specific content or the state machine specific content because technically the protocols specify the decorators to but the state machine specific content and the non state machine specific content. And I believe we can technically just merge those two together in a decorators field and just put whatever we need there like even if you have because they don't overlap right so even if you have something like the message scope localization decorator and then you have a field decorator on some field. Like I mentioned in the in the comment here, you can have both of those together in that same data structure and then you can deserialize them, I guess. Maybe one I one concept would be I don't remember specifically and I will have to look it up. I'm not sure if the field decorators can be found within like nested fields. As in, I honestly don't remember. I think I've seen something about localization decorator. I don't remember for sure. But nevertheless, message type what I don't remember necessarily but you you see my point right you know do you understand what I mean, because then things get a bit trickier. I think let's let's take this maybe to the like discussion on a on a on a github so we have 15 minutes left we can cover the rest of them. Yeah, so that's pretty much the progress. We'll think about it some more feel free to comment on the PR, you know review it and so on, and we can further discuss this. Mm hmm. That sounds good. Thank you. It was it was very useful and pretty pretty thorough presentation. So okay now is for the next point of the upcoming work so I saw the I saw you George you had the PR about the feature flagging VDR tools. I saw it's draft so I guess just a question like it's pretty clear what it does. The question is like how much effort is there left you know what are facing some challenges and I guess this was more just to start a conversation about whether it's something that areas vcs wants to have. I think I think we might have talked about this concept before. Did you understand what I was trying to get across with this so far. Yeah, yeah to basically select you either use the bdr tools or in in the for the like ledger interactions right so you don't bring to dependencies. Simultaneously. Yeah, yeah, exactly. And like, I think originally I was thinking that these server these feature flags would allow us to sort of bypass some of the dependency conflicts between areas as car and vdr tools. But that's not the case because you know when you're working on the areas vcs workspace your cargo lock still tries to combine both of them and and freaks out. But at least with this feature flag consumers can sort of pick whether they want the vdr tools implementation of a profile. Or whether they want you know the modular dependencies for lack of a better term version of the profile. And then you know they don't have to drag in the entire set of dependencies for both. Yeah, so this initial PR was just putting that flag around putting the flag around the vdr tools profile. And it's fairly straightforward. There shouldn't really be too many other changes required. Right. Yeah. But is there is there like, if you use this, is it really possible to get like rid of the live vdr tools dependency because there's also, oh, well if you use an Oscar yet and you pretty much have everything. Right, right, right. Because I was about to say like, oh, but you still need the wallet, but that's the point with Oscar if you are trying to stop using the live vdr tools wallet. Yeah, so we definitely still need to fix the areas as car dependency conflicts in the future. But putting this feature flag in right now would let consumers basically import areas vcs into their project without the live vdr tools dependencies, and then you know, put in whatever profile they want. It could be an in memory one or it could be based off areas as car. Yeah, that's pretty cool. It's pretty cool. So now it's a draft so I'll have a look but I'll be I'll be waiting for the final final final version when it's ready for review. And we can review. Yeah, the only thing that's keeping it in a draft at the moment is there is. So I guess the refactor I did a while ago was to separate out that that indie sub module from being used basically anywhere except for the pro indie profile implementation. But there is still a couple references to that indie sub module throughout the code. The main reason for that is we use Lib Indie mocks in a few places. But I think that could be replaced because it's not really Lib Indie specific. It could be just a generic mocks structure or mocking rethought entirely. I'll have a look and I'll try to see, try to better understand each challenge so I can have some useful input on it as well. Cool. Thank you. Okay, let's let's go further. Next up, this is like a task I'm currently working on actually, and it's about basically get no not actually not me. It's a it's me that was working on this or will be working on this soon. It's getting rid of the legacy kind of methods for dealing for writing service on the ledger reading it from the ledger so basically this right endpoint legacy and parse legacy endpoint atrip. This is some historical basically any any new users by default are using the proper deep soft method implementation where they're reading endpoint attribute from the ledger and very key associated for that particular d ID on the ledger as busy pinkies. Yeah, just getting rid of the old code. So this this should be probably done through our like next couple days. And yeah that brings us to the end. So I wanted to know that such as that we do a release. And there was this out of band serialization this realization fix which is also technically a breaking change in a particular scenario, although I don't think it impacts like any of our users. Still, still, it's good to have a rather more frequent and less frequent releases and make it like more consumable smaller smaller steps. And previously we had the release after one month so we just kind of enhance our release morale and try to do more often at least at least at least once, once in two weeks or so. Next up I saw a post from Steven current on this mentor to projects. Which we can like the hyper ledger. Hyper ledger projects can kind of like apply for a joint. It would entail like some mentoring some people who want to contribute kind of like, you know, I guess, I know it's called it's the right word is intern, or it just like mentee, but that's the idea. So I think it will be cool if we join it. And we have some, some, somebody, somebody wants to maybe learn or us doesn't have to be like experienced developer but I think there's plenty of work, people could work on. Even there's like, like, a bunch of ideas for the projects which could be built on top of areas vcs which will be also I think good, good candidates like the in this mentee doesn't necessarily have to work directly in the areas vcs code base, but could be working on top of it. And there's a few, like, project ideas here written on our Viki page in on the root page. Yeah, it's listed here like very far agent or credential for said or to implement the mediator, literally the mediator agent, implementing the pickup protocols. Using a Vcs or just as we recently had those like idea for the implement mediator client who supports pickup protocol, or even more relevant maybe like these days maybe the one of the most useful places to help out would be the uni f5 rapper. If we can find a person who wants to kind of like improve it work on it that will be pretty awesome and I think it will be worth spending spending time, like, hoping on boarding someone on the project if we can get some helping hand in return. Okay, next item as a. Oh yeah the protocol threading behavior that pretty much kind of bring us the end of the meeting probably. And it's the issue you created George. I'm very very thoroughly described about the like some issues we have in the current implementation with with threading. I'm not exactly sure like what the strategy to take you mentioned like, I agree like this. There's stuff like we should be probably changed and like given a extra thoughts and like I cannot. I'm not able to address personally individually, each of these suggested points right now. But it's more thinking about how to approach it in terms of like currently we are. Jordan Bogdan is working on the messages create so I don't know should we kind of wait for that to settle, I guess, we should. Yes. So the the whole idea would be that having the thread and even the idea outside of the state machine related stuff would allow us to reply like create the reply thread or sub thread or just a new thread from an implicit thread outside of the state machine or the state machine handling code and basically those there would be some methods on the on the thread object and the thread struct and stuff like that and that would provide a consistent manner of creating these threads. Then when we go back to the state machines, we simply have to call some methods and we get the correct thread that would be the idea behind it. You can invest the time in changing and we're fixing this in its current state. But it's probably gonna like it most definitely will be, you know, factored out when with the new messages create so that's why I wanted to point out, because we have to apply this sort of mentality to all the in the same approach to all the protocols. Yeah, yeah, that sounds right. Yep. Okay, well, I just kind of say that it's like super useful how like you listed out all the issues. It's something we can now that it like really perfectly aligns with the stuff going on with like bogdan's rework is this is something we can now use when one will be like synchronizing the integrating the new implementation with the state machines I guess we can this is this is something we can like yeah anchor like use to to make sure that everything's right and we don't have to make any additional like fixes afterwards. Yeah, just thank you so much for investing time into into, you know, looking into this. Yeah, yeah, good. Bogdan Dino point three in here would be addressed by the messages create. It's about how we like create the response message early before sending it out. The messages create itself, because it doesn't handle the protocol state machines, but after the messages create is done. I will revisit the connection protocol as well, and then move on to the other state machines and yes we will. We will change this so I believe that we also had this short exchange on discord about this. I'm on the same page as you are I think it should be, you know, set the set differently. Fantastic. Should I close this issue or no I think we can keep it open. I think until until the issues are like, basically the stuff you listed here is is addressed one way or the other I think we can keep it open I think it's. All right. I think I had something to say. Oh, just a very like a small note. I had a technical small note. I believe that this test ID you mentioned here, like if you try to maybe you try to check how the behavior in the tests. And you saw this test ID but I believe this is only being applied when you are like literally literally running the tests but then behave current implementation cannot distinguish to implementations for the default message ID. So when you're running in the test, it would generate this test ID for IDs. But when you're actually running like, you know, normal code, it generates you ID. Right. Okay. Yeah, I haven't actually tried it. In reality, I was just looking at the default method. Yeah, yeah, it's this kind of uglyness and I don't like it, but it will be again address with book downs book downs changes that there's essentially like two implementations for that. Right. Kind of message has like two impulse and one is for the test, you know, when you're running in the test, the other one is when you're compiling just proper code. So then, and I don't like it because then you are literally testing different codes than what is actually running production. The testing code generates this but that real code generate something else and obviously it's also confusing since since this this is how easy for you it was to get confused. But, but it will be addressed so we'll get afraid of that as well. Okay, great. All right. Rafael to leave. Rafael for joining us. I see that he disconnected already. Nevertheless, I think we are also at the end of the meeting. It's pretty much it. I have one question. Is you have time for sure. I was looking at some of the issues in the issue list. And one of them was about upgrading SQL X, I believe. Yeah, three three. I was wondering if you'd looked at that. I did look at that like kind of briefly and I think. Yeah, I know that I looked at it to the degree that I figured that it should actually like solve. It should probably solve the issues with the. I'm not sure. I'm not 100% sure if all of them, but it should solve at least some of the dependency conflicts with the areas Oscar war. Yeah, yeah, it almost fixes them all. There's still some remaining issues in Ursa and some of the locked dependencies there, but ours has had some activity recently. I think that fixes it, but they haven't merged that in yet. That'll be good. Right. Yeah, but I, and one additional I have here is that we've looked into it in the past, not myself, but there was some issue with Android, I believe, so it was like this sort of V6 issue it was causing Android, but perhaps what we could do. We could maybe, or first we can simply try to upgrade it. But now that like leave V6 is kind of deprecated we could for it maybe we could try. I'm not sure if it's possible that I suppose we could try to like have one version of SQL X. But it's all the way in the VDR tools. I was thinking that the like leave VCX build would use different version of SQL X. Then the default build based on some feature flags or something like that, but given given that the SQL X is like three layers deep under live VCX that might be maybe it's doable, but maybe be the awkward. I'm not sure. So you're saying that SQL X, the most recent version of it has issues with Android. Is that, is that right? Now in this case of it. There was something about Android, but honestly, I don't really remember what was the issue, but I think you know it might not be necessarily just Android itself maybe it was simply the live VCX Android build. Not necessarily, you know, if you use areas V6 for me like unified and the upgrade SQL X. I don't mean to say that you'll run into issues, maybe I think maybe it was just with the like live VCX kind of Android build. Right. Okay, okay. But yeah, it, I didn't, I didn't try to upgrade it and get it running. So I don't have like the technical results, but we tried a long time ago there was some complications we didn't see it at the time as a high priority. Those before all this like a resource car, and we just dropped it then so we didn't proceed further, proceed further. The issue come up when you're running tests for Android devices. Like if I were to, if I were to make a PR that just upgrades SQL X will I notice the problem in the testing. If, if Android's failing. Testing, like with with your infrastructure, like with your code or remain just in the CI of. Yeah, let the CI run the Android tests. Yeah, I suppose, I suppose it should. I'm not I'm not 100% sure it was a long, long time ago. Okay, cool. Okay guys so if there's nothing else, anything else for my side. Oh good. Okay guys, so thank you for, thank you for joining and let's talk again next week. Great, thank you. Bye bye.