 Hey George. Hey, how's it going? Not too bad. Not too bad. And you? Yeah, yeah, pretty good. I am I go rid of that bot. I hope that's okay. Yeah, that's that's cool. So Patrick won't be able to join today and he asked me to kind of take What's the ownership of the meeting of the call today? So let me go ahead and share my screen and we can quickly go through some updates here. Is it visible? Yeah. Okay, cool. All right. So for everybody that's going to tune in later into the recording, this is the RSVCX Community Call of 9th of March, 2023. We have our antitrust policy here. Feel free to review it and let's take a moment. So it's displayed here and Okay, so let's get on. Let's get down to some updates and the agenda. Now, in advance, I will say that I'm not necessarily familiar with everything that has been done here. So we're probably going to explore them together. I know that there have been some renaming of some verifier methods. I believe Patrick took care of this. As far as I know, there are mostly some renames. Apparently, there were some updates, some methods added. To the VCX core. Yeah, this has also been merged. I believe it was merged just yesterday. So that's some good stuff from Patrick. Apart from that, not familiar with the attributes getting cleared. Let's see. Okay, so apparently there were some utility methods added to interacting with the ledger. I believe this is sort of related to to an issue regarding the service endpoints, where in some old notation, they were not prefixed and we kind of need them to be prefixed now. So it's pretty much what the, I could be wrong, but my assumption is that this is what this is about. And now I know about this. This is some work from from you, George, about the type state pattern for holder. Maybe you could actually take the lead here a bit and I don't explain I don't know what your, how's your experience with type state pattern, I guess, first of all, if you're encountering any sort of difficulties or if you feel everything is flowing naturally or organically in a way. Yeah. So yeah, I guess I was a big fan of the connection type state pattern. It's very nice to use compared to the old API. So yeah, as we talked about in the discord, one of the next logical, I guess, patterns or protocols to target with this type state pattern is the holder handler. So yeah, I've just been working on applying the same sort of pattern from connection to holder, where I guess one of the main differences between holder and connection is that the connection type state pattern represents both roles in the protocol inviting an inviter. Whereas this is just the holder as a part of the issuance v1 protocol. And yeah, as we talked about in the discord, the reasoning for that is because there isn't really a lot of commonality between holder and issuer in this protocol. So I believe it makes sense to have them separated. So this PR is just targeting the holder type state and then the issuer could be done next. So it's pretty straightforward thus far, sort of just following the pattern from connection. And yeah, there were sort of a few questions that I ran into as I was going along with it. Okay. Is there anything worth discussing now? Yeah, yeah, if you don't mind, I just had a couple questions on the comment that I left the description at the top. I'm not sure you've seen these but yeah, I was wondering with the connection type state it sort of made sense just to replace the connection handler completely because it was such a new API. But I don't believe that would be the case with the holder handler. So I'm not really sure what the best approach would be in terms of, yeah, having both supporting both or replacing it. Yeah. Okay. Well, essentially, I guess the goal is to basically replace the old one. So I think that's what we should be striving for. It would require some work across the, like the entire workspace, I guess. But the idea would be to sort of deprecate the older pattern in favor of this type state pattern. Now, regarding the second point here, this is a very, very good question and this is where rather the idea I'm going to mention now is not even implemented in the connection protocol itself. But the, so to be able to change the state from one would be able to modify the type from one connection or one state to another in the state machine. We basically take the entire structure we like with full ownership. Now, in cases when it can diverge to multiple states, then, like in this particular case where you have this failed state and some just progression of the state machine, the failed state basically act as an error. So what I would do and what I plan to do in the connection protocol as well as I get to revisit it is to basically like let's take this method, the send request method as an example. So this can fail so it can return an error and we generally return a result here. So my goal would be to make the fallible state or the error representing state an error itself because you can do that. You can implement error for this and basically treat it appropriately. So you could as a result type from the send request method, you would get the result holder request sent. So that would be the okay variant and the error variant would be holder fail. And that would be my idea. Now, apart from that, to kind of take advantage of, so because we take the value, yeah, we basically pass that the state machine by value and not by a reference or anything like that. In the connection protocol like the current implementation, especially like where it's exposed in places like libvcx, when the state machine is stored in some sort of structure, we clone it out of there. We do something with it and if it progresses we store back the new value. Now it would be even better if instead of like sort of dissecting the operations in a way where if something fails, so apart from this like failure state that a state machine can get into, but I don't know just any sort of error like unpacking the message fails or packing the message fails. So anything like that, if we could design the method so that if we get an error from something like this, and it's not just a state, we get any error, then maybe we could design it in a way where the result type, like the result would be the new, the advanced state machine, but the error type would be like a two part containing the old state machine. And the resulting error from the operation, meaning that the old state, if it was passed by value, we can like see if something fails, we can just bring it back so we don't have to clone stuff all over the place. And this would make it a bit more performant in terms of how we handle it, because we no longer lose, like if something fails in the state machine at any point, and we take it by value, then that means that particular instance is lost, and it would be great to avoid that. But in terms of this failure state that some state machines have, this is what I'd like to do to basically transform this into an error. And because that's sort of like a finite state so it's just for representation motives that you would want to have it like that just be a state of the holder so you'd have holder failed, but that would in fact be some sort of an error. It's probably going to make more sense when implementation is done. I don't know if you're going to be ahead of me with the holder implementation and how advanced you are with it. I didn't get the chance to review it. I generally, I know it might be my personal preference, but I don't really like reviewing stuff, you know, 20 times as they get developed. I feel like it would be more comfortable for both the developer and the reviewer if the developer could say just adding comment somewhere, hey, this is ready for review or something like that. So that because you can change your mind, like even if you have some implementation, you might realize, you know, the next day that I can do this better, and you go ahead and do it. So I didn't really that much of a close look at it, but if you like it's in a reviewable states to say so, I can definitely, you know, do a more thorough review. Maybe one thing that I wanted to ask you was, how do you feel about just working with the holder and leaving the issuer aside in terms of the protocol? How do you think that that will play out? Like, do you think, do you see this as a problem or did you consider that? I'm strictly speaking because, like, as I said, I'm not familiar with the protocol implementation. So I don't necessarily know how they are stored, how the state machines are stored and like if they are the issuers and the holders are stored together. My assumption is that they're not because they were different types before as well. Did you face any sort of issues by just handling this one part of the, like one side, one actor of the protocol? Yeah, not really. The states that they both have in the original state machine is quite separate from each other. So there's not really much sharing going on. Okay, fair enough. Yes, it's not too bad really. All right, I was curious. As you know, probably the connection one is they're more intertwined. So it made sense even before and even now with the type state pattern to kind of consider them and treat them together. There's a lot of functionality there. So there's a lot of common stuff. And the states are not that different, I guess. But I assume that this makes more sense as a holder. You have your own set of operations and as an issuer, you have your own set of operations. Okay, I was just curious again. I'm basically doing my research right now. Yeah, on the failure states. I think something that Patrick was sort of proposing, at least my interpretation of it was that basically it should say the send request method, it should return a result. But I guess not this exact proposal, but the to be proposal. But yeah, it should return a result. And it shouldn't, you know, try to force itself into the failed state immediately in a way. And then it's up to the consumer for how they handle the error of that result, whether they want that error to, you know, send them into the error state where they, you know, send off the problem report of the problem report and then are into the whole failed state, which I think makes sense because some of the failures you could potentially get while sending a request, don't necessarily warrant that you send off a problem report and, you know, end the protocol. If you go and I mean, like a wallet access fail, say if you're in the wrong wallet. Fair enough. Or a slight error, yeah. Yeah, that's that's a very good point. And that's exactly why I was saying that right now the methods. Again, I'm speaking more related to the connection protocol, which I worked on, but the methods and the transitions seemed a bit beefy, like a lot of things were happening in there and especially a lot of different reasons that can lead to failure. Where some of them were not related to the protocol itself. So that's exactly what I was suggesting about having some sort of like sort of separating the operations in a way where Like failures can be failures not related to the protocol would get propagated without interfering with the state machine. And the only like the failed state would result from the, let's say I know last operation or stuff like that, maybe to give you an example of what I have in mind. I don't know, you can think about in the connection protocol, you get the connection request and you have to generate a response from it. So let's say that for whatever reason, you generate a response and you have to sign it and that signature process fails. And that means you essentially, you know, just the entire thing crumbles where that might actually be a retrieval operation, I believe. So in cases like that, what if instead of handling all of that into that transition code from one state to another, we could have methods that don't consume the state machine, they just take it by reference or stuff like that. And they provide you with a response like an actual response built ready to be used and then you pass that response into the transition. So this limits the, you know, the failure, the failures that can occur when transitioning the state and consuming the state more importantly. So that's pretty much what I have in mind. And I guess it kind of also falls into place with the messages refactor, which we're going to talk about shortly in the sense that the message is going to be composable and decomposable. So we have to handle parts of the message in different places and in different ways. So then when you only work like from a protocol perspective, you work with a subset of that response. Like if you have a timing decorator or some other stuff like that, that's not part of the actual state machine. It doesn't really interfere with its functionality. So a lot of these things will happen outside the state machine, but they can still hinder where even just sees the entire flow. I don't know if you get a thread message and you don't find a thread for it, where the thread is built incorrectly. Like a lot of things can happen that are not related to the actual protocol specific content and they would be handled outside. But yeah, I guess it's a bit of a, like it requires some thinking. I'm just throwing the idea out there that this is how I would see it. And it's not yet as clear for me either. It's going to make much more sense when I actually get to implement it and get another have another go at the connection protocol with the new messages. So that I can, I can actually see how it all plays out and falls into place. But that's a general idea. Yeah. If you can answer this, how far away do you think the messages work is from being complete? I was about to get that. I guess we're going to skip the SQL dependency and get right to the messages rework. We're going to talk about this after I guess is no big deal. This is Raphael also joined. So hello Raphael. I'm sorry we were caught up in the discussion here, but welcome. Hello, thank you. Okay, so about the messages rework it's actually not far off. Pretty much everything was implemented apart from the protocol registry, which I'm working on right now it's almost done. There are just a couple of things to figure out. It's a bit of like not really the optimal were best were ideal implementation. But it's also simply because this is this is starting to be quite a like it's, it's a huge PR and there's a lot of cognitive burden when it comes to thinking about it and I'm sure you, you're going to have a fun time reviewing it as well. But I am really counting on you I'm going to have multiple passes at it as well. But it would help at least in even from just the documentation perspective, you know, there's a fresh eyes will definitely see things differently than I do. So, especially if you feel like something is not. If you don't understand, like a particular piece of code and like less than 10 seconds from looking at it, let me know and I can comment it or feel free to add a comment as well. But yes, there's, there's a lot going on. So in terms of that protocol registry. I'm not sure if there's something added just yet. Yes, there is the overall idea that that this the rise from is on one hand we want to have a list of protocols that the agent basically supports. So we want to know exactly hey what capabilities do you have and we would have something like this and this would be a static thing. Just as a baseline, which you can alter, you know, whenever you create a disclose message through the discovery features discovery features protocol and stuff like that. So you can modify it but ultimately this is the baseline so this is the protocol these are the protocols that we support. The long term idea would be to control this by some feature flags so that you can choose what you want to have compiled into your agent when you build it. And I'm thinking about instead of having this as a lazy static like lazily initialized hash map because this is what it is. I'm thinking about having some sort of code generation play so that it would be even more programmatically determined. But that's, as I said, like in the in the longer run right now, I kind of want to see it functional. So this is one part of having the protocol registry for the discover features protocol and then the other part is this with a with semantic versioning in terms of minor versions, or protocol selection when you get a message because the summer rules declare that if you support, let's say you support the basic message version 1.0 1.1 and 1.2, and you get the 1.3. So that's a minor version three, and it shouldn't be too different from minor version two. The rules declare that you should basically fall back to version 1.2 or whatever is the highest version that you support, which is smaller than the protocol version you got. And this is another thing that this will help us with. There's still some some stuff to be implemented regarding that that's basically what's left. But essentially that's that's the other goal because having this list in the in the binary right now it's runtime generated but especially having it compile time generated would ensure that the correct protocol is always going to be picked and you're going to fall back, sort of, transparently, you're going to get a problem report. So the other part of this is that through this mechanism, if you fall back, or if you don't support the protocol or something like that, you would end up with a problem report that you can send to the other party and optionally a message like if if you fall back to a version you support you get the message and that protocol version and the problem report so you can let the other party know that hey I'm not supporting 1.3 I'm going to fall back to 1.2. But yeah that's that's pretty much the the overall idea. So not not as far off apart from this everything else is done. And I am actually looking forward to getting this merged. It will take it will still take some time. So once the protocol registry is implemented. There's basically a lot of tests and documentation that still need to be written. And I guess I'm also going to have to discuss this with Patrick but maybe you guys can also provide your two cents I'm thinking. And actually, I guess the plan was to retrofit the messages like the refactored messages into areas VCX and all the places that it's being used. But I realized that that would be a bit like quite a lot of work. And I'm thinking, I propose the idea of. retrofitting it or taking the type state machines one by one and sort of doing those together with the messages refactor but that will also be a lot of work. So what if instead we keep it as a separate crate for now so it co exists with the current messages create and we implemented gradually into every VCX and all the other crates, basically so that. You know, like you George you're working on the on that holder state machine so when the messages create when the messages to create will be merged, you could start using it. It would still imply some like using it and across multiple places but it would be a more iterative approach. Rather than retrofitting everything into the current code and then refactoring the state machines. I don't know what do you guys think. Yeah, I think that makes sense. Is that is that not similar to the approach of, you know, incrementally doing it with the type state patterns. Well, I guess I guess it is. But I mean, when it comes to the state machines. Like you're taking one protocol at a time or one component one state machine at a time like you you're handling the handler, the holder sorry you're doing the holder right now. And like it essentially makes sense to refactor the state machine and use the refactored one in place of the old one. But it's also a bit more contained, like it's only about one specific thing one state machine for one protocol, whereas this pretty much spawns spans across everything else. So, like taking, taking down the old messages create and putting this in place in one go it's still going to be a lot of work. And I'm just, that's basically what I'm what I'm proposing to maybe. Merge this in as an as an additional crate in the beginning and as we gradually replace the implementations from the the older crate with the new one. Then as we ultimately pretty much implemented everywhere and the the old crate is not being used anymore, then I guess we can deprecate it and remove it. Yep. Yeah, that sounds good. I mean, it's again, it's another idea we can we can discuss, maybe in the in the next week's calls well I don't know exactly if this would would even be in a merge. It probably will be in a mergeable state by then but we don't have to to make a decision right now. But yeah, so not it's not going to take long. Finally coming to an end and I at least I am glad to see the light at the end of the tunnel because it's been a lot of work. And small things like the protocol registry like a better implementation of it can be done again, iteratively. And it's also, there's a high chance that some stuff might need to be added maybe some helper methods or any kind of thing like that. Which are really hard to think about in such a big picture without actually implementing the messages in a specific protocol. So it's not it's not like this is this will be the finest state once we merge it, but it's going to be a pretty solid base ground where we can start to start adding stuff or even removing stuff if it's unnecessary. I don't think that will be the case but who knows. So yeah, that's that's pretty much it. We can talk about the sequel X version bump. Is this. Okay, this is apparently just a draft. I think I've read something about this. I don't remember exactly what it messes up but Oh, cool. I hadn't seen this work. Nice. Interesting. Yeah, there was there's a few sort of conflicting dependencies with, I guess, all of areas VCX and areas as car, and they're all coming from live video tools, pretty much. I guess this first sort of thing to tackle is this SQL X thing. Which has previously been using that get fork of it. Or maybe not for specific branch. And yeah, Patrick wasn't super clear on why why we're using that version of SQL X so I think this is the attempt to stop using it and replace it with the official version. And then yeah, the version that comes the issue that comes after SQL X with areas as car is within us. It's using an older version of zero wires and then that causes some conflicts with as car which is using a newer version. Hmm. Do you have any idea where SQL X is being used in every VCX. I'm not sure it's a dev dependency. Okay. Yeah, my bad. I didn't notice it. Yeah, it's probably just used for tests. Okay, that's that makes sense. Okay. Yeah, I've heard something about some some just version differences. I wasn't familiar with it, but I guess it makes sense. I know that, however, like there is a plan to kind of drop live vdr live vdr tools and start using the newer crates. The refactor ones. I believe like they're they're split across multiple crates so it's not one one big thing anymore. But that's again something. I don't know maybe some not something to think about it too much think about too much right now but maybe consider in the in the future. Yeah, so that's pretty much the work in progress. Just a question. Yeah, sure. For my understanding, so it means that areas V6 is using SQL SQL and behind the whole SQL X. I didn't get the link between SQL X and areas V6. It's it's a development dependency so it's only used in tests. It's basically because like to be able to test everything properly. So it's only a dev dependency. It's not part of the like as a user you're not going to end up with it. Okay. It's basically. That's it. Yeah, I know it's you. You end up with it through the live vdr tools dependency right. Yeah, I guess ultimately. I assume so. Is it in live vdr tools though. Yeah, yeah. I believe that's the version of the indie wallet that we're using based on SQL X. There's a couple like sub crates within the VR tools so it might be one of those tunnels. I guess. I guess. Yeah, it's here. I see. Well, yes, I mean, it's not. Not necessarily something we have that much control over, but and especially not a lot of work we're going to do on this since we basically plan to deprecate it. But it's not being used in every ccs as a thing I don't even know why it's being used here to be honest. I would assume it's also just for testing. Especially since it's just about SQL light. I believe it's for the indie wallet that we're using the wallet behind pdr tools. There's an SQL light version of it. And that's default to when we create an open indie wallet. Okay, so that's basically how the interaction goes with the wallet. Yeah. So it looks okay. And the SQL light. Front end sort of. Okay. Well, um, yeah, I mean, again, not not that familiar with this. But I guess that's that does make sense. Um, in the end, the ideas, the again, the overall idea is that as a user of every ccs, you don't necessarily need to worry about that. It's basically behind the scenes in terms of communicating with the wallet. Exactly. Yeah, so regarding upcoming work, I think, again, we kind of have our hands full. You George with the holder refactor and me on getting the messages refactor done. Probably again, like we've been saying for quite some time now, at least when the messages refactor is done, then we're going to start working on the other state machines. George went. I guess is already on to that. So hopefully I'll be able to join join soon enough. Yeah, and there is this mentorship program. Believe there was a list. Maybe this is not it. There was a list here, or somewhere. I don't think I have it handy. But it was a list of projects that we basically had up for the like listed for the mentorship program. I don't know exactly where it is. I'm going to have to look it up. But maybe my last word, last agenda. I'm not sure. I think. Yeah. Yeah, I believe it's here. Okay, there we go. Yeah, so there are quite a few ideas here. Patrick mentioned that. I had a brief chat with him about this and he kind of wanted, like, to have some sort of ideas that would be a bit more interactive, you know, not have someone that would just write documentation or tests or stuff like that. It would still be a nice thing. But I guess it would be nice to offer. I don't know, maybe a better or broader learning experience. So there are quite a few ideas here. I added those. The protocol registry was before I was considering not even doing it as of yet, but or yet, but I thought, okay, I'm going to have a basic implementation of it. I'm going to modify this basically listed as an enhancement that could be done. It's a bit more advanced, but if anybody picks it up, I can definitely guide them through it and it would, in my opinion, be a fairly nice learning experience in the end. But yeah, feel free to add ideas here if you can think of one or review the existing ones. For instance, there's this embedded device series agent. That's not going to happen at least not anytime soon. It's simply because an embedded environment you're a bit more constrained at what we have. And what we're using in in areas BCX right now. Technically I guess that by setting a global allocator because that's the main issue, depending on the microcontroller that you're using you could technically do something with with the current implementation but again that's a really abstract idea. So it's not like we expect anybody to come in and spin up an embedded agent. At least not right now. Yeah, so that's about a mentorship program. I don't remember the details. I believe there was a deadline. I don't know about the week or so. I think until the 15th. So yeah, not not really sure what the next steps are, where if there's some sort of application, I believe that the overall idea was to kind of compile a list of projects that we can have people work on and help them with. And then there'll be like a committee that selects a couple of these projects from all the only submissions from all the implementations. And yeah, a couple of them would would be up for the for picking for people that are interested. I believe that was the idea but I don't remember the deadlines that well I think it was the 15th in terms of that project submission so once again if you have any ideas, something that would be would be useful for the ecosystem. Feel free to add it here. Yeah, and that I guess that brings us to the did come to 2.0 version. It kind of derived from, I believe this implementation. Which is an implementation of did convie to fairly basic one, and there's one more for some reason, but ultimately, I honestly like this a lot. So I'd like to maybe take a minute to talk about it. I believe that it can be one protocols and message to messages structure. Have a lot of issues and inconsistencies and just overall some some design that could be done better. Did convie to comes, like probably my favorite part out of it all is that there are no longer the concept of decorators doesn't exist anymore. They're basically called headers but they are at the message type of the message level. No longer nested throughout the message so the parsing is going to be simpler and processing is going to be simpler. They basically formalized. I really invite you to have a look over this if you haven't. They basically formalized a lot of concepts like attachments, threading. Pretty much what you can think about even out of been messaging. Yeah, there are some some protocols already implemented. I believe this is not ready. It's still in sort of a draft state. So there's still things to be figured out, but overall it looks, it looks really good. If you ask me. The overall implementation is much simpler. Yeah, so I guess in the future, not sure how distant, but we will probably start considering this. I had to look over the current implementations. I think we can we can do we can do better. And I guess one reason that is simply because we already kind of have a lot of a lot of the infrastructure in place where we'll have it, especially with the new messages great. In terms of like parsing, I know a message based on its type and all that stuff and message the structuring and all the other things. So yeah, I guess we'll see. But again, it's worth taking a look at sooner or later. I believe there will be a transition. At least that's that's what I think right now. Zia is the goal to try use that did come dash RS great or Yeah, as I said, so there is this one and there's another one implemented. Personally, I wouldn't. I think we can implement our own and do a better job. It's extremely generic of very high level parsing. Not really, I know, not really impressed with what's going on here. I guess they're good as a reference and again it could also be that if we were to stabilize this would be enhanced to a point where there's no need to like implement our own, it would basically satisfy our needs. But right now there are a lot of improvements that could be done. It could also be the fact that we might even use this and maybe start contributing to it. It's a completely, completely open discussion. So they're all I guess valid ideas and we're going to all decide together how we're going to how we're going to approach this. But as I like to say, this is a problem for another day. It's just an idea worth thinking about. So yeah, that's, that was pretty much it. Any topic you guys want to cover in the remaining time. That's from my side. Thank you. Just want to thank you for the moment. I just want to join the meeting from time to time to have a look at how the project is going because that's possible that in the future will contribute to that. But yeah, other ones that will be more in a passive way and not in an active way. Alright, hopefully we can convince you down the line. You know, to maybe, maybe become more active. Again, no pressure. I'm just joking. But we would like, we would really like to see and this is basically the whole idea. And even why we're going through the refactor. Things can be done in a better way and we want to do them in a better way, even if it takes a lot of work because there are already implementations out there. There's the Python implementations. But we can, and we want to take advantage of the rust language to basically make this as perform as we can, or while not maybe sacrificing, sacrificing user experience for it, but that's basically the strength of the language. In the end, even if just using it through a wrapper in a different language through FFI or things like that, that's basically our goal. And yeah, we're really glad to see that people are tuning in. Even just, you know, listening on how the project is going. I hope you guys like the direction we have. And yeah, we're always open to suggestions. Yes, thank you very much. Thank you also for all this. Just a thing that you make everything public and very visible to the community that we appreciate it. Thank you very much. Yeah, yeah, it's great. Thank you. All right. Okay, guys. If there's anything else, then thank you for participating and thank you for everybody that's going to listen later on. And we can hear each other next week. Take care. Cool. See you guys then. Thanks for running the meeting as well. It was really good. Thank you. Bye-bye.