 Hey, hey guys, hey, all right, so you get started. Yeah. So let's start with the usual antitrust police city disclaimer from my pleasure. There it is for everyone to read. Right. So yeah, welcome to April 6, 2023. It's again, once again, Thursday, 9 am UTC standard time. And let's see what we have on agenda on agenda today. So starting with mentorship program update. So there's, there's a news on that topic. Finally, there's, there has been an update from, from the review process. So our areas VCS project submissions have been accepted, reviewed and accepted. And now we are officially in a stage of accepting, accepting many applications. So once again, we have these two projects, we have submitted. One is for the essential UniFI mobile wrapper plus areas, plus every compliant mediation agent client, implementing pickup protocol. And the second project is areas VCS based message mediator. So these two projects are currently kind of nice and in harmony. One is somewhat linked to the other, but both of them as possible to work on independently. So yeah, hopefully we'll have some applicants. I have, I have catch the news that there are some people interested. So there's instructions here to how to apply. So if you go to the, how to apply link, it gets you to this mentorship page with all the instructions. You should make sure to read all these texts, but also the actual action step at the end is go ahead to the mentorship platform over here under Linux foundation and essentially find areas. There's only our areas project. And then you go ahead and hit apply, fill all the information needed. And you'll be one of the applicants. There's a calendar, like official also, let me know that there's like a schedule. Everything in the mentorship program is pretty much scheduled ahead. Let me see where can I find that information. Now I don't know where it is for applicants, eligibility, how to apply for mentees, okay, I don't know where it is, but there's a calendar somewhere with a schedule. Yeah, I don't know. But essentially, basically, starting yesterday starts a period for sending the program applications. And I think it takes dead last for maybe 10 weeks or 10 days or two weeks, something like that. And after that, we'll be picking essentially become the mentees among the applicants for these two projects. So yeah, I'm looking forward. Who are we gonna have on board here? And who we can support in learning areas and rest and all the stuff around what we do. Yeah, that's pretty much it here. Any notes? Any comments? It's awesome. Exciting. Nice. Thank you. Let's go ahead then. So, a brief overview of the work done since the last call. So we had from George the dependency feature flagging. This is really great step forward. I just did my review this morning and I added mirror and book done among the reviewers. So guys have a look. I think one additional approve will be enough. It's a green light for me. It's a great improvement. I also really like these comments here. It's really a nice cherry on the top to document all the features we have right now. It's a great job. Yeah, yeah, I was trying to map out in my head what they all do and then I figured I should just write it down. Yeah, it was a good idea. It was about the time. Yeah, next up, there was this small CI improvement. Essentially, when you create a PR, you can set a skip CI tag on it, a label, and that will cause the majority of the jobs will be skipped. So it's not really displayed here, but it radically reduces the CI time and compute time. Although GitHub actions on open source repos are free from empirical experience, I can tell that there is certain limits. And when you run lots of lots of, when you spend lots of compute time, it will kind of trim you down and hold you back for a while until a refresh period. I'm not sure exactly what the numbers are, but there are some limits, I guess, to prevent people misusing the open source GitHub actions. I was meaning to ask about the skip CI one. Do you think there's any danger in someone submitting something and applying that skip CI tag and it actually is breaking the Android build? Yeah, I think we should then, in that kind of case, we should ask the person to remove it towards the end of the... It's useful maybe when you're drafting PR and you don't want to trigger the CI all the time. But yeah, I think we should then merge PRs where the pipeline didn't run completely. Yeah, okay, cool. Do we have like, is there like a guideline for PRs in the repo? Not for ammo, I suppose. There is a... Yeah, maybe there could be like a rule, you know, you have to pass the CI without any skips before it gets merged in. Right, yeah, that's a good idea. We can perhaps add it here. I guess this is the only text we have about pull requests. No, there's a more detailed guide. No, this is generic. This is just GitHub link. Yeah, we can mention it here or... I guess that would be reasonable. All right, next, there was also a small fix on the VCX from Pomfar. Apparently, some of the method signatures were not synced up with the style we are using elsewhere. I'm not sure if it was actually causing a bug, but it's a consolidation with the rest of the methods we have in this .m files. So thanks to Pomfar for this fix. And next, we have work in progress. So from Bogdan's side, we have currently integration slash testing of the messages grid. How's that coming along? It's painful as hell. Basically, still chasing down regression stuff. Sorry, Bogdan. It's kind of difficult to hear you right now. Okay, hold on a second. Is it any better now? Yeah, I think so. Okay, so I was saying that it's as painful as ever. Basically, still chasing down some regression stuff. Making progress, but it is slow. So I don't know. I'm trying to... It feels like there's just one more thing, but then I fix that and then another thing like underneath starts to fail. But it feels like I'm close. A lot more tests are passing now. Right now, it really feels like there's just one more thing feeling like that. Yeah, but it was to be expected. I mean, I completely and entirely anticipated this, but it's the way it is. Okay, thank you. Yeah, then other items within progress. As a small PR, I pushed today. It's added a new method for credential issuer role on the issuance protocol to be able to get revocation ID of issued credential. It's pretty small. Next up, yeah, there's an ongoing F4 from Stevane around the encoding of credential attributes. So we had quite a bit of exchanges here. And the last point we reached, I guess, was some further requests from Bogdanso. Let's see how this goes. And yeah, there's one more first contributor also we're going on from Andy Wayne around the refactoring of post-message. But there are some tests failing right now, so it still needs some work. Yeah, that's it, I guess. And then the upcoming work, I messed up this a little bit. I guess this is not how I meant to put it in the agenda. So let me just fix it up. This was supposed to be here at the discussion portion like that. Let's save this. Yeah, so yeah, I guess I'm just wondering about the type state refactoring. I know, George, you started a while ago, but it was back then before we even had one of the guidelines implementation guidelines for state machines. Yeah, I need to do exactly what you said and try to sketch it out first and show you guys following those guidelines. All right, so I guess this will be still rework quite a bit to address those updates. Yeah, for sure. And I assume it'll also be changed to use the new messages to stuff as well. Yeah, right. Okay, so I guess let's get well, I mean, the messages are close. So technically, if you would have, I think, Bogdan can correct me here, but I think if you would have a capacity, you can start already, maybe on top of Bogdan's PR, which is mostly done, as I understood. And just, well, and actually before that, we need to just do the draft or the design kind of proof. So yeah, yeah, I don't think Bogdan's new PR should affect this because, you know, the messages to craters is already merged in. Right. So yeah, it's only going to be a name change. So because we're basically going to deprecate the old messages create when the entire integration is done. So then it's just going to be like a small name change, just change messages to messages and everything should still work. Although there are some couple of things that have changed that I discovered during the integration, but they're much minor stuff. I don't think they're gonna inconvenience you in any way. Maybe George, do you think you will have some capacity to work on this? Let's say, you know, till the next meeting or are you busy with, you know? Yeah, yeah, I can try to get it all done. I'll do the sketch first and show you guys that just to make sure. Right. Yeah, I mean, don't take this as some sort of pressure just literally just, if you have the time or no, to kind of have some expectation like how the progress is going to be or when are we going push those other state messages? Yeah, no, I'm hoping there's not too much refactoring that's needed. But you know, I'll let you know if I'm struggling to progress. Okay. Yeah, and I guess that's that's pretty much it. There's a few emitting discussion points. So maybe I'll skip this for like, I'll leave this for the last. I just wanted to touch on the releases. So we were mentioning that the 054 would be with the new messages created, but I was thinking it would be maybe good to do release before that, to do like 054 now. And essentially, I'll refer back to the breaking, semi-breaking change I was doing. That was the, I would by name, right. So in 050, basically in 053 release, those these changes introduced with some sort of migration step. And it was like planned that in the next 054 release, we would drop basically kind of the embedded backwards compatibility support. So in 054, you will have to have your state machines migrated. And so I was thinking we can do this now. We can release 054. We dropped this backwards compatibility support. Why not wait for the messages thing to be done? Because messages on itself are quite a big change. So we could separate those two big changes. Like, you know, to, like this is breaking change and your change is not the messages change is not breaking, but it's big one. So I think it will be like safer for people to upgrade if, you know, those, those changes are more granular. Like you don't have two kind of big things in single release. So, so we could do 050 now. And then as soon as the messages goes out, the integration, then we can do 055 and put it there. That's probably not going to take that much longer though. If, if God is willing, it can be done today. But yeah, I think personally, I think we can hold on a bit longer, maybe until next week. And if the messages integration is not finalized by then, then okay, we can maybe go ahead with this plan. Well, it's not really about like to do it like as soon as possible or something like that, just to separate those changes into two releases to make smaller incremental steps. And if the message is ready today, we can do it in opposite order as well. Like maybe one first release could be the messages, let's say, and then 055, we can drop this compatibility support. So it will be a bit of a tweak plan, but the releases will be more granular or incremental. I don't know. To me, it just seems odd to make releases simply because we would have two big changes. I don't think it's like, it's a lot of them. Like, I don't know, I'm imagining someone, some consumer that 0.54 comes out, they migrate to it, let's say they adapt their code and then 0.55 comes out, maybe they're going to have to adapt their code again, you know, slightly or something like that. If I were a consumer, I would rather have to adapt it only once. But that's just my opinion. Yeah, I don't know. But then you have to like adapt to two things at the same time. Instead of, whereas with two releases, you can do things safer. What's your opinion, George? I'm not too well versed on what's normal in open source to have a strong opinion. But yeah, I don't mind incremental small changes at a time. Would you say it's a lot of effort to make different releases? No, no, it's not. That's why I advocate for making basically as many releases as possible. And we don't even follow the semantech versioning right now. And it's very cheap to make releases. It doesn't consume any time, essentially. Yeah, I guess maybe one argument for having separate releases is if the messages stuff accidentally introduces some new bug, trust that it won't, but hypothetically if it did, then a consumer who just wants this new migration can just use 0.54 and not have to worry about whatever might be introduced by the new messages create. So yeah, they have access to that quick fix rather than this whole new bunch of changes. Yeah. Yeah, I think I like incremental small changes. Well, it's 2v1, so you guys win. Yeah, you know, it's good reasoning. I don't know, I just, as I said, it's a matter of, I guess, personal preference, but democracy. So let's go with the incremental releases then. Okay, we'll see how the timing goes. And I know it doesn't really matter which of these two releases will include message, rather the idea is that it'll be separate. Yeah, Bogdan, it shouldn't affect you, right? If a 0.54 comes out without the messages. Sorry, George, I missed that. I was just wondering if it would affect Bogdan by releasing 0.54 before messages is implemented. But I think the answer was no, it shouldn't affect the work. So yeah, as long as it's not high cost to make those releases then may as well split them out into two, in my opinion. Okay, thank you guys. I think this point here, this is outdated from the last meeting. But I had like, I put one more point here, some good first issue grooming. I just thought maybe we can brainstorm a little bit and see if we can come up with any kind of good first issues. So basically right now, this one, the 772 and 776 is being worked on. And I was told by someone that they want to pick this one. No, no, no, they want to pick up this one. This one is very tiny, honestly. And this one, let's say it's free, but it's just one. So, I think there was some good first issue candidates in the messages, the new messages creates, perhaps. Is there something that comes to your mind, Bogdan? Somebody could pick up and finish some tests or improve something, something that's necessarily too difficult and doesn't have to be super useful. It's just like a not kind of task to instruct someone to do something to just get into the code base and kind of There were some things, but I'm basically wrote them down as notes to discuss Essentially, it's about how the attributes, like credential attributes are serialized. And mainly the fact that you can get a value and by the RFCs, generally what happens is that if there is no mind type field provided, then the value is a string or something like that. If there is a mind type provided, then the value is a base 64 encoded string and then the mind type tells you what to do with the actual value. Now the way that it's designed right now is that these are two separate like fields in the credential attribute. And it's the same thing for the presentation attributes, but I realized looking at that at some point later on that we could basically have and or just a non-tagged enum where the variants are either like just the value which would basically just be a string or a structure where you have the both the mind type and the base 64 encoded value. And this will basically ensure that you either get the mind type and you do something with it or you just get a string and then you use that as is. Right now the mind type is basically an option and that means you get a match on it, see if you got it and then do something with it. Essentially it ends up pretty much being the same thing, but from a structural point of view it's more more intuitive that you're either going to get this variant of the data and you process it somehow or you get this other variant of the data and then process it differently. Whereas with the mind type if it's there if it's not there being just an option it's a bit more of a cognitive effort and it's more most likely the code will be cleaner based on this change. It's not something big so that could be one thing for instance. Would you mind to write this down as one of the issues? I think it sounds good to me from what you described maybe. I will. I guess the reason I didn't is because it's I didn't yet I wanted to at some point it's just that I wanted to get the integration with. Oh yeah yeah. Once it's done we can definitely write it down. Right right we can just kind of keep it on a good first issue backlog here. I mean we can keep a note here and then perhaps create it next week or something and I was thinking from my review when I was doing the review on your PR I think I had the comments about like setting up some hashes or base 64 and I don't remember the details. Yeah you were talking about some validation of the base 64 data and I'm honestly against that because we're basically like you're just getting some base 64 data. It's the user's responsibility to provide valid base 64 data. If they don't it's not like one was going to get set on fire it's just that they're not going to get the response leaks but if they get any response at all. So I think it was also something like hashing though or like the I don't remember the details. I'll try to look it up. I don't know if you know maybe you like already as you described now like maybe those suggestions I had or ideas maybe they're not a right thing to do in the first place but I'll just leave a note here for like my own review like messages hashes and base 64 and I'll see if I can come up with something and then we can we can discuss. Okay I honestly don't recall anything about hashing. Yeah there's some SHA-256 I think for the for the attachment like that. All right the checksum very not so I think that yeah the listen to the checksum validation but then again I don't know if that's necessarily something that should belong in the messages create with that being just like the message structure that's pretty much it like that sort of validation we might I guess this is a broader topic but there might be the need to have some sort of validation mechanism for messages I don't know right now but then again I'm not sure if that should belong in the messages create per se or how to really go about it but yeah it was the attachment the attachment checksum that's what you were referring to and then there's also the question like what do you do if the the checksum doesn't match you know. Okay we'll see we'll see if I can find something something for reasons. At least in terms of discussion I don't think that's a good first issue so we should at least like it might be once we clear it out and realize how to go about it but yeah that's that's pretty much it so I think we should have an approach first before we even write it down as an issue. Yeah yeah okay I'll just leave it I'm not creating issue yet I'll just leave it here as a note and maybe I'll yeah I'll try to think it's gonna make more sense if you write down attachment checksum the message is hashes is probably gonna confuse yeah okay um I don't know what else what else could be is there any any other kind of where it comes to your another or some other things um so the base 64 thing that that was again regarding the attachment um there are some errors they're mostly serialization or deserialization errors so ultimately they just get represented as strings and just to kind of move a bit faster I let them just be strings there are some errors that are returned to strings and there could be like implemented as actual error types I don't have one in mind right now there are a couple of them like three or four something like that so there could be some errors made out of that proper error types and again I think that's a fairly good first issue oh so what should what should I note um um convert string errors to error types okay and uh the next thing which can be on mind as you are speaking was perhaps uh just a simple task like to add a message messages and message types for some of the other protocols like for example pick up protocol you know or like I don't know kind of whatever like did he exchange protocol or those those things we are missing I guess those should be a symbol for anyone to do because they just kind of can use the right yeah shouldn't be too difficult that'd actually be pretty good they can sort of breathe in the entire crate and how it's organized and how it all works so it's actually a good idea let's see uh I don't know something outside of message uh most of the these are pretty much all in the message crate I'm wondering if we could find some if there's something we can find in areas vc against itself perhaps although there's lots of reconstruction so it's a bit more difficult well I don't have anything right now so maybe I'll look through base and try to see if I can find anything uh seems like you guys also don't so I guess yeah leave it at the only things the only things that come to my mind is issues aren't aren't good first issues they're not fun stuff and yeah probably wouldn't be good first issues so I see okay okay okay so I'll leave it like this um I'll delete this piece and I think uh anyone has done anything else to cover before we close up nothing from my side nothing from me all right guys I'm clicking update um because this page is finalized and um the only thing left is to wish you all guys have a good day and see you again next time thank you cool you guys too thank you cheers