 Hi, George. Hey, how's it going? It's all good. Today, we won't have work done on the call. So let's give it a few minutes. Let's see if anybody else is going to connect. Cool, no worries. All right, let's get started. Share my screen, starting with our hyperledger disclaimer, and maybe also removing this bot off the call. There we go. All right. All right, so welcome to 13 April, 2003, RSVCX Community Call. This is our anti-trust policy notice by Hyperledger Foundation. I mean, to do that. Yeah. So for anyone tuning in, we have these calls every Thursday, Thursdays, 9 AM UTC. If you would like to come and discuss something, too, you can also just connect and talk with us. So to kick off the meeting, just to check, George, am I coming clearly? Is my internet fine? You cut out for about five or so seconds just then. I see. Let me try to fix that. Hopefully the radio waves will feel more welcome when the door is open. So let's see if that helps. All right, so good first issues. So just kind of like quick recap there, just to also periodically keep this as a theme to keep good first issues in mind. So there was one I've created recently about updating time, create dependency, as there was automatic update which failed because there is actually breaking changes. And I saw just 15 hours ago, we had a new purist contributor, SWAPTR, SWAPTR, with a contribution here to basically update this dependency. Seems like there's still something failing, some clippy, some unit tests. So I think we'll still have to take a look at that. Nevertheless, thank you, SWAPTR, for these contributions. Always exciting to have new people on board and having contributions. We also have other two good first issues in progress right now. One is from Andy Wayne, who updated once again his branch, tried to address some of our previous comments. But nevertheless, there's also something to be addressed here. So looking forward to getting this merge in. And then next, yeah, there was a short discussion here on the attribute encoding from Stevane. So this was going on for a while. And Stevane was very persistent, still always addressing our reviews and comments. So Stevane will be busy for a bit, but he still plans to work on this in the first week of May. So that's all good. And yeah, that's, I guess, all of our open good first issues right now. It's a good to, if anyone has idea, even outside of this call, or to create, to come up with some good first issues, that would be awesome. Next up, a small update on our high-pledge mentorship program. I'm sure that there are some people tuning in, curious, particular about this part. So just to kind of remind the mentees, the applicants, how the program goes. So right now we are in the period of time where people can, the mentee, people who are interested in the mentee can send application. And there's instructions here how to do that. So that's all the way on to 10th of May. Then from 10th of May all the way to the end of May is basically for us to select the mentees and notify them about the acceptance. And starting June 1st, 23, there'll be the working period until mid-November. Yeah, and in the meantime, there's some evaluation kind of dates as well. And yeah, I also wanted to talk a bit about the projects a little bit more because there was people asking me to tell them more about these, both of the projects we have. People who are interested. So let me put a picture here. I'll stop sharing for a second. OK, I'm sharing back again. So picture I had here. It's not a previous picture. I kind of get the work done. It's a picture I drew while on call with one of our applicants. So basically, we have two projects. We have the next gen mobile wrapper and we have message mediator. So the mobile wrapper, that's on this picture marked with a blue color down here at the bottom left. So that's kind of the scope this represents. It's a next generation mobile wrapper on top of Aries VCX enabling use cases where people want to build presumably mobile wallets supporting Aries protocols and anum creds and so on. So this will be the meat of this job would be to write this layer and finish. There is a POC right now available, but there is a lot more work to be done there. And the scope would be mainly to finish this part. And in addition to that, create Aries mediator client. That's essentially very specialized, Ditcom API client to communicate with the mediator server. And basically from this UniF5 wrapper then there will be auto generated Swift and Kotlin bindings. And part of the scope of the project is also build a small, it could be very simple Android application as a demo. It doesn't have to do all of the protocols, but it'll be nice if you can at least accept an invitation. That's kind of the baseline for a good starting point for anyone else to start adding other protocols and other features and so on and so forth. And here on the top left, I mean, this could just kind of denote kind of explaining, maybe a textbook example of how things work in the Aries ecosystem, in Aries deployments. Usually you have some consumer, I'll call her Alice here with a mobile device, she'll be holder of a mobile wallet capable of Aries protocols. And she'll at least want to communicate with institutions, for example, bank or any other institution. But the thing is, as you can see here, there's also one box between them. So usually Alice can easily communicate with the bank because bank has some sort of public endpoint exposed and there's kind of an example here that the two pieces of information which Alice needs to have in order to communicate with other party through Ditcom is service endpoint, which will be just URL, where Alice can send messages. Other will be a public key, which she uses to encrypt the messages. That's kind of in that show what you need for Ditcom. And then from the other side, obviously if bank wants to initiate or the institution wants to initiate the conversation, communication, it would need also the same set of information. However, there is no public endpoint, there's no direct way to directly send message to Alice's device. If we forget about maybe like some IPv6 stuff and things like that. But we assume the device doesn't have any public endpoint. And so the architecture is similar like with mail servers where we have a server where you have an account as a consumer, as Alice and this service can receive messages on your behalf. So there will be a mediator box here. And that's also where every mediator client kind of plugs in here. So for Alice to communicate with the mediator and pick up the messages, which she might have received while during the night, you need some sort of client to talk to this box. And that's what this blue box down here from the previous, from the first project is doing. And now moving on to the second project, that's the mediator itself. And that's here with a purple color. So here is a mediator a bit zoomed in. So just get any idea what might be in there. I will kind of look. Generally you will have some wire communication layer, you know, receiving message HTTP or WebSocket messages. After you receive messages, they're typically encrypted. So in the decrypted, then once some sort of decrypted message pops out, you need to take a look what kind of message it is. And for that, you can use Aries VCX to support, you know, processing some of these messages for some of the Aries protocols. So the green ones are the ones we already have implemented in Aries VCX and you will just kind of build on top of them. The red one pickup protocol is currently not present in Aries VCX and therefore the scope of this purple project would also be addition of pickup protocol to Aries VCX. Although I don't expect that to be a huge, huge effort. Well, and then essentially, as you can see, you have three families of messages you might be receiving. Based on what kind of message it is, you do something else with it. If you receive an external message addressed to someone, you would, which is common use case, you'd simply pretty much just stored a message on under the, you know, linked up with the recipient. And then second use case is picking up those messages. So once the recipient here, it will be Aries in this example. Once Aries come online, she would try to contact mediator using the Aries mediator client to pick up the messages. And that's essentially this pickup protocol. Well, this pickup protocol is specifying. There are Aries RFCs on GitHub, which I'll be adding here just after our meeting, just after this meeting with further information about these RFCs, but that's pretty much it. Obviously you need to have some sort of persistence layer to store these received messages so they can be picked up later by the proper and authorized recipient. It's also important to keep in mind scalability. So this service should be horizontally scalable. So you should try to avoid using some sort of in-memory storages, making sure that the storage is, the state is distributed and that there won't be any complications scaling this out into entire cluster of mediator containers or something like that. Yeah, George, have I missed anything? I don't think so, that's really great. Yeah, is this image available anywhere or will it be? Yeah, it's not. My original plan was to make it be prettier for the meeting, I completely missed it. So I just had to pull it out in this uglier form, but I'll be putting into the meeting notes so people can find it there. Yeah, looks great to me. Awesome. So let's move forward to the usual stuff. So let's start with the overview of the work done. So we had this extraction of Aries VCX core and by Mira. And it's all approved, but you had a great, great catch there that this was originally ran with the SKI, which is something we discussed last time. Yeah, I totally missed it. So I put a rerun and why it's not running? That's weird. It's still skipped, although I did remove it. Wait, that's strange. Let me try to rerun it again. Okay, we'll see how it goes and hopefully we can rerun all jobs. Yes, sir, rerun all, okay. Okay, we'll see. I guess we'll see in a couple of minutes if this goes as expected. So yeah, but maybe to talk a little bit about this PR. So, and actually I have one more picture and I just need to pull it out and find it somewhere. So I'll stop sharing for a second just to give this PR additional context. That was basically how we iterated to this idea that we should even do this piece of work. We were discussing with Mira how should we go about this resolver implementation? And yeah, this PR ended up with as a sort of pre-preparation work. Let me find, it's a pretty picture we had. I think I got that image now. Sharing again, sorry for a little technical hiccups here. Okay, and there we go. So what this PR is doing is extracting a portion of a portion, a big portion of code which is previously part of Aries VCX. In particular, the profiles and the trade which are shielding off particular implementation details about storage, a ledger client and credential implementation. So this is all extracted out. And the reason why we even did that was that we wanted to basically started thinking how to build the idea resolver. So we thought about some like trades here which is not really important here. We can leave that for a separate discussion. But basically we came to obvious realization that when we build did resolver, we'll need access, for example, when we build a resolver for did solve method, obviously we'll need access to server and ledger. And we already have these profiles which contains this API and functionality in Aries VCX. But behind those profiles, but in order to access them, obviously we would either have to do like make a did resolver dependent on Aries VCX which doesn't make sense because then we would have like cyclical dependency Aries VCX and did resolver, did resolver needs Aries VCX which would lead us to basically placing did resolver into Aries VCX. However, we wanted to have it as a separate create so people could use the idea resolver. We're gonna implement in projects perhaps without necessarily using Aries protocols. So that obvious conclusion was that if we extract out all these profiles including the specially the ledger profile then we can just have it as a shared dependency. Aries VCX can depend on these profiles as it's using them today. Aries VCX can use the idea resolver and the idea resolver on its own could also rely on these profiles. So people who want to use only the idea resolver can use, can do so without having to bother being concerned with the Aries stuff at all. And so yeah, so then we extracted this as a separate component right now as like one huge create. I don't know, maybe I'm not sure if it would make sense to split it out further. I don't think there's a need for that at this moment. But I don't know, perhaps if somebody, I think it's possible to go in in the future where somebody might be interested in, I would say only using ledger and doesn't care about wallet and critics at all. So then would maybe actually make sense to take out and the ledger component as a, the ledger profile as a create on its own which would kind of basically be a facade behind the BDR tools and the modular libraries. So yeah, that's pretty much it. Let's just wait for the CI. Although I have the bad feeling it's keep skipping these jobs. Yes, and I don't know why. Maybe we need to like push a new commit or something like that or sort it out after the call. Other than that, there was some small cleanups of dependencies. This one is still pending review and the other one was merged. There was dependencies which were not used and also a bunch of that code which was deleted. Next up there was dropped support for the legacy format of serialized through Verifier, state machines which have been created by a version before 0.53 release. So there's a upcoming PR for the 0.54 release. And so therefore, since we dropped the support now in 0.54 we will no longer support those old serialization formats. You'll have to follow the migration strategy provided in 0.53 release to essentially re-serialize the state machines. That's it for what we've done since the last call and then we have some work in progress. We have a messages integration. This has been open for a while. The recent refactoring of the extraction of Aries VCA score kind of shuffle the cards as this has to be rebased. This has to be rebased and also Bogdan is not here but I know the challenge right now is just to get the tests integration tests up and running. We were doing a whole bunch of internal testing with these changes in Apsa and it looks good. Seems like it's working but obviously we want to maintain the CI as is. So there's still some work pending to sync up the tests with the changes. And lastly, I suppose, apart from the smaller things there's the type state pattern holder and I saw there was a bit of a discussion here between Bogdan and you George but fortunately I didn't have yet chance to take a look here. So I guess I'll take a look. Perhaps you have any comments on this one? Although you already wrote a whole bunch of stuff so I should probably read it first but still it's a space for talking. So if you want to somewhat comment it or if you have any new thoughts. Yeah, do you want me to show you sort of what I have so far and maybe? Yeah, for sure. We have time so why not? I'll stop sharing. You can see that okay? Yeah, it's all good. So like I originally started that PR before we had the revised sort of guidelines how to make types of patterns. So it had a lot of sending messages and things on that line which we don't want anymore. And also that PR started before messages too existed. So it was getting pretty outdated. So recently I've just been working on a new branch trying to follow the new guidelines. And yeah, so basically I'll go over some of the things some of what I have so far. So it's mostly based off the original holder handler but following the new guidelines. So for instance, none of these are filled out yet. I've just been drafting the states and transitions and want to get them approved before I go any further. But yeah, so firstly the first state is proposal prepared. So you can reach this state by initializing a new holder with your proposal data. So this is basically the holder beginning the protocol saying that I want a credential with this data and then after they create the holder and enter into this state they have the ability to get the proposal message which then they can send on their own account. So this part's good because it means that no errors can happen. There's no chance of any errors. And then so after they've assumedly got that proposal message and sent it out and then received an offer back and offer credential message then they have the opportunity to transition into the next offer received phase. So this is what this API does. And originally I had this as returning like an areas VCX error. But Bogdan mentioned that you may as well do it like this where the error type is the holder in the failed state. And yeah, in the PR I'd written it like that. And the reason I didn't go straight for the holder failed state is because it seemed a little scary to implement but I don't actually think it'll be so bad. And yeah, so the reason that this can fail is because there's ledger interactions and also a non-creds interactions that need to happen as part of this step. So there is sort of a chance of failure. And yeah, this is sort of the first maybe controversial thing. I was hoping to get yours and Bogdan's opinion on which is this API right here. Even though it's a transition API I have it as taking a reference to self, borrowing self rather than consuming it. And the reason for that is if this was consuming it and it ended up in the failed state now the consumer has no reference back to the original. But if this is borrowing then if this ends up here then they determined that it was only a soft failure maybe it was the ledger timed out a retribal error. Yeah, I mean like what I noticed here or what was like what is on this line I pulled this off with my like conception understanding of the guidelines of the stuff we discussed is basically here like you are returning and like there's two possibilities of what kind of holder might be returned whereas and I mean we might have to just update the guidelines maybe just something we didn't like discuss enough and so maybe we have some different understanding but my understanding would be that we always kind of only either return like the new state successfully or we return error but not actually the holder in like a failed state. And so I would assume what I would originally expect would returning result where the error portion of the result would be yeah just some sort of every VCX error or something like that and then it would consume itself and then it will be up to the caller to either retry it again if it makes sense or just enter the failed state manually because they see they have got an error from receive offer so there's no way to go about it just entering the failed state. Yeah, so that's sort of how I wrote it out here where this should take in an error as well but they have to opt into transitioning into the failed state. Is that sort of what you were expecting? Yeah, yeah, yeah, basically I think what you have drafted there is more closer to my expectations. Yeah, see this was Bogdan's response to that. Yeah. Right, so I think we will have to go through this make sure that we are aligned on this. I think I mean I like the original approach I think with the error and then going to the failed state on your own sort of that way you don't have to take the reference and it's kind of nice and symmetrical like. Well, I think you still would have to take a reference because if this results in error then you've still lost self, still that problem, right? Oh yeah, right, right, right. Yeah, I see, I see. So yeah, what do you think that does this seem okay? Like it's not perfect type state transitions because you're keeping the original. I mean, I know Bogdan was like had lots of concerns about this and it was trying to find good like typing solution to kind of figure out is like how to prevent using the state machine after maybe you was already modified. Like if you take a reference here and you return new state machine, how can you kind of prevent the developer making mistake by using the old one? But I don't know, I mean it'll be definitely like nice to have something like that. At the same time I feel like this kind of like guard controls can be added later somehow. I don't know exactly what would be the solution, but yeah, I mean, I think it makes sense that like you might want to, for some reason want to still access the original data, like you don't want to just lose it and we also like this, I mean, otherwise, if you consume self, the developer wants to maintain the original data, they will have to make a clone ahead of time and juggling two state machines kind of at once. Yeah, yeah, exactly. Yeah, I think if the developer really wants to keep the original state, they can do that no matter what we can't really prevent them from doing that because they can always clone or serialize and deserialize before calling some consuming API. I think this was another option Bogdan sort of alluded to where it consumes self, but the result is either the new state or it's an error, where it contains the original state plus, you know, the error. And that way, yeah, it's pretty maybe kind of complicated, but yeah, it ensures that if they do get to the successful state, then the original is consumed. Or maybe it's inefficient, but perhaps even like always returning the previous state and the new state and that way you could just like, I guess the signature would be simpler because you could just return some sort of tuple of holder, you know, previous state and the new state, previous state would be whatever the previous state would be and the new state would be either the successful state or the failed state. And we wouldn't have to have the manual failure transition method. So basically result and then result and in the result. Are you talking about something like that or? Yeah, but basically it would be a tuple. Maybe the successful case, right? Like a holder, like it would return a result and then in the result, it would be successful, you know, successful result would be tuple of previous state. Oh. Well, I think if it's successful, yeah, we don't want to give them, if they succeed, we don't want to give them back the original state because it was successful. So there's no point in them keeping the original state. But if it fails, then we want to give them back the original state in case they decide that it's not a hard failure. No, yeah, I was off. I thought that we could return tuple of like previous case, previous state, new state, just every time, but then you wouldn't, you can't really express it in RAS because like the new state can be one of maybe multiple states, it can be the successful one or the failed one or maybe even something else. So that's no go. So yeah, it looks quite complicated in the way. This way the signature might be more matching, but at the same time, there is some beauty in it too, I think. And especially if you can have like the methods, the transition methods like symmetrical in terms of always just consuming self and then it's not like sometimes itself and sometimes it's reference. Yeah, I'll be definitely nice property. So you're saying you prefer this sort of signature to this one where it's taking a reference, but no two. Come on offence, I'll have to think about it a bit more. Okay, yep, cool. I'll think about it and join the discussion on the issue. Cool, okay. I'll post this update on the thread, but yeah, I guess the rest of the state transitions are fairly straightforward. Yeah, this is another constructor as well because you can technically start the protocol in from the offer state. So you send off an initial offer rather than you sending off an initial proposal. So yeah, similar transitions, you can go back and forth between proposal and offer if you're negotiating the credential details that's part of the protocol. And then once you're happy, you progress forward by preparing your request and that puts you into the request prepared state. And when you're in there, you can fetch the message and then send it off on your own terms. And then when you're in this state, it's assumed that you've sent off your credential request message. And then once you receive the final issue credential message from the issuer, you receive it and enter into a credential received state. And then once you're in there, you can store it and storing it results in you transitioning to finished. Right, but the question, where you receive issue credential and store credential received. Yeah, so this is something different to this is another controversial thing that is different to the original holder API. I guess you receive it and then maybe once you're happy with it, then you store it. What do you think? Just be receive it and store it and then transition. I'm not sure at the moment what will be the implementation. Maybe what would receive issue credential? What would it actually do? What kind of stuff? Pretty much nothing, but stuff away the message into the state. Maybe it's not worth it for it to be a. Yeah, maybe you receive. And there could be some like still maybe validation. Like what if the credential you received is actually what you expected, right? So you wouldn't just store store some something you don't want in your wallet. Yeah. Yeah, I guess I guess it could be also think about it. But one more question, which is popping, popping in my mind is remember that the holder is also sending back like acknowledgement message at the end, isn't it? So, yes, so this is maybe another controversial thing, but you transition into finished and, you know, maybe we have it like this and get rid of this one and this transition straight into finished. But once you're in finished, then you can get the act message because I wasn't really sure how to represent. The intermediate step. Or whether sending the act is a part of the finished state or presented as like the step before you're finished. Yeah, seemed a bit awkward to represent that. But this isn't the best either because I don't know, someone might see finished and assuring that they're done and not bother sending the act message, even though they should. Yeah, right, right, right. Yeah, but I think it's I mean, it's it's aligned with the fact that we don't do IO anymore. So you just get the message you need to send as you. I mean, usually with all the other steps within the protocol, it's the same way, right? You like get the request message or get proposal messaging. So the same way you get the get the ag message and you send it with some like it's up to the consumer to send it somehow, right? And maybe just a question. If the if the if the act of sending the message or allegedly sending the message, it should if it should leave to some sort of like next next state. Yeah, I'm not even sure if Holder is obliged to send the ag message or if it's only if the issuer asks for the acknowledgement. Yeah, yeah, in the original implementation, it only sends the act if there is the please act flag. But I'm not totally sure if that's 100 percent accurate to the RFC needed, but that was the original implementation. Right, yeah, I assume it's probably that way. Maybe question is how it works with the two point of protocol of the issuance. Yeah, yeah. So yeah, if if the act messages in the finished state, this was another idea I had where it returns as an option and it it only returns some if the please act flag was true one way to represent whether you should be sending the act message or not. Yeah, right. These are like great findings. I mean, you're doing pioneering work here. As we wrote out those guidelines and now you're now you are kind of doing the first rewrite trying to follow them and trying to tweak it to change the approach we've been doing following before. So yeah, it's definitely valuable just to have this. I mean, I assume that implementation of the other protocols will be much easier as we kind of dig through these like big question marks of like how to do this, how to do that. Then we have it answered. We can just read up the same approach everywhere else. Yeah, yeah, exactly. I think so. I mean, like, I guess these questions about some things are result types and whatnot, consuming or not to consume. I'll post them in the thread, but I think they won't block me too much just proceeding with the implementation now. They're just sort of minor details. So I'll go ahead and just start implementing if we're somewhat happy with the shape of these, apart from the questions. Yeah, I think I mean, I think it looks looks good. In general, I'll just have to take a closer look at the discussion. Cool. OK, yeah, that's all from me. So for taking up a bit of time. No, it's all good. It was it was a good, good talk. All right, then let's let's. Let me show my screen again and I'll just add notes here. I had like a high level we just covered. So there was a question kind of open question about the return types in case of error. And then we also kind of touch on the. Self was self and then we had. I had. So separate states. Received credential. And stored credential. And then one more point was the acknowledgement message at the end. OK, so we have these of the table. This was really nice discussion and moving on to the next one about the upcoming work. So we have Mira current and work on the deep parser, the resolver. We have yourself working on the credential holder and basically all of us kind of going through these questions which arise. So I'll put it. You know, that that's that's. Well, I'm talking about upcoming work, but. I got a little bit tangled up here, upcoming work. Well, Mira will start to work on these in like in a close future, I suppose. So that's why it's so an upcoming work. And then we have the type state pattern, I assume, once maybe this is in a little bit matured PR, we might pick somebody might pick up the other type state pattern implementation here. And I guess that's like the close future ahead of us. Still as for the. It's for the getting rid of VDR tools. I think the like the main next point is to get rid of the like it is a rewrite issuer with the credits. And once that is done. We might be able to start trimming down a VDR tools such that it would only essentially contain the wallet, the original wallet. And we could consume, consume in the client and credits implementation from the modular, modular, modular libraries. Yeah, and we have four minutes left. There is a bit of a tiny discussion point here about the trade naming. So just notice that we have a bit of an inconsistency here I think, or do we? And maybe I was wrong. It seems like all of the crates are with underscore just that the repository name is with a dash. And then also the name of the credit itself is the dash. Maybe this is what this will trigger me to to add this point there. I just if we name the credit this way, maybe we could just name the directories, use the dash for directories as well. And then I guess the second inconsistency is that for the other projects, for example, agency client, we also use underscore for the directory name. But here we also use underscore for the trade name of the package name. So I guess we should kind of find, unify this approach, although it's just like a minor thing. I guess my personal suggestion would be since we named the repository aries-vcx. Then we could just and also we call the package the same way. We could just use dashes everywhere. And also I guess when I'm looking at the other dependencies we depend on, looking at how this is being done in an ecosystem, is that in the credits is also with the dash. And but I know, I mean, this is kind of, there is no single, I think, recommendation in the RAS ecosystem. I saw lots of crates with underscore, but also lots of crates with dash. So I guess it's kind of up to the individual projects and crates, what kind of approach they adopt. What do you think, George? I'm like, I'm browsing the internet at the moment trying to find what the idiomatic way is, and I can't find an answer. Yeah, because for example, Serdi, I think he's using underscore. Yeah, Serdi underscore, Jason. Yeah, that's what I thought of, but then others have dashes, so I'm confused. Yeah, yeah, it's 50-50, I feel like. But yeah, we should definitely stick to one. I have no preference, personally. Let's take a look at the LVDR tools here, what kind of dependencies is here. A lazy static is underscore, Serdi is underscore, but log derived. Oh, that's a small credit, though. All of the indie stuff is with dash. So they're consistently using dashes, is that right? Yeah, it would appear also in the credits. Well, let's take a look at in the, maybe there is no dash in the name. Anon creates RS, right? Ah, yeah, good. RS, I think they also have, they also have dash. Yeah, repose the dash. And then the name of the package is actually different than the repository name. Yeah, I think I would go with the dashes, since it looks like it's popular in the hyperledger slash indy slash ery's. Yeah, ery's asca is a dash, that's great. And our repository name has a dash in it as well, right? All right, so there will be some big rename, I mean directory renaming, but I guess let's leave that after some of these big PRs are merged here. Yeah, making things harder than they have to be. All right, oh, and then one more point, although we are just on time, this one is short. I was just thinking, what kind of, I was thinking it would be nice if we use maybe some shared prefix for all the projects which are incepted under the ery's dcx repository. So for example, messages or like, pretty much everything. So I was thinking like if that we could prefix, I'm not sure about the directory names, but at least like the crates themselves perhaps. I mean, once we start publishing this, I'm 90% sure it probably messes me. Already exists on crates. So we will need some how to distinguish ourselves. All right, so I was thinking ery's vcx, ery's dash vcx dash whatever, or maybe I don't know, experimental brainstorming idea, like some abbreviation like abcx or maybe just ery's dash something, ery's dash messages, you know, I guess there's multiple things one could come up with. Yeah, is there a reason we couldn't go with just ery's, you know? No, there's not a reason. I'm just wondering if then ery's is not bit too specific though, because for example, let's say we create like, we create now this resolver and it's going to be like ery's did the resolver, but people who might want to use it, you know, they want to use the like rust implementation of some of the other resolver. It's going to be like ery's did the resolver as that's not volume. I don't care about ery's, this seems to be something else, right? So I was thinking maybe something less like specific or at least at the face value, like avcx, it's like some string, you know, whatever it means, like it could mean ery's vcx, but avcx messages, like nobody would, if somebody consumes it, maybe they wouldn't be concerned about this avcx. Right, yep. I don't know, I just, I'll just leave it like an open question and maybe send a poll on this quarter or something, because with the others, I just wanted to like put this, put this topic on a plate to start thinking about it as the new crates are being born now. All right, anything else from your side? No, not for me. Okay, awesome. So we got it all done and it was a pretty long agenda today. Yeah, so thank you, thank you for taking time to join. I know it's late now, so I should get some dinner. And now we'll see every other, everyone else again next week, 9MUTC, go for it to join. Thank you, George. Cool, thank you. Cheers. Cheers.