 Hey, Patrick. Morning, Bogdan. Let's give it a minute or two. Ah, hi, George. Hello. Hi. Hey, Joel. Let's give it a minute or two to see if anybody else is gonna connect. I think Dinesh was considering or perhaps we'll see a Rafa here. So let's wait a bit. Where would they get this link though? I don't see it in that wiki page. From Discord or from RSVCX Ripple. And actually it's also on wiki page, but maybe it should be a bit more visible. There's on a top level page, there's a link to the calendar and in a calendar there's a link to the Zoom call. So yeah, maybe we should make it a bit easier when a person looks at the wiki. Hi, Rafa. Hey. Hello. Hey. Hello, everybody. I'm happy to join for the first time. Yeah, it's great to have you. Let's wait just a minute or two more, see if anybody else is gonna join. Though I suspect that for Dinesh, who said he was considering to join, is as far as I know in Canada, so maybe too early for him, I guess at 9 AM UTC, it's the middle of the night, or early, early morning. Perhaps we can kick it off and all right, let's join us later. Yeah. Okay, so, can you see my screen? Yep. So once again, welcome everybody to our next RSVCX commentary call. It's 16th of February, 2023, and this is our anti-trust policy notice we have to go through for hyperledger policy, so you can take a look. I'm not gonna read it out loud. All right, so let's get into our agenda. So yeah, today is, we have a Raphael for the first time. Usually Raphael, when somebody new comes, we ask for a brief introduction, if you wouldn't mind just to briefly tell us like what are you doing with VCX and what company you work for, just something like that. Yes, sure. So my name is Raphael. I'm living in Switzerland and I work for the Swiss federal government. And yeah, we just have started a few months ago, a big project to digitalize the identity here in Switzerland. And for that, we plan to work with RIS technologies and because we, of course, we have an iOS and Android application, we plan to use VCX as framework to use RIS. And yeah, that's how we have started and we just made the first proof of concept I think this month, yeah, or last month. And yeah, I'm really interesting to join you and to see what will be the future, especially the deprecation of the VCX, but also the new Unify topic because what I have read in the past year, in the previous days, it makes total sense and we are really looking forward to that. Awesome, awesome. Thank you so much. And maybe just out of curiosity, if you are able to respond, is there a reason why you went for VCX and instead of going like a native, I guess the value proposition for you is that you can build native application instead of having it wrapped in like, what do you call it, React Native or? Yeah, exactly. Yeah, in fact, we made the first pilot with React Native last year and now we want to go with the native application, yeah. I see, awesome, awesome. All right, thank you so much. So let's get into the agenda. So yeah, before we start, let me just ask if you would like to, anyone add anything, any point additional to the agenda, perhaps I know about you, George, I think you wanted to probably discuss the stuff around the edX course and the UNIFFI that there are private chat. Yeah, yeah, that was something I wanted to talk about, but yeah, I can see you have that in there at the end. That's good. All right, so that would cover probably like also the stuff around the UNIFFI then, right? A somewhat. Yeah, yeah, that'd be good. Okay. Maybe I might not look in here. Oh yeah, there we go. By the way, just a note for anyone again, you can always feel free to add anything to the agenda ahead of the meeting. You just need to log into the hyperledger page and then you can edit, it's a big key. So it's free to edit. Okay, so if there's nothing else, then I guess we have our agenda complete. So let's start with our recent overview of the recent work done. So that will be fairly quick as these things has been discussed before in a greater depth. So we had this huge gigantic F board merge props to Bogdan for pulling this off. It was the new re-implementation of the connection state machine without mediation. And this has been merged after three weeks, roughly just a few days ago, two days ago. So yeah, feel free to try it out and definitely curious any feedbacks. Next up, there was a minor CI updates but this was relevant mostly to Node.js. So there was some minor testing issues probably default version of NPM has changed in CI and that has caused some issues. So the solution was to just downgrade the NPM temporarily and later on we can figure out how to actually do the upgrades to NPM 9.x. Now getting to more exciting stuff that what's going on right now, we have another huge rewrite being done by Bogdan and there's an open pull request for this. So it's still I guess a midway but I'll leave Bogdan space to tell us a bit more about it. Sure, yeah, thanks for the intro Patrick. So essentially. I'll stop sharing so we can perhaps navigate at your will if you want to show something. Sure, I don't have the PR up I think but actually I just might, okay, cool. Let's let me bring this up and show the screen. Just a tip, make sure before you turn on this screen you don't have some sort of private screen. Yeah, don't worry, don't worry. I guess this would be it. Okay, is this visible? Okay, cool. So yeah, just as a short intro of the rationale behind this. Yeah, I mean on one hand there are like a lot of improvements that can be done to how messages are handled and what they expose and how they work and probably one of the biggest aspects of this would be the deserialization like the conditional deserialization the conditional deserialization of messages based on their type because that's basically determines what message you end up with. Then there are some traits that I like to introduce for like various common behavior between messages containing the thread decorator and stuff like that. But one big, I would say an improvement slash feature to this, because this would be sort of a new feature would be the introduction of handling semver in a consistent manner. So right now the messages are pretty much designed for like version one of protocols and like version 1.0 of protocols actually of the ones that we support but there are efforts into creating and some new versions already appeared like there's the issuer protocol 2.0, I believe and I think also proof requests 2.0. So there are advancements being done in these protocols and the semver RFC, there is an RFC describing how this should be handled and we basically don't have anything of that sort, right? So right now there aren't really any other minor versions that we should be concerned about but some could be added and we could be prepared and should be prepared to handle that. Essentially, the overall idea is that if your agent supports, let's say the connection protocol up to 1.3, this major version one and minor version three and there's 1.5 out in the wild and you get the message like that, you should fall back to 1.3 and respond accordingly. So that's the overall idea. And yeah, basically not to interfere with the like the current messages because this is ongoing and there's gonna be a lot of work that needs to be done before this is somewhat finished and could be merged into every CVCX. So there will be some, I created just a new crate for now so that I don't get a lot of compilers by simply refactoring the entire thing directly. Yeah, and that's pretty much it. Maybe if you guys want a short introduction into how this works and maybe the ideas that are exposed here, let me share my screen again. And there are actually a couple of things that are, let's say up for debate and I guess it would be a good idea to bring them up here. Can you see my screen? Yeah. Okay, cool. All right, so right now the messages are pretty much just stops so there's nothing really implemented in them because essentially the most complex and important part and that's actually done. So that's a good thing. The most complex part was basically the deserialization like the conditional deserialization and like resorting to the what I call a concrete message. So I don't know, a basic message or in a connection you have an invitation and request a response, right? These are just dummies right now and that's fine. They will get populated later. But yeah, essentially the idea is to have this message type that helps us with deserialization. And basically, I don't really wanna start with A to A message because there's a bit of debate that I wanna bring up there but essentially let's say you get a message, you have a type field and this is basically used to deserialize that type field into a concrete or like, yeah, the concrete, let's say, I don't know, indication of what message the rest of the JSON contents are linked to, right? So what you're gonna get out of the rest of the fields. So essentially we basically deserialize this and this contains an enum which is pretty much the protocol supported and these are segregated into versions and then like major versions and the minor versions and so on. And then these are basically just structures containing the, like enums containing the, let's say string representation of the actual message kind. So for routing, there's only forward but if we look at connection, there is, there are a couple of message kinds that you can get. These are for version 1.0. So a new version might have different naming or different, I don't know, maybe multiple fields or stuff like that. And this is why we have this segregation at least in terms of types. We'll see that this is not public exposed. So, I mean, it's not here but this will not be user facing API. So someone using the messages create will not care about this. This will be internal and used for purely deserialization and serialization of messages. So the complexity of this is not necessarily something that users will have to consider when using the messages create. Yeah, maybe as a side note, the namings are still pretty bad and I'm aware of it. And also the, like that the create structure is still pretty bad. This is still ongoing. It's actually fairly early in the development. So a lot of things will change in both of these regards. But yeah, so essentially there's this concretization of what a message will end up, like what a type really gets to be. And there are some traits implemented, badly named, but I know, with some constants and stuff like that. And essentially the deserialization happens of the message type happens by deserializing to a string because that's what it is. And then there's a from string implementation for message type. And it does the following thing. It takes the prefix and then splits the, like the remaining or the overall string up to a certain point. And then parses the parts, you know, the family or the protocol, the version and the final message kind. And then parses the major and minor versions, like parts of the version and builds up a message family from that. And then this results in a message type. The prefix is there because we need to support like both the old prefix and the new one. Basically the old behavior or the current behavior of the current message is great. And let's say this new crate that I'm working on is the same. So we accept both of these, but we're only going to send out the did com prefix for types. So yeah, there's a lot of intricacies here and feel free to review the pull request and even ask questions. Or if you see something that could be done better, I'm more than willing to, I'm more than open to suggestions. And yeah, that's for the type. And now getting to, let's say the debate of how this works. So we're going to have basically just an enum of the A to A message. And this would be split on protocols or message families, similar to how the message family part of the message type works. And now these right now, because firstly I'm trying to replicate what the current message is crate does. So there's only like version 1.0 or version 1.1 for out of band. So there are enums or stuff like that here because there's really no need for this and this would be user facing API. And I guess the rationale behind that is we can proactively create these enums and segregate the messages by versions as well. But that would be user facing API and users would have to constantly keep matching on the enum or parsing it to say, okay, this is version 1, version 1.0, whatever, whatever. And maybe the routing protocol will never get another version. Maybe there's always just going to be version 1.0. It's the perfect protocol, it needs no improvement. I don't know. So these kind of changes will be done as they come and as the need arises. So for instance, right now for the, maybe not a connection protocol, but the credential issuance protocol, which is version 1.0 that's being used in the current message is crate. There's version 2.0 out there. So this will get a bit adjusted later on and an enum will be introduced here, segregating the version 1 from version 2 or the major version 1 from major version 2. Yeah, and essentially, we can talk a bit about the deserialization of this and serialization of this. And this is where the, I guess the debate comes from. So generally when you use Serdei to serialize and deserialize something, you take advantage of Serdei derived and derived the serialized and deserialized traits from your types. And that does a lot of things under the hood. And essentially the way it does it is that Serdei built a lot of stuff like a lot of visitors or deserializers and serializers that are somehow like somewhat private, but they're all public because they need to be available in your code, right? But they don't only advise to, again, they don't only advise you to use that directly because it's sort of like private content that they can change. And essentially when you use the macros or the derive attributes, like the code gets recompiled, right? And regenerated. But for our use cases and because these message types are somewhat intricate and they're not like, I don't know, just simple fields, you know, as you would see maybe in one of these, one of these like message versions we kind of need to parse this in a way. And so we're kind of taking advantage of some of things that Serdei has marked as private. And there are a lot of comments of what these do and even my opinion on this, it's quite thoroughly described here and why I think this is okay. Shortly, I think it's okay because we're not dealing with a lot of internal stuff and even the inner workings of these exposed types. This is basically just a bit of a refactored deserialized implementation of what you would get from simply deriving deserialized. But in a general, like in a generic tagged, internally tagged enum you would get, Serdei would create a field struct or a field enum here that represents any of these variants and then create a visitor for that and then basically pass the type to this tagged content visitor, which essentially just as it deserializes your input, it looks for that tag, which in our case is the type and stores that separately and then caches the rest of the contents to be deserialized later into the concrete type. So that's exactly what we're doing here. We just use this internal type of Serdei to basically get the tag and store everything else. We deserialize the tag to our message type and then this is the content deserializer because that's how the tagged content visitor stores the rest, the remaining input tree as a content, as an internal content struct. And then essentially this delayed deserialize is just about not having a 100 line match here because you essentially have to look at the, if our tag is a message type, we have to look at the family, right? And basically see, okay, what protocol this is, what major version, what minor version and what message kind, and then deserialize into that. And this is what we're doing here. This is exactly what this is. It's just that it's segregated from, on level so that you first determine the message family and then when you have the message family determine the major version and so on. In this case, it doesn't go that far because it doesn't need to because we only treat version 1.0 here, but that's what it would be doing. And that's for deserialization. There are some alternatives here. I'm not necessarily gonna discuss them right now. I documented them here and why I think they're worse. If you guys want maybe after I finish talking you can ask me, depending on what time we can discuss more. So that's for deserialization, sorry. And I'm just gonna say that in case of a breaking change this gets moved, it's no longer present here or it's renamed or something like that. It's really easy to fix this. And also we use like concrete versions of surveys. So it's not like our code is not gonna, like suddenly not gonna work tomorrow. Maybe it will not work if we bump the version and something changes and then we can fix it but nothing will just stop working out of the blue. So I guess that's another important aspect. Serialization works in a similar fashion but it uses a different component. It uses this flat map serializer. And this is basically corresponded to when you have a structure and you wanna flatten the internal, like a different structure that is a field in your parent's truck. So essentially because when we serialize we have a concrete message but it doesn't have the type and the type needs to be adjacent to the message, the serialized message. So this is what we do here. The only internal part is this flat map serializer which will basically do precisely this. Let me pull it up here. So it will like based on our message we can determine the message type, like the concrete message, we can determine the message type. It's part of the infrastructure. And then we serialize that as the type field and then we serialize, we generate the serializer here and I'm gonna explain why, but then we serialize the rest of the structure and that's it and you end up with your message. So the reason we have to generate this here through closure is because, I mean there are a couple of reasons altogether but the main one is how the machinery works because you generate the state because this is how you serialize a structure in survey. It basically serializes as a map where the fields are keys and the values are values. So we generate the state here, this is public and then we pass this around and then we end the serialization and we end up with our serialized format. So because we need a mutable reference here, like in these two places to serialize the first entry which is the message type and then we have to pass the mutable reference to the serializer that does the rest of the job. We kind of have to postpone the creation of the serializer here and this is just a new type structure. So it's fine, like it implicitly has a closure created out of it. So we just pass that around. And yeah, that's pretty much it. This is how it works and there are some tests here I've actually even ran them before. So right now the messages themselves like content of the message is not important it's just gibberish, but the important part is this like you get the type which is adjacent and then you deserialize the rest of the message as a concrete message type. And that's the overall idea. Another thing about the like the semantic versioning and the fact that we will support it and accommodate it is that we can also this way sort of determine that compile time through some feature flags because right now everything will just be exposed, right? We're not gonna have any conditional compilation but down the line, we can definitely implement that and let's say you can choose whether you want a certain minor version of a protocol or a certain major version or a certain protocol altogether. And based on that, we can build a compile time map of the protocols and their versions that are supported. So when we use the discover features protocol where a different agent queries us for the protocols and the versions that we support we already have that like compile time determined. And that would be pretty cool because there's no way to go wrong with it. And the entries in the map would also be like conditional and compiled. So that's how we would control it. And yeah, that's I guess the overall idea. There's still a lot of work to be done and there's some boilerplate going around which I might turn into some macros. I'm thinking about taking these and moving them with the protocols themselves which is probably gonna be much easier to track instead of having these larger folders. Yeah, so I might move things around. Certain things definitely deserve some better naming like these resolve traits. But that's the overall idea. And right now the remaining parts is like what I just said right now and also implementing the concrete messages like with the proper fields and so and such. And that's it. Any opinions, comments? Looks really cool. I think I'd need to sit down, read all your comments to properly understand it all. Definitely, yeah, I know. So it does take some time to go through it and maybe to mentally map what's going on. Obviously we don't wanna sit here for three hours while I talk about it. So feel free to go over the PR and your own pace and again, feel free to ask questions either in the PR or even at this point. And also again, if you have an idea or anything like that, feel free to ask and or to propose it. But yeah. Yeah, I appreciate all the documentation you've been doing on your recent PRs. It'll make it much easier to understand. Yeah, I love documentation. So like it's also for you guys, but honestly, I think primarily I do it for myself because in two months from now, I will have no recollection of what I did here. I'm obviously joking, but it will take me a lot of time to figure out what I did and why I did it. So again, the documentation is also for me. But yeah. And we could definitely use more of that, especially I don't know maybe for newcomers or people that are just tuning in or new users of our crates. It's probably gonna make a lot more sense to actually like as you're going through the code and reviewing it and understanding it, some comments here and there will definitely make a difference in terms of how fast you understand what's going on. So yeah. Yeah, definitely. I think we'll have a chance to do that if we're type-stating all the handlers. Yeah, definitely. Maybe just like very minor comment from me about naming. I would suggest to kind of change the naming as we used to use A to A message. I think this was actually created in the times where Aries didn't actually exist at all. So maybe we can rename it to Aries message. I think that would make sense. Yeah, I don't know. Again, I don't think it's... I mean, if you guys wanna debate stuff like that here, we can, but I think it would be best to debate naming and stuff like that in the PR itself. I don't know, I honestly don't know. And I don't really care what this gets named to. I guess Aries message is a better name. So I don't have a comment. It's just a small comment which came to my mind now, so I just... Yeah, another thing is like you were thinking of moving message type under the protocols. I would actually suggest to keep it as it is because it's already like the message type itself, the parsing and the serialization, the stuff around it, like it already has quite a bit of complexity to it. So I think if it's merged together with the protocols, it might be kind of... Yeah, I see what you mean and I would agree. But if I can get this narrowed down to a couple of macro invocations or stuff like that, I think it would be much easier because then you might end up with 10 lines of code in each of these files. And it's probably gonna be a bit more... That's my opinion, but it probably would be a bit more... It would make it a bit more easier to understand that this corresponds to this, right? If they are together. So like the concrete message type corresponds to where... I don't know. The message type, like the variant of the message type corresponds to the actual message implementation with its fields, right? Again, provided that we have this narrowed down to a couple of lines, I don't know. But again, this is also up for debate. If you guys, it would be much easier to work more comprehensive to have it separate. That's also cool. All right, yeah, all right, let's keep this. I don't want to pollute it too much with small details. We still have some time, some stuff on the agenda. So thank you very much for the presentation. It's a good introduction. It's a big... We don't usually review every single pull request on these calls, but since this is kind of a big one and it's like big rewrite essentially, refactors from scratch, if you will. I think it deserves some space here too to actually tell people what is this about? Why are we rewriting this? Yeah, so thank you. And I just noticed we have a new joiner here, Innocent Grades, welcome to the call. You can stay silent if you will or you can introduce yourself if you would like to. So I'll just give you a bit of a time and you can decide. All right, thank you so much. So for being a little bit late, my name is Innocent Grades. I'm based in Zimbabwe. I'm a software developer just getting into blockchain and I came across Irish JavaScript, it was interesting. So when I saw this on the meetup, I was interested to know exactly how you guys are doing it as a community. So I am basically here to learn and maybe later on I'll also contribute to the community. Awesome, awesome. Just to maybe a technical note here, just to make sure you are actually where you're looking to be at. So we, Irish JavaScript framework, if that's what you're looking for or if that's what you're interested in, that's actually a different group and they have their own meetings as well. Yeah, and this particular meeting is a rust implementation of Irish protocols. Whereas although we have actually JavaScript wrappers around, you know, for our project and you can consume us from JavaScript, it's a native Rust implementation. So, but there is a like a JavaScript implementation of Aries as well. So you might take a look at both and if you decide to stick with us, we'll be happy. But just so you know, you have a, just to make sure that you have all of the information. Yeah, yeah, I noticed, yeah, I'm already familiar with JavaScript, with Irish JavaScript, but I had no idea that there was also a Rust native that was going on. So when I saw that this is based on Rust, that's actually excited me to see how it's been done in Rust. Yeah. That's great to hear. So yeah, happy to have you here. Welcome on board. We have these meetings just to give you some information I said in the beginning. We have these meetings every week, 9 a.m. UTC at this time and there's a Vicky page on Hyperledge Foundation. So if there will be, you know, in the future, if you would like to join next meetings and you would like to discuss particular topic, whether it's like a questions you have or I don't know, any issue or discussion point, you can log into this Hyperledge Foundation Vicky, you need to create account and then you can just edit this page, you know, at your will, you can add points here or yeah, it's a Vicky, so it's free to edit. That would be great, thank you so much. Yeah. All right, so let's continue our agenda. So we reviewed the messages create and actually for upcoming work, it's kind of empty. It doesn't mean that we have no work, it just, I guess we are already busy with the current of the messages create and then some of the other stuff is also ongoing, but I don't think we are gonna be taking any sort of new items right now or like maybe not any significant new items right now. So I guess I'll just keep this empty. Lots of stuff is already going on and now coming to the like the discussion before the end of the meeting after our work review. So there's two points here. One is from my initiative, this repo restructuring and that relates to the deprecation of the libvcx components. Oh, I'm not sharing my screen, so let me do that. I thought I did, so I was like pointing on my screen and trying to make sense and I realized you don't see anything. Okay, there we go. Yeah, so these two points and yeah, I would like to just talk a little bit about this. So, as we have mentioned before and we also mentioned on previous meetings on a Discord, like we are going to deprecate the libvcx component of the repository, but it's a bit more nuanced than that because the libvcx itself and the way it's structured, it actually has two main modules in it, so there's apic and there's apivcx. Maybe it'll be easier if I actually open up a diagram which we have somewhere. Let me see, where can I find this? Ah, probably libvcx, yeah. So this will be easier than to understand. So we have this libvcx component which has kind of two parts. One is the core component of it is called apivcx and then on top of that there's another component apic and on apic is built a libvcx Java wrapper and libvcx iOS wrapper. So the deprecation plan is to deprecate this part here. So Java wrapper, iOS wrapper and apic as there are better approaches nowadays how to actually build FF5 wrappers for mobile, for iOS and Java. And that's something we've been discussing on our previous meetings. So again, anyone interested in the particular topic of like how to build better FF5 wrappers? We covered that extensively on our previous meeting on 9th of February. There's a video recordings for every meeting we have. So you can take a look at that. But yeah, in a nutshell this takes a lot of maintenance. It's a very old approach how to do FF5 and we don't have like capacity to further support this especially with the new kind of the plans to like implement new protocols. We are doing lots of internal refactoring now to kind of propagate these improvements and add new features in a future to Java and as wrapper you will take lots of effort and honestly they are getting kind of outdated in terms of dependencies and yeah, just overall approach. So instead what we'll be keeping from the libvcx trade is the apivcx we'll still keep maintaining that. I know Dinesh on this court is building flutter wrapper on top of apivcx. So there should be any worries about that. We also do plan to keep maintaining not just wrapper but yeah, for the mobile approaches, we want this part and have it replaced with the new approach based on uni FFI which is right now in like POC stage. And yeah, and what I was actually also wanted to point out here to make this whole deprecation and what is deprecated and what is not kind of clear I created the issue to actually separate, split out the libvcx trade into two components. So one would be the apic kind of create and the other will be apivcx. That way we could kind of more clearly communicate like, okay, this credit is fully deprecated and this one is still supported. Don't use this one, but you can use the other one. Now it's kind of, it could be kind of confusing like, oh, we are deprecating half of this credit. So I think splitting and splitting it out into would make things clear. Yeah, and that's kind of it. Do you guys, anyone have any comments, ideas, insights on this restructuring and also the deprecation itself? I do have a question. So the current libvcx part, the apivcx part of libvcx is that only gonna be used for the Node.js wrapper in the future? Yes. Well, it will be used for Node.js wrapper and as I mentioned, Dinesh is on this building the wrapper on top of this. I know, okay. Yeah, because I was thinking about integrating that directly into the wrapper, Node.js wrapper but I forgot that there's also the flutter wrapper being quite bad, all right. I have a question. Do you confirm that we will continue to do bug fix of the libvcx at least until we have a stable version one of the Unify library? Yeah, I think we can do like fixes if there's anything to fix. I think we can do that. That wouldn't be much of a effort but probably can expect like new features to be propagated. If there's gonna be new features or new implementations in Aries vcx these won't be propagated to the Java and iOS in all the vcx wrappers. Yes, sure. Makes sense. Thank you. Just on what was said just before the Node.js wrapper did you guys originally try to write it on top of Aries vcx and ran into issues or? No, the Node.js wrapper is also very old component and it was always, well actually originally the way the libvcx looked like there was only one crate. It was Aries vcx and libvcx just altogether intertwined and then we started to kind of cutting in out into components. So then we iterated like this was the final iteration when we actually split it out API vcx layer in API c layer and Node.js wrapper existed for a long time it was just kind of built the way it is. It just, yeah, we started cutting it out. So probably if you are building Node.js wrapper today from scratch, there also will be better approaches probably you could avoid the approach with the use32 handles but it just kind of ingrained there already. So we didn't try to just rewrite it completely from scratch it will be challenging. Okay, so there's no further questions. I think we can move on to the next point and that's we had recently in inquiry from Steven Koran he's a creator or maybe one of the creators of edX course which talks a lot about Aries and like Hype Ledger and he posted a message on the Discord channel that he would like to include or like include Aries vcx implementation that's kind of like some included into the edX courses building to point people like if you would like to I guess take a look at the Rust implementation this is where it can start. So and there's two I guess pieces here. One is that we still have to create some sort of getting started page and so far we agreed that I think we will I'm not sure we'd discuss this on actually call last week but at least on Discord or like per private conversations I had seems like the consensus is consensus is that the main sort of place where which would sort of advertise or promote on this edX course what we would try to show people is the Aries vcx portion of the entire repository. So not to send them to the vcx or elsewhere like just make Aries vcx Rust implementation as a first class citizen and then additionally to that there's lots of people interested in mobile implementation when it comes to Rust but since due to the deprecation of the libvcx it's all the approach it wouldn't make sense to send people a new people to send them towards the libvcx anymore so instead you would kind of point them to the UNI FFI POC implementation or let's say for now it's POC and then yeah even though it's very early stage I believe that if there's people out there who wants to build native they might be open to actually work on this implementation and perhaps have some contributions and help us out with building that. So that's kind of I guess intro thoughts from my side but I'm curious to hear what's your thoughts. So just for my understanding so the goal is for us to have some markdown file or files of a getting started guide and the main focus of it will be Rust consumers so consumers of Aries vcx create and then there's another section for mobile users where we'll point them at the proof of concept the unified proof of concept. Yeah, I think something like that. Okay, cool, cool. If no one has other questions my sort of big question is what that proof of concept should really look like and also when are we trying to have it finished already by? So I think we don't need to have it like finished you know the course as I know the course starts on 23rd of this month. I think we don't need to have the proof of concept like finished even if there's just like a connection even if it is just what it is today just kind of template for some approach how to do the UniFFI I mean you demo the application and it works. Maybe the implementation in the POC is not yet ideal. I can't really judge is not personally familiar with UniFFI never tried it but it works. And so it's something I guess we can iterate on and even though it's like largely incomplete it's a place for I think it's a good starting point for interested parties to have a further contributions or yeah. Yeah, yeah true. I think my main thing with the current sample app that I showed last week is that it's just wrapping connection at the moment and all it really can let you do is create the initial invitation or accept an invitation but I guess a proper sample app to actually walk through the connection protocol you'd have to put in a QR code scanner and have all these things running a mediator running and all this other stuff for a proper sample app that I think would interest external consumers just because the sample app at the moment it might be cool to us because we understand that if you can call dot pairwise info and get back the data it means that it is working but I think more interesting to the consumer is being able to walk through a protocol if you get what I mean. Yeah, I think to get that kind of flow like the main challenge would be to figure out the mediation actually and but yeah so I guess that's the question. At the same time I equally wouldn't want to further promote the mediated connection which is coupled with the V6 agency node as a custom implementation or maybe we can like actually use, maybe we could actually use it for the demo but without actually using the mediated connection implementation which exists in Aries VCX but just kind of, you know, wired up together on the wrapper layer so the wrapper would separately deal with the Aries VCX and would separately call the agency client for VCX agency node. That way the connection Aries VCX wouldn't be used but still we could have like a cool demo which would actually work. Right, so you're talking about having the agency client in the wrapper layer so that you can fetch messages and then, you know, inject them into your next collection and then there will be a demo level implementation then I guess if somebody would like to they could use the VCX agency node for mediation if they don't mind that it doesn't necessarily speak like the pickup protocol to download the messages or if somebody would like to they could use different mediator it would be like, you know, the implementation sideways from Aries VCX. Yeah, cool, cool. Also, another note. I wasn't sure if I made it clear in the past but Unify, I don't believe, generates Java wrappers in Poland. I see, I see. So it generates just the bindings but not like classes or something like that. It like it generates, you know, code that Android consumers can use all the classes and everything but it's in Kotlin so I don't think a Java Android consumer could use those bindings. So it only generates Kotlin and iOS? Yeah, and on iOS it only generates Swift bindings. I'm not sure about Objective-C or I'm not sure about much of iOS development, to be honest. I didn't realize that. Anyway, I think that that's perfectly fine. I mean, now only Kotlin and Swift. Yeah, I'm not sure of the state kind of of mobile development. Is that the case? So Raphael, for you, you say that it's okay to do Swift and Kotlin? Yeah, definitely. I mean, most of the Android and iOS application are currently migrated to Kotlin and Swift. It's compatible, it's retro compatible with everything made in Java and Objective-C and I think that every new mobile project now will be in Kotlin and Swift for sure. I don't, it's not a problem I think. Yeah, that's good to know. So what you're saying is that Objective-C is not used that much anymore? It's used for, I guess, a reason, but everything new is made in Swift now and it's the same for Android. I guess the demo kind of you built on the V6 now, we generate Objective-C as I remember, it's correct. Yes, but we can easily make which for Swift. So that's what I made for my demo. I see, I see. Yeah, Swift can consume Objective-C, is my understanding, and Kotlin can easily consume Java for legacy reasons, but not the other way around is my understanding. I see. And similarly, my company as well, we're strictly Swift and Kotlin, not Objective-C or Java. Yeah, these are great notes and I wasn't really aware of this. So thank you guys for bringing this up and clarifying. I also would like just to share my experience after that. Unfortunately, I have to leave because I just finished the EDX course becoming an Hyperledger developer. So I just finished it last month and it gave me all the keys to start with V6, but I totally agree with you that it will be really cool if we can just add some, yeah, let's say some chapter in the EDX course for Unify. And also what I missed to start working with V6 is really an up-to-date demo application for iOS and Android. So definitely I will support you if you want to do that. Awesome. Thank you. I think we wouldn't do that for libcx anymore, but I can understand that speaking from your experience, starting on libcx, that's probably, I can imagine you easily missed and there are some third-party made demos, but they are fairly old. I guess at this point at least two years old and things has changed since then. But yeah, we should take like maybe, we should try to take like a friendlier approach with Unify the new way and make sure that there's a demo and that kind of stuff to make it easy. Yeah, so I guess I can definitely work on the Android demo and sort of have a demo that can walk through a connection protocol if that's what we're after. Yeah, well, it seems that having at least something working would be like definitely nice. But we can start without that. I guess we can just prepare the sort of getting started page, right? And point out to like two different, you know, one separate getting started for every ccx and one for the Unify, some sort of readme's and then just kind of update them on the fly, right? As we further, as we progress further, we can keep these things updated. Yeah, yeah, good point. Thank you, Rafael. Thanks you for joining us. Rafael already disconnected. Well, anyway. Yeah, anything else to this? All right, so seems like that's it. So thank you, everyone, for joining today. It was a great meeting. We had one of the highest attendance in a while. Yeah, and I'll be happy to see you and Rafael as well in the next next week's call again. Again, Thursday, 9am UTC. We're looking forward. Thank you guys. Have a great rest of the week and nice weekend. You too. Thanks guys. Thank you. Have a good one. Bye bye.