 Hi George. Hey, how are you? How's it going? Yeah, good. Thank you. How about you? Yeah, I can't complain. It's been almost a year since we started doing these, by the way. Oh, really? Wow. I mean, it's two more months, but still it's almost. Yeah, nearly. Are we going to have a special episode? Yeah, we should. We should make something. Everybody needs to connect with a glass of champagne, and we all got it. Turn on the cameras to the proof of champagne. Yeah, I know a little bit. Hi, Nanny. Nanny, you're asking if everybody's suddenly mute. I don't know. It was just like coincidence. We were just talking about it. It just happened to that we were on mute. Right. Okay. Sorry. I couldn't hear anything. So I thought is there a problem with my audio system or if you're actually done quiet. It just happened. All right. I think we can get started. So welcome to August 3rd, 2020, RUZ-6 Coventicle. Hyperlander antitrust policy notice is in effect displayed on the screen. And well, I guess we can just get right into it. So I prepared some agenda. Do guys, anyone has any item you would like to add here? Anything you want to discuss? That's not already on the list. Not from me. All right. So I think that's really good. So, yeah, we can start with the mentorship as usual. We have an ion on the call becoming our usual visitor. It's great to have you here. Nanny, would you like to give a brief update like you usually do about what you've been up to and how you're progressing? Yeah, sure. I'll give a small update. So this week, what I had decided is to shift from working on the test server to actually getting and digging inside the AV6 code. So the previous week we had initialized, we had basically taken some code and initialized AV6 as a dependency on the server. So this week, I wanted to try to actually initialize a wallet and start working with BCX. So I did hit some roadblocks when I'm trying to initialize is the wallet. I didn't know exactly what wallet conflict is. So I saw that the initialization function, it requires some parameters like wallet config, any config and stuff like that. So I don't actually know what to use that. So that is kind of postponed a bit now. So by looking into the solutions for this, I just took a look through the V6 server and I found George's simple relay. In AV6, there's a tools directory and in that there's a simple message relay. I think it was just two weeks ago. So I took a look through that and yes, it seems to be an HTTP mediator sort of thing. Yeah, I thought that maybe we'll have AV6-related stuff, but it is also based on HTTP. So I decided that I can maybe take inspiration from that. I'm thinking of wrapping the mediator, the test mediator that I'm writing, into a usable form so that it can act as a demo-able thing. So the difference between that relay and the repository now? Sorry. Is it just me having connection issues? Like it uses the same endpoints that are there in the pickup protocol docs. So I think this would be a good demo for the mediator. And the next steps are to see how the wallet is created in AV6 tests. So if you could suggest some particular test which I can take a look at for generating the wallet, then yeah, that will speed things up. That's my current status now. So this week the goal is to wrap up the test mediator into a demo-able form and to get started with creating a wallet. Yeah, that's about it. It was a bit difficult. I can hear you. Yeah, I can hear you, but it's kind of clobbery. There was lots of words being dropped on my side. George, you're experiencing the same issue? Yeah, same. I think also the audio is coming through pretty late because Niam was sending those messages as they were still talking. Yeah, it feels like there's something wrong, not just with Niam's connection, but there was something maybe with Zoom. I'm not sure. Yeah, anyway, sorry, Niam. It was hard to understand, actually, fully. But I get it that you were taking a look, trying to get inspired, how to initialize the wallet, and yeah, trying to get it up and running. So yeah, that's a good start somewhere. So sorry, maybe you said this, but have you actually managed to create a wallet in the end, or are you still playing with that? No, I haven't managed to get the wallet created because it asks for indie config and wallet config and all those configurations, which I don't currently know what to actually give it. So yeah, I'm stuck on that part. So in summary, I'll just summarize what I had said in the last minute. Okay, so in summary, I'm trying to wrap up the test mediator into a demoable form so that it can act as an HTTP endpoint and you can send and pick up messages and it'll respond. So it'll be a pick up protocol conforming demo mediator, which doesn't work on Ares messages, but over HTTP, basically. Yeah, so that's right. The first part, I intend to finish the speech. And the second part is to do this, that is create the wallet. For that, I'm thinking of looking into the tests. But yes, if... Yeah, right. There was some drop towards the end, but I think we got most of it. And I just wanted to note that you can have a look at Ares VCX slash test slash MySQL wallet test. And it's essentially the config you would use to initialize the wallet with MySQL wallet implementation. It's using some builder pattern here. So you don't exactly see the JSON, but perhaps if you run this test and just put some sort of console log here and print out this config wallet in its final form, you will see the whole JSON kind of document for the configuration document. So you can have a look at that. All right, let's move on. So we don't have Slapnail. So I guess we just skip over this one. Maybe, George, I know that there's the PR open from Slapnail. Is it soon to be merged? Or what's the state of that currently? Do you know? Yeah, the goal is to have that PR ready before next Monday. Yeah. Right. All right. Okay. And then moving on to our usual topics. So we had 0.571 release, which the main reason for this release was because we found that the last release 0.57.0 was faulty for iOS and Android builds. It would crash in runtime upon calling a basic functions very early on. So this should fix the problem. And there was also squashed in some refactoring and some minor things. But the main edition here was the fix for the iOS and Java Android. Yeah. And then we've also done within that release refactoring of features. So you can again run based on George's last week remark that we kind of had this this reverted some behavior and it was impossible to compile with no default features. We we fixed this and George you are unmuted. Would you like to comment something on this? Oh, sorry. I just left myself unmuted. I just thought you are getting ready to say something. Right. Yeah. So this has been merged. It also has like some other refactoring included in terms of features to make it a bit easier to work with and even understand. Yeah. And then we have a whole bunch of things in progress. So the exchange protocol, it's a long story, but good stuff is coming out of it. There is like a number of people kind of, for now, PRs in a draft state. I'm not sure. We don't have mirror on the call. So I'm not sure what is needed for these things to be merged, to transition into ready state, but I suppose not too much. Yeah. And then the exchange protocol, it's in progress. It's kind of relates, I guess, a lot to another task we are doing in parallel with prototyping the new state mission approach. So I know that Miro is not fully satisfied with how the exchange protocol looks like right now. And I think that perhaps if we combine the outcomes of the 915, the new state mission approach and the kind of implementation work done in Miro's branch, then something really nice can come out of it. Well, and then in progress, we have also removal of VDR tools larger client in favor of IndividuR. That's close to, I suppose, close to being ready for review. I'm still doing like some final touches. I'm testing in like on our internal, with our internal services, getting some feedback out of it and then kind of iterating on the work with some like further fixes and improvements based on my findings. So this is almost ready. It removes the entire pool and ledger portion of the code from VDR tools. Yeah. But in general, it works good. I found that IndividuR is a bit slower than the original VDR tools implementation. I'm not exactly sure why, but we can investigate it further. Nevertheless, IndividuR is where the communities and where the support is. So it's still, even though the performance seems a bit slower, I think it's still definitely the right move forward. Any comments on this one? As you're removing parts of VDR tools, are you sort of updating any of the cargo tomos as well to like remove extra dependencies that VDR tools might have? Or are you sort of removing like whole crates from VDR tools at time? Right. So for now, I just deleted all of the code. And yeah, that's a good point. Actually, I didn't remove the dependencies. That's good point. And it should be possible because I mean, you know, we're going to need zero MQ stuff. Although that might be kind of the only dependency. I'm not sure there's any more. But nevertheless, I know that right now, the way that the cargo tomo looks like in areas VCX, there's some improvements to be done here. Because what was it? Oh, yeah, right. Somehow indirectly, currently, we are bringing in the VDR tools. I think that was some conversation we had together, George, in that feature bar, right? Yeah. Yeah, it's in core. We're bringing in like the error types from in the API types or something like that. Yeah. So I think we can just kind of extract all those like it's just small, it's just tiny portion of VDR tools we are needing there, I think. So we can just kind of extract it out and minimize the dependency impact from that. So then if you are using the fully modular configuration of various VCX, then you wouldn't have to carry all the baggage from VDR tools. Yes. I started working on it like locally. But it's just in infancy as I'm still trying to finish this one off first, but that will follow up. Yeah. And well, then I'll leave comments about this one towards the end. Just want to know that I restored this ancient PR, removing open cell dependency. I found yesterday both of you guys have been commenting on this throughout the year, kind of checking in what's happening with this. And yeah, I think we can, this seems like it's passing, so probably you can get this merged and get rid of the open cell dependency here. Well, and lastly, since we fixed the kind of feature setup in even the last week, I think we can now bring back the migration for Node.js, which was running to some dependency issues with VDR tools. And so one more item here. So we have this prototyping ongoing for quite a while. It's been a rather journey, lots of comments, all discussions and calls. But I believe we are reaching somewhere further. So this was my last comment here. Basically, I think I like it in general. It just, one thing I'm reserved towards is the loading of the state machines. And that was kind of my last remark here. And I'll book them. What's your latest take on this? What's your thoughts? Share with us. That we're not even close to anything ready. Yeah, I saw the comments you left. Honestly, I don't really follow that well. So removing the get method from this, the interface kind of makes it somewhat useless. You are right about the... I try to kind of do a demo, kind of have a test that will just start the connection between two parties and have them communicate with each other. And indeed, there is a problem with the interface as it is right now. And I guess that was the initial idea with having the extra method for resolving the ID somehow. But anyway, taking it step by step, maybe commenting on this here. I didn't comment yet because I'm on the PR because I thought I was expecting that we're probably going to be talking here. So yeah, the naming of the associated type is just a name. It's probably not great. But yeah, by the... I was thinking mainly about just something that you can use to to deterministically pull out the state machine out of your database or storage. Then I don't know about these points that you made, like the efficiency concern, especially about having... If you're using a thread ID and you're having the state machine ID separately, okay, you would have to do some update join. But even if you don't use the interface, you would still have to do that. And I'm not really worried about an update join in terms of databases. They should be good at that kind of stuff. That's what they were made for. Then I also don't know about the generality. Yeah, it's an interface that we use. So I don't necessarily even think that consumers would care as much about how we use it. They can go through the code if they're really interested in that. The indirection... No, so can I stop you here? The users will need to implement the trades, right? The implementation of trades depends on how they're going to be using the handler. It might be big too much. What do you mean by how they're going to be using the handler? Yeah, because what you implement here depends on what you are intent to... Let me open this up. Let's see, for example, like some sort of handler. Here's the... Okay, handler response, right? Handler response. So when you pass the SMID, so when you're implementing the storage implementation, the get and the inputs and whatnot, then what ID is going to be depends what you decided to be when you are calling the handler function. So they decide... I don't see a problem with that. Okay, they decide what they call the handlers with, which is perfectly normal. It's in their control basically. Then they define the interface based on that as well, which again is in their control. How is that... I don't really see how that's a problem. No, it seems like... You're saying that it's complicated to understand that when you define the interface and you set the associated type to something to kind of make the connection that the associated type that you said there is the one that you're going to be using in the handlers. I don't know, this level of indirection, when you want to explain how to implement this, you need to refer to when you need to develop... The ID is going to be what you call some another function elsewhere in the codebase with. I find it strange because... I don't honestly, but I actually find it pretty straightforward. I mean, obviously, it might require some comments just to get them to understand what's the interface actually used for, maybe some more explanations. But yeah, it has an associated type and you use that as a function argument in the handlers. To me, it seems maybe not the most intuitive thing ever, but it definitely doesn't seem like something that's very hard to track or to call it some sort of cognitive indirection. All right, well, Anna, I find... So we can agree to disagree? And then... Yeah, well, you wanted to kind of address those points, so you went through general... Yeah, so inconsistency one. So you're saying that developers might have multiple implementations for these traits, each with a different strategy, and that will get confusing for them. So you're basically saying that the code that they write will be confusing for them. No, no, no, because sometimes you might want to get... Sometimes you... I don't know exact situation right now. And so I'm not sure how often it's going to be happening, but apparently it's the kind of flexibility... Since we are not defining what this actually is, that's what we are trying to offer developers, this versatility and generality, like it can be anything. And presumably, maybe for different message types or whatnot, maybe sometimes you want to call it with a thread ID, and sometimes you want to look at that based on some sort of primary key. Then you need to have two implementations of your storage. Why couldn't you use the ID as an enum instead? By all means, you can have two implementations of the storage, but you might as well have the idea of using an enum or something like that and kind of act on that. All right, well then... It ends up having one implementation that will have two, I don't know, let's say two or X kind of sub variants underneath that. I don't know, I find it like a lot of gymnastics for... I really don't see value actually in it. The user can just get it, just get the state machine on their own, pass it in there, and they don't have to wonder about what the ID is and do all these different variants, different variants of the ID. The thing is that even if you take out the get method, Patrick, you're still stuck with the other two, and they still have to kind of function the same way. Just that you have somewhat of an inconsistency between... You can actually end up with some inconsistency between what what signature get will have and what it will use in contrast to what the other methods in the trade will use, because I think you're right. If you remove the get from the trade and just leave it to the users to pull out the state machines and just pass them to the handlers, okay, it's technically from a point of view, we're more interested. The main goal of this was to kind of abstract over working with the return type of the state machines, not necessarily pulling out the state machines themselves, but you're still stuck with the other side of the of the story. I don't think so, because once you do this, once you pass in the state machine and you are not doing the get, then you can de-generalize this ID parameter, and you can simply say, because under assumption that developers typically when they store data and state machines, they typically assign this record some sort of ID, I mean, any database, like you always have some sort of ID. And so then for the put methods, since you already have the state machine, for sure you also have the ID of that state machine, not message ID, not thread ID, not anything else, just some sort of like primary key which identifies the record. And then we can just say like, hey, when you're implementing the put method, the ID parameter, it's the primary ID of the storage. And it's that simple, you don't have to explain them that it can be this or that, it's just the ID, and they just have to, in order to store the new version of the state machine, they just look it up based on the key, whether it's like name of a file or primary key or SQL, you know, something like that. It's a lot easier. But the problem that I see with that is that it can cause inconsistency, especially if we take the example that you've been pointing out about people starting out with the thread ID. And based on that, they want to look in database and retrieve a state machine, for instance. So, but now they don't have the thread ID, like directly associated with the state machine, that the thread ID might be associated with the state machine ID. And that state machine ID can give you the state machine itself. Then, so you kind of need to use that thread ID, maybe do a join, get the state machine, JSON, deserialize it, whatever, everything is cool. But then, if you separate, if you split the interface, or you take the retrieval part out of it, then, okay, they do the get outside, where they might do other stuff. For instance, they start out with a thread ID, and then they end up with a state machine ID, you know, that they use to retrieve the state machine. But then when they, when we have to put the state machines back using the interface, then if they use the state machine ID, it might be possible that the thread ID, that some operations would have to happen on the thread ID as well, to maybe link them together again, or something like that, especially for like new state machines that we would create. So then, that operation is either left out entirely or awkwardly put in there, because it wouldn't be consistent with kind of the, I don't know, it doesn't necessarily make that much sense in terms of the arguments, the function signatures anymore, because if you're using the state machine ID as your associated type, then that's you all, that's all you kind of have to work with. Whereas if maybe we rename that associated type and kind of have, I think I even did, I called it state machine info or something like that, but if it's basically more like just an arbitrary type, arbitrary type that you use to deterministically select a state machine or deterministically insert a state machine, then it can be a collection of things. And that gives you more room to approach this, however it's necessary, and however you need to. So, so the concern, so your concern is that, like when you, that it will cost that the like the loading and storing. Yeah, I think that taking the get out is practically more confusing than letting it in, or than that associated type. I mean, associated type can still stay because like ID, somebody might use like some sort of type to you ID and somebody string, whatever. I'm fine with the associated type, but rather just the, you know, the definition of what it actually and so, so if I understand, if I'm following our concern is that when you remove the get then you kind of have the, you kind of, you might end up with having the fetching and storing behaving in different sides of the code, different parts of the code base, and it's kind of not together, stick together, or maybe I didn't fully, fully get. Yeah, so when you, when you do a get, for instance, you might have to get that thread ID and do a join to get the state machine because you need to work with that state machine ID, but then it's not intuitive if the get is not in the same interface and you just have the put operations. It's not intuitive that the associated type is really meant to also incorporate that thread ID, which you might have to work with. Why would it incorporate, why would the put incorporate thread ID? What if you create a new thing, or what if it's the start of a protocol, you just got a connection request or something or proof presentation or credential or whatever. You have to create a state machine or we create a state machine and then you basically have to also link all these pieces together in some organized manner, like the state machine ID to the thread ID. And this is a new state machine. You don't have anything in your database about it up until now. So you kind of have to set things right. Okay, so when it is, when you are creating new state machine, like accept invitation, okay, let me think about second. Yeah, so you create it and you are not passing it in my model, you wouldn't be passing the ID, you wouldn't be, yeah, and you don't have the get operation, but you are doing put, right? So I know for that kind of cases, you just need to let the caller know, you'd have to ask the caller to generate the ID for you. But yeah, basically specific, you would, okay, so in that case, I would suggest that you would pass in the ID, and again, it will be not like some sort of arbitrary, like generic ID, it will be just the primary key for what it is, what it means in your storage. And it would get stored under the ID. So as far as you get okay from that transition and invitation was accepted, then you know, like the handler has created a new record for you instead of updating the existing one. Because yeah, as you said, I understand that the main value of this, why we deal with this storage and these interfaces is to show the user away from those transition results, just kind of store it for him. And he only needs to deal with like simpler return types from the function. And the fact that he has to load the state machine on his own or or maybe he just keeps it in a memory or would not like we don't care where he keeps it. But we do care. We don't care what it's coming from, but if it's coming from somewhere, it's probably going to go into the same place. So I'd say we kind of care a bit. But yeah, I guess you kind of came to the same conclusion about the fact that we need to have the ability to kind of generate the ID on demand. So that might need its own interface in some fashion. I don't know. But yeah, ultimately, you cannot ask for the user to give you an ID for the state machine in the handler is just weird. Like, hey, I'm going to process this invitation, I'm going to generate the connection request for you. Just in case that succeeds, how about you give me an ID that I can use to store it with some sort of ID generator and then let him know exactly that would be yes, that would be better. I don't really know exactly how that works. That's basically why where I got stuck with the the example, the example test. And yeah, it just occurred to me why we had that resolve ID function in the interface previously. But anyway, that also kind of deserves its own organized matter of dealing with this, because I'm not sure exactly how it should look like or what it should look like and what it what arguments it should be processing. And it's also a matter of kind of the only things in the sense that to kind of determine the state machine and its ID, whatever you might have to kind of process the message in some manner, or maybe particularly the thread. But it begs the question of what exactly can you use? Or like, should we limit ourselves to kind of resolve the ID from the thread? Would the users be using something else? They might. Yeah, so that's where I'm stuck anyway. But I think the get should stay in the interface. I don't really see any sort of value in abstracting them and taking that out and letting them deal with it. In a more chaotic manner, I think this kind of keeps the interface together. And it makes more sense that so we have this operation with these arguments that you use to take a state machine and give it to us. And then you have these other functions, which where we give you a state machine. And you just put it back or put it wherever you want. And I think it's like this kind of mirror, mirror like behavior is easier to grasp than, yeah, we just deal with putting your state machine somewhere. Yeah, I mean, the estimate, like, asymmetric, asymmetricity? Yeah, the asymmetry of my suggestion is something I'm aware of. And I don't like at the same time, at the same time, you know, I have counter arguments for the, for the SES solution. And especially with the like, you know, I call it efficiency, called it like efficiency concern, but I just really find a little bit like, I don't know, cold, cold smell, like conceptual cold smell, like, you load up the state machine and like, for sure, you have the idea of it, you could just save it directly. But instead, you what? What do you mean? I really, I really don't kind of get because what I mean is that, oh, here, what I mean is that when you're writing this, and let's say you decide that, you know, let's say that you decide that this ID for you based on your context of calling handlers, that for you, the ID argument actually means thread ID, because... Okay, I think I got it. So you're basically saying that once you generate the new state of the state machine, you should be having its ID by then. So then you can just put it back because it's technically linked to whatever else needs to happen, like to whatever else it needs to be linked to, like the thread ID. I think so, but my... Sorry, just one thing. So like, you know, once you decide, once you kind of come, you kind of start with the get method and here you come into something, you decide like, okay, the ID is gonna be, it's gonna be thread ID, actually, what this means for me, based on how I'm calling the handlers. Then it also means that the same definition applies to all of these. So it's also message, you know, thread ID, this is also thread ID. So then when you're gonna be storing the state machine, you need to... When you're gonna implement this, you need to keep that in mind. You actually have to... Even though you actually have the state machine with some primary ID on it, you will end up having to write updates which will involve joining and it's just unnecessary. It didn't have to do it. You have the IDs and it's kind of more complicated. I mean, I wish I could just... As a implementer, I wish I could just write like, you know, like... So like, actually, right. So, but this is what I was aiming to solve in the beginning and which I'm probably going back to in terms of having some sort of ID resolver. Because then, like, the point of the entire thing was to kind of have a mechanism to sort of determine the ID or we could even just split these things apart. I don't know. But like, have some arguments for retrieving the state machine and just the ID or whatever, like a bare bones string or ID, whatever associated type. Something simple, like you said, just the primary key in the database that could be used. So then, you wouldn't have this separation between... Like, you wouldn't have to do that join when you update the state machine. I wouldn't necessarily be that concerned about that, but it's a fair point. Yeah, so I'm not saying this is perfect, but I definitely don't think taking the get out is the way to go. If anything, that's probably going to create more confusion. I think we kind of need a mechanism to determine... To have this ID resolution, like the state machine ID resolution. So then, based on some input, maybe the message, maybe some other stuff, we can even generate the ID on demand when we need to put a state machine into storage. And we can also use it to maybe do a direct retrieve, you know, like a direct get, such as the one that's there to use the thread ID to join get the state machine, or maybe also just, like I said, generate the ID for a put operation. And then, when you want to do the store operations, you just use the ID directly in the state machine instead of going through hoops. But then, the thing with that is, it still kind of boils down to the fact that if you have this linking, for instance, between thread IDs and state machine IDs, when you put a new state machine in, you need to insert it, you know, you need to insert the record in that thread ID mapping too, because otherwise, you have your state machine somewhere in the database, but it's in limbo and you cannot find it. So, that's what I don't really get. Like, you cannot be completely agnostic, I guess. Maybe we could have a separate operation for that, you know, like put new state machine, you know. So, it's a specific operation for a state machine that's like, you know, sort of a beginning of a protocol, something that's not expected to be there right now. And maybe, yeah, separate the put new state and split it into something like put a new state machine and put an update state machine or something. Or when you create state machine, you don't always have the thread ID yet, technically. You kind of assume it, but usually you create a message. This thread ID thing is also kind of bothering me because, I mean, it's probably the best way to go about identifying things like states and protocols and state machines. But for instance, it's also a matter of how the rest of these things would look like, because right now the thread ID is stored in the state machines themselves, which is not really the way to go because these threads are technically meant to be somewhat controlled from the outside in some manner. And the reason this has been flying in RSVCX up until now is because we really just use the thread ID and sometimes the parent thread ID. But there are also these other fields, which you cannot keep track of, like the sender order and the received orders, you cannot keep track from a single instance of a protocol, especially considering that these are technically meant, like the threading are also meant to, and the threads are also meant to kind of keep track of conversations between more than two parties. So it's also a matter of that. That's why I'm kind of trying to generalize over this from that regard as well, not just getting this done and, okay, take the state machine, put it in there. But I was also kind of just trying to take it once the bit of time. Because when you factor in the idea of some external component handling the threading, we're just dealing with that. And the inner workings of that, then it gets way hairier. And yeah, I don't know. That's why I was saying that the, honestly, I'm still, I still stand by that. The best thing to do is would be to kind of devote a good amount, a good chunk of time to develop or design some architecture, lay things out and then start finding patterns between these things because it is just messy. And the POC is just that. It's a POC. And I'm not sure if we might be able to fix the problems that are currently here, and maybe the things that you don't like and that I don't like and that George doesn't like maybe, I don't know. But I'm still somewhat certain that stuff will be left out in the bigger scheme of things. Yeah, I see what you're saying. So what's your action step suggestion? Do you suggest to further just kind of proceed with this POC and kind of work things out, find out what we are missing and keep on iterating it as we've been or what approach would you take here? I don't know. I think we could probably get something working out of this, but it would by no means be final. But I think just serving as some sort of example, it might be nice. And it's also a matter of, for instance, in message processing. I think I just pushed some commit. I've been working on this where the another interface is kind of introduced something called a message handler, and that basically just incorporates all the handling operations that were there previously. And the thing is that this is a trait you can actually look through code if you want it might make more sense. And the thing is that this is a trait where there are some methods that have to be set, but the handling operations are actually default and have default limitations in the trait. So I was thinking kind of exploring the idea that if we make these, if we make small methods, reusable pieces that consumers could even overwrite on demand. Because when you implement a trait, you can overwrite the default methods or the methods that have the default implementation. So then you could actually end up with kind of disability of letting them construct things or maybe customize things, but also have the operations done in an organized manner. But yeah, as I was saying, I was kind of getting stuck on this whole thing with the ID and especially like inserting a new state machine and the resolution of an ID in that case. Maybe just since we talked a lot, George, do you have any inputs on the discussion so far on thoughts or minds or now and if you guys have something to stress? I've mostly just been listening to be honest. That's a very detailed conversation. Yeah, I need to have another look at this PR, I think. Sure, sure. All right. Yeah, it's all good. It's all good, of course. Yeah, so where do we stop? Yeah, you actually wanted to show me some sort of trait or something in the code and we have six more minutes. So yeah, I think it's in the new protocols mod RS file lower, the last mod file there. Yeah, and if you scroll down, I think it should be there somewhere. Yeah, so there you go, the message handler, it's at the bottom. Oh, okay. Yeah, so I mean, don't be too harsh on it, it's just an idea. The whole thing was with the whole concept was to have smaller pieces, smaller, rewritable pieces. I kind of think that this would end up being too big of a trait maybe. I mean, users wouldn't have to override or implement all these things, but yeah, maybe splitting them on a protocol basis might not be a bad idea either. Nevertheless, it's basically the exact same thing as the handlers, just that it makes, like when you incorporate the ledger and the wallet and all the other stuff there, it makes things a bit more streamlined and also in terms of like function signatures because you would be passing this in anyway. So this way you can actually use the self fields. Yeah, and it's basically just using default implementations for the handling operations and technically users could override that. That's pretty much the idea. All right, let's leave this out for now. We are running out of time a little bit. So I think we can continue discussion on GitHub and other channels. Let's just get back to the agenda and wrap it up a little by little. Now I don't know how to go back. I don't think we had anything else actually much. Yeah, so yeah, that's actually it. I don't think there's anything new here. Maybe just one question. Bogdan, you mentioned before that you started kind of looking into the NONCRETS-RS in parallel with some improvements. Sorry. That you started like looking into the improvements which could be or start working on some NONCRETS. Yeah, maybe just high level stuff for now. I'm just kind of fixing some function signatures and maybe removing dummy arguments like we're too big of arguments to the functions but like actually making some drastic change would involve a lot of work. I don't know if this is necessarily the place to discuss that so and we're kind of out of time. Okay, well, I guess that being said we can just wrap it up unless any of you folks have anything else to add in the last minute? Not for me. I have something about tomorrow. Yeah, it's possible to maybe have an earlier time for the Friday meeting. Maybe we can discuss this one slack. Yeah, we can set up one time as you would like. We can definitely make it a bit earlier if you prefer that. Yeah, let's take this slack but it should be fine. Yeah, thanks. All right, thank you everyone for joining in. Have a great rest of the week. Cheers. Thank you, have a good one. Thank you, you too. See you guys.