 Hey, hi George. Welcome. Thank you. How you going? It's all good Getting warmer over here in Prague. How's Australia doing? Finally starting to get colder, thankfully Perfectly aligned inverted Yeah, when is your summer? Well, it's now the cherry blossoms starting to blossom a little bit and Yeah, it's usually around like June Yeah, I would say that June is what I could consider summer here Yeah, definitely inverted then. Yeah Is it snowing in winter? Not not where I am. No, I'm in Queensland. So it's mostly just hot most of the time. Right. There's some snow, but yeah. Hey, hello. All right. I don't know if anybody else is joining. We'll see. But I think we can start in the meantime And let me show my screen. So the agenda is not very heavy today. It's pretty lightweight So, but yeah, we should probably start with that following the anti-trust policy from Hyperledger. So I'll just leave this Play this screen for a while. In the meantime, we'll come everyone on On another RSV6 community call. It's 23rd of March 2023 And this is our anti-trust policy notice. All right So let's jump into our agenda. So As a last time I mentioned I I swapped the discussions from the end to the beginning and I Kept it that way again. I think it's kind of better to Discuss unusual stuff or like some novelties in the beginning rather than let everybody wait until the end if There might be a new joiners who just are interested in some like announcements. So starting with that Yeah, just a quick update on the mentorship program. So we have our two mentorship projects pending right now There's a two project submitted one is for UNIF5 mobile wrapper. Another one is for Implementing Aries mediator on top of Aries VCX We do have one person who is already interested in in Picking some of these projects up. However, the the timelines for the the mentorship program is the The TOC I think that's technical Technical something committee of hype pleasure Is it's time to approve it until the Until the end of this month and then I believe 5th of April begins the applications from mentees So I I know for sure we have one We'll see there will be more people who will join or how it's going to go Yeah, but in the meantime I In the meantime, just a small bit on a other way to join And participate in in our community Is to picking up some of the good first issues which has been created Recently on github It was We mentioned we touched on this last week and so this is small small update here that It's actually catching up catching on pretty well and we have two new brand new contributors Submitted pull requests. Although these pull requests pull requests all are still in progress Nevertheless, I think it's pretty cool to to see, you know, new activity new people Picking up some some issues and Yeah, just I guess this is like a good signal for us that this is actually like a good approach to get some helping hands and Just do a bit of a public goods to educate like help people get into rest get them into Aries and you know, possibly Possibly a raise a valuable Contributor long-term contributor for our community as well So there's a few which I've created before and again, I would like to encourage you guys to or anyone To create these good first issues and time, you know, find something Lee something of a reasonable scope Which could be picked out by beginner Assuming that, you know, it's like reasonably explained. So Um, I think the the more detail more detailed description of the issue. You are willing to provide the better 40s the better 40s newcomers And yeah, so just just to note about that Any any feedbacks on this first two points guys, uh about the Github issues or about the mentorship program Well, that seems like no, so that's all good. We move on By the way Right Yeah, and then I just wanted to Act on the the parallelization of maybe just like something to keep in mind Uh I was just thinking I currently we have this like big PR from from bogdan going on and and obviously like sometimes it's difficult to Like parallelize and it's it's it's it's just like Feels risky to start a new work when there's something big going on so So I just like would like to I don't know suggest or yeah, keep in mind like going forward Just to think about like how can we you know Make progress but at the same time like enable make make sure to enable parallelization So for example, since you guys, um both bogdan and george are on call I'll just like I talk directly about like to you So I was just thinking like going forward, right? We'll finish now the messages create And then then there'll be the bending work will be too To integrate it in the like rest of the code base So my suggestion here would be like I think we can do it like piece by piece. So uh So we don't have to work in kind of a Like waterfall mode that uh that one person like take like you know does it all But I guess like we could just start Integrating this new message. Oh, actually, I mean, I'm not sure it's very possible but uh But if it's possible, I think we should at least we should try to try to Like integrated maybe piece by piece so that like Maybe one person can integrate the new messages into One protocol another person Can put into another protocol um And and probably like Also the the state pattern refactoring can be happening at the same time I know, I mean it might be it might be a risk here Maybe it requires more coordination, but at the same time it it seems like it seems pity when when There's no like multiple streams I guess of of we're going in what well, I know that you know, both of you guys are Uh, you know, very very capable So I don't know. What's your guys? thoughts on this I had some thoughts about this before and in fact discussed it with Mira I think that we could probably achieve that if We implement some conversions between the old message types and the new message types So that for instance, let's take george's example and work on the handler not the handler the folder Stay in shame. So If if he continues to work with that and let's say, I know we we merged today the message is great And he picks it up and starts using the new messages Then we kind of have to keep and check the fact that this will be using new messages and the others will be using old messages But as long as there are these conversions in place, I think it should be all right So that would technically allow us to like do multiple things at once and not You know without too much hassle I think I guess yeah as far as it's it well in terms of this particle like Matter the messages like I guess if the messages like not leaking if there's no like no conflicts like If these two craze two messages craze are not both leaking out of areas vcs and they're just kind of You know encapsulated within areas vcs and there's You know two versions of the messages Used That should be probably fine. Well, maybe it might be problematic if there's some some apis which for example are currently returning You know every like every message Of the old crate and then there will be like similar api, but returning Destructs of the new crate might be a little bit messy, but Yeah, I mean there probably are instances and the other crates the agency clients the agent limitation Maybe even leave the vcx I don't know about the union to fly a wrapper, but there probably are some instances. I can't tell sure, but Ideally um Like having the conversion place. I think it could just be um um Yeah, I mean it would have to be at a message level not just the the big enum containing all the possible variants, but um Ideally, I think it can be just like a another line added just for converting the message You know when let's say you pass a I know some sort of request message And then you just do a from the old the new one from the old one It could it should technically work I I think So it will require some work, but I don't know if it will be that big of a hassle Go ahead. Yeah, are you talking about sort of like a public transformer for Turning the old messages into new ones because yeah Just implementing from the from trait I would do in the old messages crate. So then when we get rid of it, we get rid of the of these things as well um And basically just implement from an old message To the new one And then whenever you need to transition you can we could do it back and forth. I guess we can do it both ways I don't know if would make sense, but we can yeah, I mean Theoretically right if someone is serializing and storing an old message It should be able to Well, I guess serialize back into the new form of it, right? Because it's just yeah Yeah, so Right, right the the data structures changed In in terms of how rust sees them, but serialization and deserialization. I think I mean, I don't think ideally they should be the same Yeah, I don't know there were some things added that were missing one example that comes to mind is the Received orders from the thread decorator Uh, but that's basically optional. So if it's missing it's just not gonna have it um So, yeah, I I don't think there would be problems in terms of that I don't know that's that's my idea yeah, I'm sort of hopeful the migration for external consumers from the old messages to new ones won't be too much of a big deal because uh, I guess like I said the Thing that comes over the wire is still that jason string payload and now you're just I guess serializing it into the The new message rather than the old one um Alternatively if that's an issue we could probably Like duplicate the state machines and when they're all implemented just remove the old ones but That might get um I don't know it might get to be quite a quite a lot of Let's say read. I don't know redundant old code legacy code I don't know. Hmm. I think I think it shouldn't be uh I think we can I can I think in these case we can Make it without duplication is that it's not really functional changes just like maybe Dealing with a little bit different api right of that. Yeah, I mean ultimately, um I think we discussed about this Patrick at some point and there are these tags right in the in the repo so I mean People can just pull the code from an old tag old I know the current tag whatever tag is And just stick to that and then when the new release is made and let's say we replaced all the state machines and whatnot Then there would be a new tag and they can Start using that one so Like if if you just consider that then they wouldn't even have to do any sort of I don't know Transformation gymnastics, they would just have to pull the the code from that particular commit so Yeah, I mean personally um Just in my use case as a consumer of vcx I don't think it's going to be a huge deal migrating to the new messages At least in my situation Um Okay, they introduced in the type state patterns is going to be the right time to start using the new messages for sure Yeah, um I guess it's just about It would be it would be kind of The weird to have the two messages and keeping track of where you need to convert in between I mean if someone wants to do that, they definitely could and we can provide that um And we probably could use that, you know as we're developing So that we can work with these state machines independently um But From like from a consumer point of view, I would just stick to the old Where whatever current state is and then when everything is done You know keep start using the new release then I wouldn't personally I don't transition to having to Half of the state machines in one way and the other the others in one way and some of them using some message Great and the other is using a different message great Hmm But technically they can't I don't know it just feels more cumbersome to me I think like uh the message the message conversion or like integration probably that should be Done at least like like we didn't want to release. Yeah, like I would agree that maybe maybe the work itself If it's possible, it would be good if it can be paralyzed like maybe two people, you know One can I help all the other to actually finish this work? But then but then the the might I think like 054 really should not have the old messages create anymore, but and then we can I don't know and then independently of that We can I think start Implementing the type state pattern like piece by piece even in 054 We might include you know already the type type state I'm not holding or something like that, but That's that's a good idea actually. I don't know why I disregarded We could technically just integrate and deprecate the old messages create sooner And for instance like George could start using it. It's not yet Mars, but hopefully soon enough We're getting there but Like George could start using it in the holder that he's working on and maybe I could start integrating it into the old state machines um, basically it would be like a I don't know sort of dummy or not dummy, but Kind of silly integration like just replacing the messages as they were with the new ones Uh, no You know fancy decomposition or treating threads in some whatever way. Yeah. Yeah So and I think that's also like the goal For using the type state pattern in the state machines. I don't think we should focus on like optimizing Or just abstracting away the message processing. That's probably a completely different beast Like handling all the threads in a uniform way or and whatnot Hmm that we that we could probably do later on Uh, because it we would end up in the same spot where it would be too much to handle I guess So, um, just to be clear, uh, so we're talking about by 0.54 Uh replacing messages entirely in areas vcx the crate That's my suggestion that uh, throughout the until the next release we can kind of You know start replacing it iteratively, but 0.54 should not have the old messages anymore at all just delete the entire crate Yeah, fair enough. Nice. Yeah, and then and then Since it would be used everywhere the the state machines Refactors would be more consistent, I guess And it would avoid all these Weird conversions It's probably it's probably the way to go. Yeah All right, then Shall we move on In the agenda, okay fine by me. All right. Um, so yeah the overview of recent work done so those Not much stuff happening, but Nevertheless, that was two prs for myself I think I covered it already I actually have a wrong one here That was two prs from me All right, and I we we covered it already in a previous week. So that was like First it was the first round of changes was I think some some method get a vocation status And the next round of changes was actually Removing or kind of renaming that method And it's described here extensively. So this is pretty much the the only I think Yeah, significantly recently This actually changing the api. So it's breaking change but only for the the proof verifiers In terms of the api and also also some serialization deserialization Impact consequences Uh with provided migration strategy Um, and I think we'll be just to touch down on this a little bit. I think this is something I will be doing A lot may possibly a lot in Like upcoming releases with the changes we are planning for the state pattern. So Oh, I guess we'll always have like two choices either just kind of start from scratch and Just say like oh, this is new proof implementation. Like let's say this is new Uh, like a holder implementation using state pattern. It's it's completely different and it doesn't You know, there's no migration path to the old ones and here's just a new set of apis Or the alternatively we can do migration like this where you basically Re-serialized the old instance and You deserialize it and then serialize it into a new format and you You you you go on with your life, right? So This is the first time I think we we actually do something like this this kind of Backwards compatibility migration support, but I think we'll we'll we'll be running into this kind of stuff possibly a bit in the upcoming future Uh, next up. Well, that was a release 0 53 uh, that was after a while Since the previous release. I believe that was uh That was a month ago so releases, um 10 hours ago 0 53 And 0 52 was yeah, I was last month and as for the changes um Yeah, I I can't conclude the changes in 0 53 3 right at this call because our Job generating change lock is being broken. Apparently it somehow doesn't pick up the changes from the 0 50 between 0 52 and 0 53 Instead it it it includes all kinds of all changes. We shouldn't be here So I should we should create that issue to fix this change lock job Which is being auto generated from prs So sorry about that I'll I'll Go ahead and update this Change log manually for the 0 53 version after the call Uh Next to check on our progress as I mentioned before. Uh, we had uh kind of good initial success with the good first issue stuff So we had uh, stephane as a first uh contributor a first time contributor uh picking up One of the issues to uh to refactor in code attributes Uh, it's in progress and we are having a bunch of discussion here So feel free to hop in and share your ideas if you have some about this your thoughts Uh Next we had also andy vain picking up one of the good first issues Uh, but andy running to some uh problems just setting up the repo and running the test stuff like that. So He'll need to fight through that. Uh Nevertheless, uh, yeah, these are kind of uh initial state But I wanted to give honorable mentions to our first First first uh first time contributors Uh, and next up moving to the messages to credit would be we we discussed a bit already I assume I I believe it's uh Nearing completion uh day by day almost there I left my review recently um And um Yeah, I don't know. I'll I'll leave a word to to bogdan as the owner of this PR If you have anything to share or any update Whatever is on your mind Yeah, sure. Um, so thanks for the for the review. First of all, uh, really thorough. I appreciate it Um, I already addressed a lot of the points you you had um, maybe And by the way, I had to like I removed that Formatting those formatting options. It was indeed quite a bad call to introduce them now. We can do it after um, and I basically had to um Sort of cherry pick the the commits and put them back and as they were and you know that and I rebased based back on main Um, because it was uh, some things were merged in the meantime. So right now the PR or the brand should be up to date uh, but because of that some of the Conversations you you had on the in the review, uh, you know, some of these threads are kind of missing um, as they point to some Obsolute commit because I had to to push to force push the changes Uh, but yeah, now there are less way less files changed. You can already see it 75 They used to be like 480 something this the the formatting options went through all the files in the workspace um, so I reverted that maybe something Kind of worthy of addressing is the timing decorator Very good catch there. I forgot about reading treating that As it should be so that's been handled um, there were some testing suggestions which Have been which have been I've been implemented um Yeah, I don't know what what else was there. Um, let me try and pull up the PR myself Let's see But yeah overall, um So things are moving, uh, we're almost there. It was just a matter of documenting and testing stuff and Kind of settling on some namings um Right now Pretty much. I think the only thing remaining to document are like the messages modules Maybe adding the like it suggested. I also had an item in the list Like adding the rfc related to a protocol in the module. So it would be easy to track what these messages are um and Yeah, some testing Like kind of related to what we were discussing earlier, but testing some of the Like testing some some serialization quality between the old crates and the new crates Uh, the new old messages and new messages. Sorry But yeah, the old crate and the new crate. Um, kind of to You know, make sure that, um These things are as they are supposed to be Um, maybe so Just saying them maybe once one one idea here. Maybe like right if we try to like compare those two crates Although it's probably was suggested originally by me now. I'm not sure if it's like like good like necessarily the most efficient approach like Maybe what we can do is like, you know within this release like just try to integrate it into the rvc checks without Without doing like preliminary check if we like building the, you know, serialized exact same messages Uh, but just kind of, you know, try make it work and then We can we can just plug that new version into the uh, every's, uh, you know Every's agent test harness And I'll see if we still have the same interrupt with other implementations and if I Significantly can drop them. Yeah, probably we have like some we introduced some issues and we can start to investigate, but I guess Checking those serialization between these two crates ahead of time like Will be the kind of code we Delete after all anyway, since we'll be deleting the original Yeah, that's true. Um, okay, then I'll remove the item from the list or strike it through Um, but yeah, so essentially it's just some some renaming and some that documentation at the module level Um, and maybe just exposing some some types through some re exports But that's pretty much it and I would actually like I'm more than open to ideas in terms of naming stuff So the two main things are You can scroll down a bit. It's under the renames section those two. No, no In the So these two things you also mentioned them in your in your review. I also had that in mind So basically just naming those two to something I would It would be really really nice. I think to have sort of like, uh, like the same name uh, basically just representing the The implementation Of the because these uh directories Basically hold the these two modules hold the actual implementations of either the protocols like the the contents and the curators or Um, you know the message type Like the protocol we use for deserializing the message type and protocol registry for that. So It's not necessary. I don't know just just figuring out some some decent name for them um And then there's also um I think it would be also nice to try to avoid collisions between um Like that the protocol names and the message name You know because you would have this um, like the message type would be I don't know, let's say Connection and then connection v1 and connection v1 point underscore o and so on and ultimately the Protocol message itself would kind of follow the same convention, which might be okay, but maybe having something to Um, sort of distinguish between them and avoid collisions if you have to import both of them, that would be nice um I just don't know Nothing comes at the top of my head, but feel free to um, you know to suggest something but I guess those are the I don't critical things Uh, not necessarily critical, but the the things I just can't can't really figure out um And then I'm basically going to take care of the of the documentation uh today the rest of the stuff um and re-exports And yeah, it would just be these renames and then from my point of view This can be merged Provided that you you guys don't I don't have anything else Um to note from from your reviews Yeah, I'll I'll have a review soon. Uh, sort of waiting till it was right near the end and sounds like we're there Yeah, fair enough. It's uh it's definitely better documented now probably still Still lack some stuff here and there. I hope not that much but uh, at least in terms of the more intense stuff I think I I I tried to document it Let me know if it's not well enough and we can adjust or You know Yeah, great. Cool. Thank you Yep, thank you Yeah, so that's that's pretty much it Mm-hmm Okay, uh So I guess let's let's move on and that brings us I think pretty much to the end of our call possibly It's upcoming quirk item here is just copy pasted from the last week. So basically I'm we're still on track with this one and then we already uh integrated like discussed this stuff all extensively within the when we talk about the parallelization Pretty much like how are we gonna do all this work in efficient manner? The most efficient matter manner where we can parallelize. So I guess this is gonna be like now like soon finished I'm done my book done and then Then in a zero we have recently had zero fifth three release and in zero fifty four release We'll have fully integrated the new crate into areas vcx will delete the old crate and if Our if our capacities allow, maybe we'll actually Like finish some of this some of this new implement type state type state implementations, but That's pretty much anything independent of these This can be some of these can be done zero fifty four and The rest of the rest of it can be done later on And yeah, I guess then let's see maybe zero fifty five and and and on Some of these other items can start to be addressed. Maybe also in in parallel with the type state migration Yeah And that's our last point and meeting discussions. Do you Does anyone has anything else? You would like to Mention or discuss. Yeah on the on the video to us that Um I had that p.i. In draft a little while ago. Um, where I was putting Video tools behind a feature flag. Um, and then I sort of got lazy with it and should come back to it um, but Yeah, yeah, I'll I'll try I'll try to finish this up soon. Um, I was going to ask as well if if you think it'd be a good idea to Also put like the I guess the shared modular dependencies behind a flag as well So then you can sort of switch between them. Um, so like critics and indy vdr Uh, right critics indy vdr. Well, I first I I saw that it's actually passing So I guess this is like close to completion. I suppose right because um the ci works Maybe the Like with the state is like what what is actually missing right now other than the the suggestion for adding the additional feature um It's just there's a small test that uh, doesn't go well because it uses like an old uh, libindy mock concept. Um, which In my opinion should probably be swapped out for like a more general mocking. Yeah Yeah, yeah for sure. That sounds fine. Um, but that's it really like I've been using uh, this privately and it sort of works as expected where You can have aries vcx imported Uh along with something like aries asca and then you don't get all the dependency conflicts Um But yeah, there is still the dependency conflicts that we will need to fix up eventually But it works as expected. I guess yeah, right and with your uh to to to your suggestion So you're saying that okay, uh, this this feature flag here is to hide vdr tools behind a feature flag. So if you are using this flag, right, uh, vdr tools Then we leave vdr tools become optional and so in case You are using the the kind of uh Those profiles those implementations Which are using the module or stuff like you don't you simply don't need this very because you have uh You have Yeah, yeah, exactly. You have all the other You need um So how do you go about if you use if if you enable this right now? Then how do you go about what are you using ascar? Uh, like privately Yeah, privately. I've been playing with ascar and also just mocks of it just to test that it's working correctly Right and and so if you if you do this feature flag, uh, then you don't have those dependency conflicts We've been running into I suppose, right? Yeah, exactly and it cuts down your number of dependencies like significantly by hundreds I see Yeah, I really our tools has like So the the tree is really uh, like Long and quite deep. Yeah, I think it's like 500 lines of like dependencies when you print out the entire tree You're maybe 600. It's quite beefy. Yeah Yeah, exactly like realistically While we're in this transition period of vdr tools to the shared stuff um Consumers are only really gonna want to pick one of them either vdr tools or the shared dependencies. They Probably won't be in a state where they need both Maybe while they're migrating, but that's pretty much it Hmm and so we'll just the suggestion the additional suggestion, you know the next feature flag you are saying um So like the alternative dependencies to vdr tools are at the moment Individia uh indie credex and in the future areas ascar So they could also be Optional dependencies that are put behind a feature flag Similarly, how the autos is like you see that or If you're using vdr tools, then you don't need Indic credits, right or like the the those modular ones Yeah, exactly. Yeah, right. Yeah, that would be nice. I think You know We are in position where we would actually use it. So it would be nice. It would cut down our uh dependency uh Like effective dependency, uh, at least in the in our binary. So there'll be definitely like nice to have feature Yeah, yeah, exactly. Um consumers such as yourself and that's that's why I've put uh vdr tools as the default feature flag there So you wouldn't need to change anything when importing areas vcx if this pr goes through Um So yeah right Awesome. Awesome. That sounds good. Let's do it Yes, need to stop being lazy and finish it up Yeah, I know the feeling The situation All right, anything else any other points? Maybe just uh what we discussed about the um the state machine states about like sending a message and receiving it and how that um Like how the how the state machines are really not um You know, they're they're sort of inherently flawed from my point of view and we discussed about this. So the overall idea when you think about it is the state machines pretty much have like two types of states either a message was received and Or a message was sent There are the initial states and the end states but those don't really matter from this point of view really So when you receive a message, that's fair enough You receive that you're going to process it you advance the state machine But when you send the message Like this concept of sending a message, especially when considering a like transport Abstract protocol Simply saying that you sent the message From my point of view doesn't really mean that much Because there's no real guarantee. It was even received So you send the message you advance the state machine but That doesn't really do anything on its own. So The overall proposal was to maybe consider You know, at least for our our crate, but um To consider just the the state of the the state of the state of the state machine Like transitioning to the new state to just be done when the new message is generated And then we give the message to the user And they can send it to whatever they want with them with it They can retry or drop the state machine at a certain point in time And we basically encapsulate that message that we generated I don't know. Let's say you transition from a requested to A responded state then the responded state would have the response the user can always deserialize the state machine get the response from it try to resend and whatnot The idea behind it would be that this way Our lives are easier and we don't really make a promise that we cannot really keep because Sending a message like this this concept of advancing the state machine because sending a message Doesn't mean the state machine doesn't get in an invalid state You can get in an invalid state where you're never going to get anything in return Because you have no guarantee that your message was sent. So instead of making that You know going that extra length of sending a message at least at the like lower level building blocks um I suggest to just Have the state machines not do The the message sending just the message generation And leave the sending to the user to handle however they want Yeah Rather than transitioning to like message sent it'll transition to Something like message generated and then there's a way for them to pull that message out so they can send it Exactly. Yeah Next transition would be like basically received process the response, right? Yeah, yeah, so you you always know when you get the message Yeah, so it's a good idea Yeah, I also agree. I think that's uh That makes sense. We could adopt this as we are Going to be rebuilding the state machines with the state pattern I guess we could have a bit of A bit less states than before perhaps Yeah, we basically just go through that extra extra step For no good reason Maybe I don't know Time goes on and we might build some sort of like more batteries included framework but on top of various pcx Then maybe we could do something like that, but that would be a different thing Whereas as far as I know for the library. We're basically targeting lower level building blocks Yeah Yeah, I think I think it's good and also since we are talking about this I remembered of our last week's discussion and I just want to Make sure that George is like synced up like without George. Did you have a chance to to Hear the last meetings call No, no, I haven't No, that's fine. I mean, of course It's like a one-hour listening and you need to know which are the important spot spots like It's quite It's it takes more effort to listen to recording than actually attending the meeting. So since we have a few minutes left I would like to maybe I just kind of Revisit what we discussed last week because we were Last week we're discussing with Bogdan on a meeting about Some of the like guidelines we should be we would like to be following now for the You know the new implementation states learning from the mistakes which has which been done in the in the original implementation And and those basically like the three main points plus the today's one so Yeah, the first thing was The first thing was Uh, basically approach for the final state So right now what we do Uh, pretty much in all of the protocols, I believe is when we have final state, let me actually pull up some code Uh protocols and we do issuance issuer Uh, and I think this is more related to the like issuer slash verifier side of the protocol usually So that there's this often time like a finished state But then the finished state itself has status which can be success I mean, actually this is seems like way too many But just the entire concept of it like that there is a status your finished state But there could be like, you know different ways how you could have reached the finished state And so the finished state means that it was success or that it was also failure or You know, apparently like different kinds of failure And it's kind of It's kind of That that was a question should we follow this one should we Keep this pattern having one finish state with Substates as an attribute or should we just have multiple like multiple states and I believe now I believe that the the conclusion we reached look down correct me if I'm wrong is that we should have multiple of these states instead of trying to Put in the substates Is that do I remember correctly? I mean, so the idea was that um Yeah, pretty much just have multiple states. Um, so We would basically generate multiple types. Like if it's a finished successful state, then that would be one time, you know in the generic Whereas if it's failed then that would be a different type and we could handle them like that And basically when you have a let's say valuable transition like that, um You could just You know the return the result where the okay variant is the successful state and the error variant is the failed state Yeah, yeah, because because uh Usually this different The finished state in different substates can have different type of data associated like If you are success then you don't really have any other information But if you're in yeah, no as you do So if you're if you reach finished state currently with success then this data will be said And it'll be actual string and here will be some structure But if you reach the finished state through Like a fail because you received a problem report Then this will be actually none currently. That's why we that why it was originally made option But on the other hand, you will also have like a kind of extra parameter here For this enum with the detail about the error Like error which occurred. So basically we have like one state But that itself can have like many different kind of like sub variants and combinations which are valid and some Some of the combinations wouldn't make sense at all. For example, if If if you somehow managed to build finished state with status failed But you set the credit ID and revocation info, then I don't know what it means And just hard to understand like which combinations are valid and which are not valid It's it's not always in the first site. So that was that's kind of main argument for I guess Making it into different states because then each state could simply have required set of data Which are needed for that particular my condition which occurred Does this make sense George we have any What do you think? Yeah, no, I'm I'm fully on board. Um, I started doing that in the holder type state I had a finished and a failed state. Oh good. It was awesome. Which it it lets you get rid of these optional types Because I guess this is the main advantage of type state, right? You don't have to rely on logical Conditions that that you as the developer know are probably true. You can just apply on type safety. Yeah, exactly. Exactly. Um But uh, also on Bogdan's point of uh returning I guess the failed state as the error variant is is a really good idea And that's something I hadn't put into the type state yet and Yeah, I'll adopt that Yeah, practically, I think that there should be a way to go and create the failed state as an error And whatever we do with it, we can handle it however we want Yeah, then then the next item we discussed last week was like this part. It's it's kind of under one point here, but it's actually Or it's it's No, maybe it's missing. This is more about the success versus failure, but uh I think one missing point here is to to kind of explicitly state the problem with Acknowledgements right now Is that Currently Oh, no, that's what we that's what we do and we agree to keep it. So the thing is sometimes the the Eris protocol includes Describes that at the end there should be some acknowledgement message sent to one of the parties And I was originally wondering on the last week's meeting if if this acknowledgement should simply be a flag in a finished state or The pre or if there should be two different states Like full blown, you know state pattern states One where we are expecting the acknowledgement and the next actual finished state where we have received the acknowledgement And we came to the conclusion that since since since since it's kind of like areas interaction sending this acknowledgement It should actually be Like a separate state. So And that's that's how it is. So basically we are not changing anything Let me find if where we have that kind of Uh condition, I think yeah for issuer. So for issuer right now, we have credential sent state And then we have finished state And The only thing well if you ignore that the structure looks different, which is probably like a different issue But essentially these two states are equivalent The only the way you transition right now from credential sent to finished state Is you receive acknowledgement And uh, yeah, we agreed that it should stay this way to kind of Since there's like literally like interaction between the two parties And we are expecting new message. We should actually have like separate state for After we receive the acknowledgement Does it make sense? I'm not sure if I may it was a bit messy explanation. I feel like Yeah, no, no. Yeah, that makes sense. Um, similar story with uh connection as well Right. Yeah. Yeah, it's also also like that there, I guess When you have completed right and you have I guess responded probably No, let's invite the inviter You have completed and you have Yeah, yeah the Sends a response Is that right? Yeah, and then If they get an act back then they can transition to completed Yeah, yeah, yeah Just we put here protocols as extra in the final state, but yeah, essentially it's it's the same thing The only difference is the acknowledgement between them So, uh, what do you think you do? I agree with this as well to have these states keep these states separate Yeah, yeah makes sense to me So And the last one and I think this is something we are all Already familiar with because we were discussing this in in your pr george is the basically that I'll pull up the picture because I Big fair pictures and making it making ideas visual Those in this pr Those is idea of That with the current approach sometime you call some transition on a state machine, but you don't know You don't know which state it's going to reach because it's conditional It conditional depends on the actual execution of the transition whether for example, you succeed sending the some some data to some response Or if you fail or perhaps you can fail Just like processing the response or I don't know accessing what or whatever Uh, we currently it will move you to the failed state But if everything goes smooth you goes to request send in this particular example and and so the idea is a kind of Kind of a linearization of the transition so Each transition function should either move you to one specific state Or it should abort and You might be able to retry it According to you know custom logic on top of these state machines Or you could yeah, just maybe after a couple of retries you can decide to Move into the failed state and and possibly send the problem report But the main idea is that one transition shouldn't Leave not deterministically to two different result states Yeah Yeah So these were like three sort of principles we're discussing and last week We should which we should follow for the new New implementations of the state machines and I guess the additional one As per bogans addition today would be the Reduce the IO and reduce the number of the states basically remove the states where we The states which only serve as a marker for the fact that some message has been sent to the counterparty And and and is the idea to replace them with like a Message generated state or selling of that nature Yeah, yeah, yeah exactly and and actually we are like as you probably know We have some of those states that kind of states for example, we have Uh, we have offer set that's when you set the credential offer as a issuer And then we currently have offer sent, which is the same thing just only after you have Sent the offer you created or same with that. I think on the prover side, which you're probably more familiar with Proverification prover we have here Well presentation prepared right and then we have presentation sent it's again the same same situation Yeah All right So I'll kind of put it together maybe here at the end of this meeting notes all these like four principles So we have it put together and we can hold on to it Anything else guys we are slightly over time, but I think it's fine Um, is there anything else? Not for me All right, uh, there was a productive and nice meeting we covered lots of stuff It was pleasure to have you guys Enjoy the rest of the week. Enjoy the weekend Thank you for coming Cool you too. Thank you Have a good one guys