Hi everyone. Mary at Espresso Press Design. Thank you for stopping by. Sorry, adjusting the camera. Thank you for stopping by. I hope you're all doing well. Today is a variety. I'm going to do some wax paper, more wax paper, glassing type technique I came up with as I was trying to clear up my little wax paper scraps.  I'll get to that in a second. I've spent most of the week coming up with ideas of things I would like to do for my craft show. I thought you might like to see that and give me a few. I would like some help on one particular thing. So my high ticket item is probably going to be something with shaped flowers. I make these and put them in shadow box type things and this is one of the ones I have that was done on a tag. So I'm going to do that. I'm going to do note cards because this is one of my favorite types of cards to make. I took some time to create some bases here that aren't finished. I really like to do something with my handmade paper. This is another version of the shaped flowers. I'm going to do something with these, the Mamagami paper and bookmarks and this is my low ticket item magnets refrigerator magnets because my daughter can help me do these and we can make a bunch of these in no time and there might be kids there. My other I watch these craft show videos all the time and treat type things are always a good seller. I have a feeling the crowd is going to be more pink strawberries if you know who I'm referring to than artsy. So I would like to do some things like this but I ran into a problem almost immediately and that is the majority of my paper is single sided aside from graphic 45, stamp period and Tim Holtz and this is the only other set of paper I have that doesn't crack or that's double sided. So if you can recommend a double sided brand of paper that doesn't crack and has more of pattern type selections than I don't want stamp period. I don't want graphic 45 although they do have patterns and I don't want Tim Holtz. This is Waylene but the selections that they have available right now really aren't what I'm looking for so even though I like the paper and it doesn't crack I just I don't like their particular patterns and I'm looking for patterned type paper and variety of colors and styles. Okay so let's get to this. In this experiment I had a dumb moment I really like this bag it uses my Momagami flowers it's not strong enough so I thought well maybe I could just double the paper double the wax paper and that's what I did and it turned out and it's much stronger and it's not going anywhere and I also thought this kind of looks like frosted glass or ice so maybe for a winter journal or a Christmas ornament I could come up with something to do something with crumpled wax paper so that's what led to this to these they're actually pretty stiff they kind of feel like laminated they kind of feel laminated but in my humble opinion I think what is probably going to show up better especially when you have an image is probably something like a silhouette so I got some of my die cuts butterflies bird and I'm going to use that today these are much or even something like this stamped stamped and fussy cut butterflies so with this technique it goes a lot faster you don't have to wait quite as long to let it dry than the previous wax paper techniques so I have one here that's um dry enough I have my scissor here I have my wax paper and someone asked for the embellishments what side of wax paper I laid atop the image and it was this type of wax paper it's wax on each side I was not using deli paper or parchment paper I was using regular wax paper so that answers that so what I did this one is a triple layer so what I did I got my glue I'll show you how I glued it in a minute and then I ran it through the scissor which I have my scissor here and I'm going to stand up and run it through for you I'm not going to bring my scissor over because my space on this table is limited but I'm going to show you that I um I have a sandwich in there just because if I get a glue squirt I don't want it messing up my plates and I have it a triple layer so that I can get a good press so I'm just going to run this through standing up here let me move my coffee and hopefully hopefully my glue wasn't um no my glue is not totally dry so there's my little specimen specimen type thing when it was completely dry I just trimmed trimmed the edges so it was square if it's not dry it doesn't work very well in the guillotine or the trimmer because it acts like wet paper and it will tear so wait until it's completely dry so I'm going to show you the assembly and these are the types of scraps I had lying here in my what I call my to-do pile that has to be cleared off that has to be cleared off this week that's for sure because my table was getting crowded so I just crumbled it up hopefully this piece is big enough if not I'm going to use a bigger one or cut a bigger one and I think I might because there's not enough space around there just your bigger one so yeah I think a silhouette will probably end up working better and I just folded it and this I'm using the same glue linoco linoco book binding glue I didn't experiment with this one with different types of glues and this one is much easier because it's pretty easy to spread in my glue bottles my glue is really low should have filled up my glue my glue is low and then I just placed that image there I didn't worry about putting glue on top of the image but you can and then that was it ran it through the press and then trimmed it up as I wanted for the bag I'm just going to let that sit a moment for the bag I have the paper and this is as wide as the paper here's the trimmed edge of the paper and I just folded once folded once folded twice and there's the shape of my bag crumbled it up pretty good enough enough wrinkles in there evenly distributed you still see my fold lines trying to remember here yes trying to remember where I how I placed the images okay there we go up here are the flowers I mean up here have your um and I think maybe this one I also put the glue here I'm wiping my hands just place my flowers my mom and gami flowers because they are very thin like tissue paper I just back them lightly tack them on a white copy paper before I punched them out to give them oh but I didn't realize that I thought I checked all those oh well I'm going to have some lettering on the back of one or I just won't use that one use my flowers of glue there yeah I'm pretty sure I put glue down this side as well yeah see this was quick just some manner of uh doubling the paper to whatever size bag envelope specimen you would like it over hold it over there we go if you want it you could also do this side with the flowers I did it but I you know I might because you can still see them through the back so I don't know how much you care about that okay so that's basically all I did was double the paper if you wanted this to be a little more sturdy just do another layer I don't have enough paper there just do another layer I have a big bottle here somewhere that's way too much that's way too much get it all in there and then wipe some off that's what I'll do it's going to squirt I know that well there's nothing there to tear because there's no it works a little differently going wax paper to wax paper than it does wax paper to image to paper don't have to worry about it quite as much okay so I'll run this through the press first then I still don't think that's completely dry feels cool so that's how your image would come out and then I wait for it to dry completely and then trim it I'll just run this through I'm going to stand up run this through even it up a little bit a shim here these aren't big enough to prevent a glue squirt but it's a little there's not enough pressure so I'm using a shim so there we go and then I glued up my seams I personally like to use the embossing folder and that's another thing because it was doubled I didn't have to worry so much about tearing the wax paper so that was another good thing for the envelope obviously I didn't use a embossing folder but it's just glued I don't think it's going anywhere it's kind of like my little bag here it's glued it decides and aside from tearing apart the glue isn't coming loose so I just took some little little ephemera type I took some little stamps and I scattered them through there little things like that stamps that'll be up to your imagination what you want to press between them leaves would look lovely dried pressed flowers would look lovely so then I just assembled my bag that's just basically like a new sheet of paper that you would use however you would use it but in my humble opinion I think if I were to do it to do an ornament or something I would probably go with something that's more of a silhouette type image than a detail type image or I would choose dark colors because as you can see the red shows up better than the pink that's not too bad but I personally think the silhouette type image is a lot better for this type of thing so that's why I grabbed some butterflies birds so that's let me run this through hopefully this is explanatory enough because I really prefer to spend the rest of my day crafting then doing a video but it was just another experiment that's how I approach things I like to explore see I got a glue squirt I like to explore the mediums just like I would is if I were oh wow I got a major glue squirt just like if I were painting or something I would like to explore my paper explore my brushes explore my watercolors and that way when I begin a painting or something I know what what watercolors what brushes what paper is going to give me the result that I want so that's just how I approach things and I don't see paper crafting similar to the paper cracking I don't see paper crafting is being any different and I or mixed media or anything else I like to explore and learn the medium before I that's part of the fun and when I do begin something I won't have to be disappointed I already know if it's going to work or if it's not going to work hi everyone me again I accidentally forgot to delete a previous video so I ran out of space so I'm tacking a little on the end here of my last comment and if you have any scrapbook paper type suggestions I would truly appreciate it if you have any helpful craft show item suggestions I would appreciate it thank you for the kind comments on the previous videos unkind comments get deleted in my philosophy as long as I'm not committing a sin there is nothing I have to feel bad about and living up to my own expectations is hard enough let alone trying to live up to yours so there's nothing I have to be made to feel bad about including my voice my persona how I do videos this is new to me it wouldn't be my first choice of how I would teach a class I have taught watercolor before in person it wouldn't be my first choice of how to interact with people but it is what it is and it's part of the new economy I don't have to like it that's just the reality of today's world and I do the best I can so have a good day everyone I'll see you next time I hope you learned enough to find this helpful and I will be back next time have a great day have a great week bye


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