 Hey, Patrick. Hey, good morning, Bogdan. Good morning. Today, George said he's not joining. Yeah, I've seen the message. I guess it's just going to be the two of us. Possibly. Let me just update our gender page. Currently it's missing the disclaimer. All right. So let's get started. Right. Welcome. Welcome, everyone. 2023, May 15. There is VCX community call. Is there antitrust police notice? I'll just follow the script as usual. So there you go. I'll leave a moment to read it for listeners and attendees. So let's get right into it. So a small update on the mentorship program. So there was an update on this court from the program organizers that they prolonged the application period of 15. Nevertheless, we already have more than, I believe more than 60 applications were so received across the two projects we have. It's pretty a lot. Competition is high. And after the application period is official close, we'll start selecting the mentees. That's pretty much it for here. We had good first issues already. I think we did the previous week and there are some open ones. I think one problem we are sort of suffering is people tend to not actually compile the code locally. And then it fell CI. So, I know maybe we just have to tweak the guidelines a little bit and make sure to maybe make it more feasible for people to compile it or know how to run tests or just kind of like make a checklist of submitting PR, please like try following things. Make sure that the code is format and make sure that you have a commit signed off. Those are kind of the most common failures. I mean, after all, it's always up to the contributors part to get things right. But I think we can still try to make it a bit more streamlined for them and make kind of a checklist. Yeah, and there's a bunch of PRs opened. There's been an ongoing conversation here, the contribution from Suman to TXD. Let's see if we can get it closed. And there's other unclosed PRs, which needs attention from the contributors, the one from Swaptor and also the one from Prasang over here. Also, there was some PR closed due to inactivity. So yeah, it's important. It's valuable to drive the PRs to completions. But I understand sometimes it's all right to drop it sometimes. So no hard feelings for those contributors. It's great space for another people to try to contribute. All right. Anything from any other start meeting points from your side? Not really, no. Maybe just what you said about the contributions and the PRs failing. Yeah, I guess we can make some guidelines to follow. But I also think it's kind of a common sense, at least in compile languages like this. Just give it a run. I don't know. I'm really lacking the words. But some checklist, especially regarding tests, those are indeed a bit more convoluted or maybe non-intuitive in terms of how to run them. So definitely that could help. But in terms of just getting the crates to compile, I think that's some minimal effort. Just please do. But yeah, that's pretty much it. Yeah. All right, let's go ahead. So overview of the stuff done in the last weeks, a whole bunch of stuff actually. So let's start here. There was a kind of a change or slash fix for the verifier behavior where previously the verifier would send, correct me if I'm wrong, it would send acknowledgement message if the verification was successful, but it would then say send any message if the presentation was deemed as invalid proof, invalid presentation for whatever cryptographic reason. Yeah, so we would be generating the problem report there, but it wouldn't be sent. And that kind of also sort of defeats the purpose in a way. So yeah, essentially we're going to be sending the problem report now on failure. Yeah, so either way, there always will be either egg or a problem report. And actually before, even if it failed, an act would be sent nonetheless. So if it failed, we would be generating the problem reports somewhere would be sending an act regardless of what happened, which would be quite confusing. So I guess it makes more sense with the way it is now. Yeah, yeah, and tying into this change those another change that one is the one still still in progress but all kind of jump jump a section ahead here. Since it's related. We also where was it. It was a modification to this problem report slash acknowledgments, which is still open kind of pending for further verification and testing. But maybe I'll leave a short, you know, a mic for you to briefly conclude what this is about. Yeah, so it's not, I guess that much talk about but essentially areas has this concept of borrowing messages from different protocols, which I'm not even sure it's something of a universal thing but essentially the act message and the problem report messages are kind of defined in their own specifications. And they're kind of generic messages so they are defined there in terms of structure and stuff like that but more often than not they would in fact be sent as part of different protocols. Yeah, and that's pretty much the idea now here we basically just propagated problem reported the notification message family, which only had the act message is where the act message is defined. And that's, again, as per the RFC so it's completely fine but there is actually panel plans sometime in the future, normally know when but to kind of propagate the problem report to other protocols like credential issue credential and present proof present protocols again as per the RFCs. The act message is already borrowed there, and if we are to use the areas terms, and the problem report would also have to be for the pretty much the same reason like if there's an error you would be sending a problem report. But I guess it's more kind of intuitive or convenient or self explanatory when the message is part of the same message family or the same protocol. And that's pretty much the idea. Thank you for for summarizing this work is to a related so kind of merge group them together. Now let's continue the overview. So another big piece, which was done was we've merged the DID slash DDO resolver. Huge, huge undertaking huge effort from mergue and also reviewers was probably the most discussed become the most heavily reviewed PR in terms of number of comments almost 200. So yeah this adds a bunch of crates to the repo. So we were discussing that this could actually be taken out out of areas DCX under perhaps a separate a new hyper ledger repo. Some sort of I'm not sure how to name it yet but some sort of DID resolver perhaps the ID utils I don't know. And it's pretty universal it's not related to various essentially at all. And we are going to simply consume this from areas VCX. But I believe there might be other projects which find is useful and probably will be cleaner if it's less confusing if it's outside of various VCX, perhaps it can also help with adoption too. So props to props to mergue. I just need to get this integrated now into areas VCX. But I believe that shouldn't be too big of effort at this point. Linking to the DID resolver we also have implemented this is wrong link apparently. We also have implemented the DID that method. So that's pretty much says says says it all. There's a link to the spec. It's possible now and I'll bet now essentially we have to the ID methods support the ID solve and the ID web and I believe the next one we will be adding will be the ID in the, which should be supported by in the ledger. In an upcoming future, I don't know exactly the timelines for the ledger, but I believe should be this here. Next up, we had good for this issue merged again from swap to our recent contributor. So yeah thanks for driving this to the completion as we have this merged. And lastly, we have some CI refactoring related to iOS. And this has been approved from from like our side but we need to get it tested and we asked the guys from Switzerland, who are using iOS and the VCX in general, including ours to give it a run so we'll see how they come up with and if it's all good then we can go ahead and merge this. All right, now to stuff which is in progress right now. So I'll start with smaller stuff so we have a good for this issue ongoing here, as I mentioned before from Suman TXD and this is ongoing conversation here. So, yeah, happy to see happy to see active conversations. Let's hope that Suman TXD can, can finish the work needed to get the merged. Next up, we have this stuff we've been talking last week about. I think we can leave this point as the last because that might be the richest discussion. And we also have a new PR again, a new feature sort of implementation of the ledger interface using IndividuR proxy. So for those who are not aware, IndividuR proxy is a web service which enables accessing in the ledger through an HTTP API. So technically now you could use, especially in server environment, you don't always have access to maybe internet over zero in queue due to like security limitations, some security compliance limitations, restrictions. And so you could instead just kind of call the HTTP proxy. And then you would use this, you would opt into the IndividuR proxy implementation of the ledger trade so it will be transparent for the rest of the RSV6 code base but you'll be actually calling the ledger through an HTTP server. So this, this is pretty cool stuff. So pending reviews, I reviewed myself but we'll come surely confident that Mirgi will appreciate further reviews. So next up we had the problem report that's already covered before and then the holder implementation state pattern. I believe that George mentioned he was kind of sick so there was a much, much new updates here. I also am not sure but I think that George is actually working on like a separate branch and this is kind of old version here. So this is just kind of on hold right now or on hold slash progressing little by little. And so getting back to one point I skipped here. Okay, that was the trade, not this one, the concrete ledger trade draft, which we discussed last week quite a bit, but we didn't yet concluded how to go about it. We discussed the associated types last week and since we are just two of us today, maybe we can discuss it further and maybe look into some implementation details, just kind of zoom in and try to publicly on this call try to find a solution or conclusion how to go about it so we can get started. Right, so I think there is a like in the agenda there is a point about splitting trades so it's kind of related. We're probably going to drop the trade prefix from the crate name. Yeah, I don't know how to name it just just just without the trade I guess it's fine that that should make sense. Yeah, so like this this is one aspect of these core trades so as VCX or pretty much just contains all these trades, but the naming is kind of weird and nevertheless, like to summarize our discussion, probably the starting point was about the ledger and Murgy running into issues about related to the fact that there is just one ledger trade that combines both read and write operations. And that makes things kind of difficult sometimes because a lot of in a lot of situations you only just need read access with which is obviously more permissive and requires less stuff. And because of that, like this would be one reason to split the ledger trade into something like ledger read and ledger write. They don't necessarily have to be in separate crates really I think just one is enough. But regardless so that's one thing then there is the add on creds trade, which similarly, like contains all these operations for all these, you know, actors roles roles I guess would be a good word. Which, once again doesn't really make sense like you might not even be interested in using one of the protocols or you might only be interested in being a prover and not a verifier so why would you be bothered with implementing verifier operations, which again, technically always just do is like return some error or stuff but I guess it's more explicit and self explanatory if these things are separated and this was actually your idea. So there's this this aspect of splitting stuff based on their domain so that implementing them would be easier for for consumers and for us as well. Then, I guess there is the idea of, okay, we are going to split them, but how exactly should we go like it's not only about splitting them but right now the traits and the way they are defined. So I kind of locked in a bit in the based on the in the implementation or the in the specification. Although like there's an implementation for the in the ecosystem for each of those of these traits but I guess like the that was the the main driver for implementing them and that was the main that was the main reference so they were kind of designed around the idea of indeed but also the point that we kind of want to make them ledger agnostic or ecosystem agnostic so that the operations could be virtually implemented for any any type of ledger or ecosystem that is that exists right now where will exist later on, and this is a bit tricky because the specifications are not really well defined at least for for an on credits but I guess this is where the point of associated types comes from so, for instance, there are these types where data structures like schema and credential definition and stuff like that where there's not really there should be but currently there's not really a common specification for them. And last week, I believe we pretty much discussed about whether to use something is to use associated types so that each implementation could define its own types. So, for instance, for Andy, you would have an in the schema or in the credential definition, which are actually already defined I believe in some of the in the crates. And you could use that. And then if you want to use some some other implementation or ecosystem. For instance, the work that George has been on to regarding the the newer VDR tools, I guess, like the split crates so they're still in the but they're a bit different. And while some things might be common and then they can still be implemented as common. Some other things will be different. Yeah, and so the two options that we discussed were either to define our own types for schema credential definition revocation registry and whatnot, and kind of, you know, like brute force them into all the approaches and hope everything will work. More that I don't just cut corners to make it work. But it might be possible George says that if he does it. I don't know, honestly, like the entire scope of age, AFJ and what they like whether they are really that ecosystem agnostic or they're also kind of more targeting indie, a bit more. But regardless, so there is that option of creating our own types, which might work but I'm unsure of. And so as not to risk it and just work, I don't know maybe for for some time couple of weeks just to realize that we got the point we're cutting that we're cutting too many corners, I would just go with the associated types way of doing it. So then, if in the future, we realize that or even just the specification kind of stabilizes, and we realize, hey, you know what we can use the exact same type and all of these trade implementations. Then, like in the very beginning to kind of accommodate that you just have to set the associated types to the exact same type and then everything will just be fine. And then you can remove them as well like removing them will be would be much easier rather than adding them later on. So that's kind of my my argument about it. Then there also one other point that I discussed with murky last week, and that's the fact that, for instance, for the ledger, and the fact that these the trade right now is kind of kind of taking kind of taking in the as a reference and the in the specification as a reference. The trade would have to be kind of heavily modified to basically in the trades so we're going to split them to read and write but we would have to modify them to kind of accommodate pretty much all possible implementations. And I guess the main, maybe the main point of this would be the revocation registry methods, like working with the revocation registry so living the type for the revocation registry aside, it's going to be common or an associated type, but each ecosystem can kind of implement their own way of working with that. And for instance, in Indy there is they use deltas, I believe you correct me if I'm wrong, but I think that's the case. But that's not necessarily a standard, like they can have they can work in pretty much anyway. So the way to accommodate that again, I believe would be to have an associated type for something like, I don't know, revocation registry options or something like that. So then when you implement the, let's say the ledger read trade for for Indy, you would pass or you would set an associated type for the revocation registry options, specific to Indy with the delta so you would have a to a to field and a from field these dates that you would use to generate the delta or create a delta. But for other ledgers you would have you could define a different type, and you could have whatever options are needed to accommodate the operations there. But correct me if I'm wrong as well, but I guess these are actually kind of two different issues. I mean, you could technically have like, let's say they are right. You have common types and just use the associated types for this kind of stuff. Like I don't even have any other better way to handle this. I can think of a better way to handle this, like the this options kind of approach. Because if you define, like right now there's, I believe there are some delta methods in the in the ledger trade, which are really, really don't belong there, right, because it's not for. Yeah, it's not. Yeah, it's not universal. They're not universal. On the other hand, you kind of need them to be in the trade because regardless of the interface, or just maybe not another delta methods but the revocation registry methods they need to be in the trade. So that, because it's a common operation that you would be using on any in any ecosystem so they need to be there but they need to be configurable like that to kind of act differently or behave differently based on. Based on your implementation so the associated type is the way to go I think. And yeah, about the schema and credential definition and like the types themselves, I'd still go with associated types. But yeah. Yeah, let's maybe just do like a quick, I think I'm pretty on board with the associated types for the options, but maybe let's just give a bit of a review for like, I think the important question to answer is like, if we were to, like, if we were to, you know, use the shared types which I think would be like preferable if possible because then you, then you like stream all the interfaces to like single type and you don't have to like have like different versions of like let's say very far which works like with different. But there wouldn't be hold on it wouldn't be a different version of a verifier, like the, the trade implementation would be like you just implement a ledger and then when you work with like you wouldn't work with an indie ledger as a, as an implementation you would work with a type that implements the ledger read. So you can use generics or if you want trade objects. Like that's, that's the entire point of it you don't care, like there's, I've thought about this a lot and I see absolutely no downside of using associated types, they're going to be just as generic or easy to use, but leaving like we just added flexibility to a verifier or a prover will not care what implementation they get, they just care that they get a type that implements ledger read or ledger write or something like that. And that's that's the point and then the trade or the implementation in like let's say the indie ledger read would internally work with the associated types. That's pretty much it. So when you're for example implement like, when you're building instant, let's see. Can we can can we revisit the kind of the demo you do you have the demo from the last week can we kind of look at it again. I don't know if it's there anymore. Let me see, because I accidentally committed it. Oh, actually, I think there should be because I committed it so it should be in the last commit. Let me see. I think you can actually just look it up if you go into PR and going to PR. Right, right, right here. And just look at the, at the commits. Maybe maybe commits actually. Is it there hold on. Yeah, so just open up the previous commit. I guess. This one. Yeah, yeah, that should be it. So I think they're here. Yeah, there is something there at the top. Right, yeah, yeah, this seems somewhat familiar. Right, so yeah, we have, let me try to kind of rehearse this. So yeah, we would have like ledger read let's say, and they'll be for individual ledger with their tools ledger maybe we'll have eventually, like a header ledger let's say they would have its own. They would assign some sort of header on on credit schema. As a associated type for schema. And then then we have an on credits very fire. And when you are right. Yeah, like, that's the thing like you need to have like in the end on credits very fire and then you would also need to have different trade say you would still have an in the end on credits verifier, even if the types were common because the operations like the method implementations would most likely be different. So I don't think you get away with just implementing one and on credits verifier because then it wouldn't be a trade it would be just a type with some methods. So it's still need different types for each implementation. Right, yeah, yeah, yeah, different type for each implementation. So, like, this is not about like you don't want to use your in wherever these are getting used. You don't use. I don't know if you use if they are used right now, but I hope not. But we're never like essentially going to be using in the end on credit verifier directly, we will ask for an interface which is the trade so we're going to ask for a type T that implements and on credit verifier and whatever that's going to be. That's cool. So then the caller or the consumer will say, yeah, I'm working in the in the ecosystem or header ecosystem so I'm just I'm going to implement these types and here we go. But the associated types are pretty much contained within the trade just getting used there or getting used and even up and work down technically in the stack. Yeah, but you will have like, say, let me let me copy paste this into here. Random location. Right, but so then you'd have this you'd have in the in the other credits very fire. Yeah, there will be some sort of particular implementation implementing the unencredged interface somewhere. Right, so we have this trade somewhere which declares those associated types. Right. And on crits very fire is on crits. So for example verify proof right let's take this one as example. You might want to look at the implementation in the PR though, because you will need strong typing here. I mean, not need necessarily but that was also one aspect of this life. We're taking strings everywhere which we don't really want to do. Yeah, exactly. So there's that. So then you would have like this kind of schema right the different define it on the trade. Right. You'll use it for, but say here. Yeah. Yeah, you have to say so self column column schema. Yeah, right. And then that's the that's the intro to trade with the associated types declaration then you have the actual implementations for the trade where you would and we are assuming here that we have clients which return kind of schema which looks maybe different fields or whatever it's differently structured. So, to read. This is on crits. Or it will be let's say, here we okay, right. This very fire I'll do it like this. You know, right, so that's, that's the very fire, very fire needs to have a variable schema type, and the web implementations for this. No, yeah, in pole, and then we have like, let's say, it'll be like in the friends very far. Yeah, but the other way around the implemented trade for a type. Oh yeah. Okay, schema. All right, and then we would say, for example, yeah, something like this in the video schema and this could be. Oh yeah and we were saying actually. And this would be some sort of in the time, then we could have, say, had era. The other side. Yeah. Yeah, well and see and this is like, Yeah, it would probably have like had their schema there in the implementation. What I'm thinking is, you know, like, and what would we would this be actually two different implementations, you know, that that's what bothers me I guess about it. I don't know. There's differences on ledger and you have to resolve those like schema, but the actual like verification code. You know, I think that should be this shouldn't actually be like two different implementations. So you're simply verifying on crates like proof. You know, I don't see what the actual difference would be like you already resolved. Why is this a trade. Like if it would be a common implementation for all like virtually any ecosystem then why not just have a type. Yeah, it's the reason why it's straight is because it is shielding away the actual implementation and the main reason is that we, you know, we're migrating from video tools to the modular the credits library. So then we can swap out the implementations but technically like as for as for the other ledgers and like credentials based on other ledgers the only different really should be the way you resolve these kind of primitives from the ledger. But then from then on you have these like, I mean I know it's maybe not perfectly fleshed out yet, because it's like, there's some to dos here. But definitely like long term idea is to have the standard so so the there should be any differences like you just the deviation the difference is between how to get this resolve this data from the ledger but then after you have that finish this I owe the verification on credits, you know that's described here how to verify on credits proof this crypto, this is what's implemented by VDR tools. So the VDR tool should be able to verify, like, had a hash graph based, you know, anchored presentation, for example. Okay, we now kind of now when I see it this way like, oh, you know, that we see that we would have two unknown credits verifiers. But hey, that actually. Right, so that's the case. But if that's the case, like, even the tools implementation so there's VDR tools and credits are shouldn't. Can we just be able to verify what VDR tools is able to verify. Like, I don't have two implementations for just these two. Yeah, they're doing the same thing. Right. 90%. It's just a VDR tools is old and everybody counts. Right. So then, again, why even have like, I'm fine with this, you know this. The system itself way better than me but then if you if you're saying and it makes sense so the ledger stuff is agnostic but then and on credits would be kind of different then why. No, that's more of the wrong, like the ledger stuff is a little bit different maybe across the ledger but then the unknown crest verification code and stuff like that. Okay, so then why not just make this some actual types and not a trade and it wouldn't be an interface it would just be like something the type and on credits verify. The reason is because we, you know, because we are trying to get rid of the VDR tools but it just can't it's difficult to do it in like one go. But I'm still trying to if they do the same thing. Why can't we have one uniform implementation. Like why not. Let's say I could do it in the scope of this PR I could look at credits implemented here and just say, we're going to be verifying all add on credits through credits and that should be fine it should be backwards compatible right. Yeah, yeah. So let's just do that then. Like, yeah, that's like the kind of the ideal, like just get rid of the VR tools. I know you are taking careful approach about that because I think it's like kind of a big piece of like it's a lot of work and so it being done for holder and so let me that's not what I mean. If you're doing this diagram for me. I hope it's for everyone watching. Okay. Yeah, go on. I'll just kind of maybe draw on a bit. Okay, yeah. So, I understand that we have like the old VDR tools and the new credits stuff. And my. So, from what I understand. Okay, we can have interfaces in the form of traits for ledger, like ledger read ledger right and for wallet again maybe those are different. I don't know. They could be different so. But for add on credits like right now it's a trait which is why I'm bringing it up as a trait but from our discussion right now I understand that okay but this stuff is supposed to be universal like there should be just one and on credits verifier that can verify and on credits from any ecosystem, provided maybe a generic with a ledger or something like that doesn't matter but so if that's the case right now we have it as a trait and there's one implementation for VDR tools the old Indie libraries and credits the new Indie libraries. Why implement why have these two implementations why not simply modify the Indie implementation to use credits directly like why have something new. So it's a it's a yeah I mean like are they compatible do they do if they do the same thing and they're compatible then why keep both one. That's the final desired state and just a matter of like it just kind of. I get it is the final. You know. Yeah. I understand it's a final like that's where we want to get to, but why not do that directly. So as I saying it's kind of matter of approach we took maybe you know even like before you started with us. We was it wasn't so long time ago was like basically George started this work he George introduces these interfaces to kind of enable you know, like, what if move from VDR tools to credits otherwise like you have to like, like, modify lots of code here and there and I mean they're mostly similar but there are, there might be why. Okay, differences is, especially maybe on like issue or site. Because we just don't quite know you know how different they are the in the after all they doing doing kind of the same thing but those interfaces are somewhat different. It's not exactly like maybe one. It's not exactly one to one mirror. Basically, when when these, you know, those module libraries were intercepted the way was created. They took in the VDR tools or in the SDK back then, and they split it out into small libraries but also did a whole bunch of I guess refactoring and tweaked a little bit. Um, so I don't know we were not confident ever to just do it in one go. So that's why we hit them behind interfaces. I see. Alright, so what do you think now like cannon. I mean, I can also look into it a bit. But at the top of your head, do you think it can be done like that directly or because it's all about this like the be the whole argument against associated types right now for this trade is, but we should have just have one implementation, but then you're saying, I mean, we want to have just one implementation, but we cannot have just one implementation right now. So we could still like as a as an iterative approach have the trade with associated types, implement both credits and VDR tools, variants, and later on when VDR tools is dropped, just transform the credits implementation into just the singular type and not a trade interface. Um, yeah, I think that also in the in the case that, you know, when when the specification is stabilized and we know that okay, we can have just a singular type it can do everything we need, like regardless of ecosystem or library or whatever. Yeah, maybe we can have a look at this credits, like to see how the code in the credits. How they find this. Yeah, I mean, yeah, I assume assuming that like this library that the credits library it can like verify like an increase, you know, an increase. Yeah, but you see my point like there are a lot we're making a lot of assumptions right now. And when I'm where I'm trying to get at is these assumptions might turn out through, which is perfectly fine like if we go this way. It's not hard to like even if we have this straight implementation with associated types it's not hard to transform like okay let's drop the other implementations let's just have one add on credit verifier, and it's going to be just a singular type one structure and no longer trade, and we're just going to be passing that around. That's easy to refactor. But if the assumptions don't turn out true. And there would in fact be differences, or maybe the add on credits will get stabilized in like after two years from now, we can still work kind of like pretty much seamlessly. Yeah, but we don't want to support like other ledgers right now and I don't think it's strong assumption to say that I don't credit is a standard and if like head around, you know, if somebody in on the head around graph wants to like use and I'm going to head here to to this to this on on credits RFC. Which originates from Indy. And there's a library which is like implementing this essentially is an on credits. A library library. You know I don't think there will be more like libraries. Fair enough. Right. But it's not even just about libraries but leaving that aside so let's say okay credit skin satisfy all ecosystems. We still have the VDR problem, like the VDR tools problem. And again, like if, if these two are not fully compatible or if critics is not fully backwards compatible so say with VDR tools. And there are implementation differences and I know maybe they require some different arguments or some stuff like that. Then you cannot just have a singular type at least not right now. Well, it's in use. When it won't be used anymore and we can drop VDR tools, then we can transform the implementation into a singular type. Like I was saying. No, but I mean that like Like right now I'm brainstorming I'm not saying we should do this like ideally from what I could gather what I would do would be to look at the credits implementation and VDR tools implementation and see whether we can just start using credits from now on and gradually drop VDR tools. So that's that would be the ideal scenario and just have singular structure types for animal credits verifier holder issuer prover whatever. But I don't know if it can be done right now so. Yeah, right. Like kind of summarize what I'm saying is, if we review this, there are basically two outcomes either credits is like and fully supported and it's fully backwards compatible with VDR tools in which case. I think, or I would say we can implement singular types using the credits libraries drop VDR tools. Or if they're not backwards compatible and we cannot just have a singular implementation, have the trade, have whatever associated types are needed and just like maybe for this case there aren't even there, they aren't even needed. I think there might be a ledger needed but that can also just be like based on a generic that implements the ledger retrait or something like that. But if they're not compatible then have the interface and have two separate limitations for now. And then when we fully decide we want to draw VDR tools. Drop it and just combine the trade with the credits implementation into that singular type that we want to achieve nonetheless. And, and I mean I generally agree. I just want to point out like I would maybe mainly mainly try to focus on like just yeah just getting rid of VDR tools, and maybe not, maybe not concern like even though we mentioned it through our discussion I've been mentioning it through discussion, you know kind of maybe step further like thinking in terms of unknown creds and different ledgers. That's something we need to keep in mind but like the main goal really, and actually the reason why those interfaces were kind of created in the first place where to enable like, yeah, like iterative migration away from the VDR tools which is essentially abandoned library now to the smaller ones which there's much more traction because ACAPI is using it, ACAPI is using it, and there's more people around it getting better support. That's like the utmost like priority, you know, other than the Rift state machine stuff we do is to get away from the VDR tools. Okay, so then. And maybe just. Depending on the differences but just one more note like basically you know we are like 75% there, because the only thing we are really missing now is the issuer. So, so the prover and holder, that's George has already you know implemented those. So you can use like on mobile. Implemented to. Yeah, actually even I believe even very far. Yeah. Okay, because the one was really simple. I think it was just like one function, but the issuer is just like bit more like there's more work and issuer, and that's, that's ending to be done and explore. And it's kind of important for us to maybe test that if you were previously VDR tools, but issuer that you can kind of keep on using the, you know, if you switch to the new implementation with the credits issuer. We still, you know, just keep on going and for example revoke the credential we just previously issued with VDR tools. I believe it's possible but it's important to make sure of that. Right. Okay, so I can, I can work on that. And based on discussion then I would just try to like it would require us a bit of research but if by all means possible I would just have singular types for all these implementations and just not have interfaces anymore. Right. I see, I see, wait. So how would that work, you would have, can you elaborate on that you would have singular types so you would. Yes, instead of having an add on credits verifier trait and you implemented once for in the ones for head there are ones for whatever you just have. Yeah, but to get there, but to get there I find those, I find those traits useful because you know it enables us to be 75% there but you're killing me Patrick. So, okay. Like, should we do it the traits way. And if so how should we go about it, or should we do it the singular type kind of way. Like, like in my opinion, like the whole the whole point of this we started from you were looking at the, at the traits and saying but why are there two implementations. The, we decided that kind of the goal is to have, you know, just one implementation, just one add on credits verifier. Why would we still have the traits then. Yeah, like, once we fully migrate and we find out that it's okay and we can, you know, switch from video tools to the credits then I agreed and we can. We can technically dump those interfaces. This is useful for the migration from video tools to those smaller libraries. So then we go with the other options that I mentioned that we make that we keep the traits and have two implementations, one for video tools one for credits. Once everything is said and done and we can drop video tools then we combine the trait with the credits implementation into just one type where basically the credits implementation will absorb the trait if you want. Just not have an interface anymore just one type. I know like because that's what you're saying from. If you're going to, you know, look at this. I mean, it might be the way like and I won't like, you know, get in your way if you find if you find it to be like better way, you know, implementation lines. Useful to associate the types here. Why not maybe I'm just well the types honestly are not even about the Anon credits part I think they're more about like they would be they're actually needed in the ledger traits. More than they are needed here I think they're needed here too but you kind of have to pass a ledger nonetheless so yeah you regardless have to make use like you can use them indirectly like that. But yeah so for ledgers we definitely need to trade an interface with different implementations and yeah again the point is because if you look at the draft the PR we're a bit over time can you stay a bit longer maybe we can wrap this up and yeah yeah I think it's good discussion. Okay cool yeah yeah it is so sorry this is not it. The draft right here. Yeah and again look at that previous commit where there was more of it. So, you'll see that basically the ledger traits are the ones that actually implement these things and these these associated types like you I think you might have to scroll down a bit. Or is this just that this is the Anon credits file okay maybe you can look at the ledger file. There's nothing else here but in that comment but I can. Fair enough just look at the latest one yeah. I'll take a look at that. Yeah so just look at the ledger.rs. So this is where they are actually defined because again like they might be common but they might be not they might not be. And I don't really know right now and the safest option in my opinion is to go with the associated types if they turn out to be common. It's easy to remove those but if they're not then it's going to be a bit more difficult to add them later. All right yeah okay then we can we can. I think we can do the associated types here but then I guess for now we would just have like in this stuff and then then then the Anon cred interface. I don't know exactly what this does so I haven't taken such a close look at the methods but it's likely that the. The Anon creds implementations like we might not even need an associated type there. We can just take a generic for ledger read like a type and then implementing ledger read and take the generic in the function rather than bind it to the trade to the interface. So then it will be general enough like you can use you can use the same implementation with whatever ledger you want. And I guess that would be that would be the way to go so I guess that's what you were more concerned about then it makes sense so. Yeah like I was mostly like concerning with the fact that Anon creds for or shouldn't just even know about the ledger exists like maybe the credential scheme I was taken from a text file or or a printed text or whatever. Should be the existence of ledger, basically, or Anon cred stuff all of it. Okay, taken from some ledger or some from the base doesn't matter from it should be the same thing for Anon cred standards although just drafting or fleshing out the. Okay, but. Then that means we do need common types, like just one schema type and one something one credential definition type, because if like if this is supposed to be a singular type. And this accepts a schema and a credential definition and stuff like that then. Like. Yeah, I mean, yeah, it should be it. I think I know I know I know it should be. Like that that's the goal but. It's like even you look at the indies can, for example, or this is schema and when you know when you. This won't be like, somehow, and the in increments are on crates RS this stuff here. This is all, you know, originates from injured the stuff you see here this is the way it's done on Indie. And this is the standard forming the other implementations like head around or I don't know who's doing it head around or like. Cardano, I think, and I don't know who else. They are they are they're following this, you know, and when we look how it looks on like credential definition schema is like way too simple claim definition. Then it has like, basically, this this piece. No, no, no, it's kind of simplified version of the transaction. This is some ledger stuff is nothing, nothing. This is the actual transaction data. And this is the actual, oh, this is some metadata. This is also metadata. This is the, you know, I don't create stuff. And so this is the standard right piece. This is what the other other ledgers or implementation also have to do. If you take a look at this like primary I'm surely gonna get it's here. I looked at something like we did look at, I think the schema and there was something that Indie was adding on top of this. There was one field but I don't remember which one. Yeah, it's it's I think it just a matter of, we can open up that on credits project. There are shared RS repo and that has few things in the critics. Maybe I'll just check it out. I think I already have it but I'm not sure where. Okay, it's already there. It's the moment. There we go. Indie critics and Indie critics depends on the Indie database Indie data types, I believe. Yeah, I think this is where they're defined. Yeah, Indie data types here. And that specifies as an unconcrete types kind of. Ledger primitives kind of right. Yeah, and this is number. Let's say, let's say credential definition, for example. So it has ID schema signature type schema ID. Let's see in this kind. This is credentialed the claim definition is credential definition. schema ID. It's not here. Signature type. That's a schema ID. Okay, that's not part of the transaction that would be essentially like the this, this. Okay. There will be basically this one, maybe. What about the sequence number in the schema? Yeah, there's not a sequence number here, apparently. No, this is the credential definition, the schema. Yeah, schema, right. Yeah, second option here though. Interesting. To read names. Let's go to schemas. Because essentially, like, if anum creds is kind of was drive driven by by Indie, then if we're to use some common types, why would we even define our own when we can just use these ones? Yeah, yeah, yeah. Well, yeah, yeah, pretty much. Because if it's aim, it's supposed to be a common standard, then this, this is it, right. That's the definition. I don't know. That's, I find confusing when there's sequence number here. Can you see how it's used? Can you do like search references or something? Like there's like some mapping to string. Create credential definitions. So when you're creating credential definition, for example, in the node requires the published schema ID field is hema sequence number. So I guess when you're creating credential definition in Indie ledger is a, yeah, is an issuer. Then we need. Right. And this is what I was getting at you see so this. This doesn't sound like anum cred stuff. This sounds like Indie specific stuff. Yeah, but, but keep in mind that this is like creating credential definitions. So this is actually happening outside of those unknown credits, you know, issuer and verification protocols, those areas protocols like you would have to do this. As an issuer, you know, prior to any credential, you have to write and that's not that might not be standardized, you know, how to write financial definition on this ledger or dead ledger that probably I don't think that will be standardized, but would definitely shoot and will be trying to be standardized is the like the, you know, resolving part. I want to resolve schema. I want to resolve credential definition from this ledger that ledger. And let's see the other usage I see seem like the second number is only for this is great current. Yeah, it's the same thing. It seems like it's only for creating the credential definition, which is in the Indie does it in its own lane. Okay. But then back then I guess I really case with the others like this should be more like shared like this, the revocation registry that just like pure crypto there's not much stuff here. It all boils down to some Ursa accumulator, some points on a curves elliptic curves. Right. I think should be returning this type like working with these types and yeah in those trade interfaces as you said. Yeah, well, I don't know about that now. So, because even if you look like I think you can look at schema. Like there is some some schema ID. Can you can we look at that? What is that? Is that just a new type? Well, this is some sort of. It's really just a new type. It's a but essentially that will be referring to this string. I got it. Yeah. Well, I don't know. I gotta gotta think about it some more. But, okay, so then then we can have in this case like common types for these operations and it makes sense. But looking at this, I don't know if this is necessarily the way to go about it. Like whether we should expose that because then then again that seems like it seems like a schema for interacting with Indy. What we I guess should be aiming for is if we define our own types, let's say we create our own schema type. Then we can convert it into the Indy types, which can be passed to the Indy ledger or whatever. I wouldn't. But you know, like, yeah, this is like concern when you want to like support other ledgers, but isn't this the goal of the library? Like, I know we are primarily targeting Indy right now. But I think it's worth thinking about it from the get go in terms of this agnosticity rather than. I think this is something they, you know, they are we as a community need to solve in this library. You know, this, I mean, otherwise like, yeah, we will have to like reimplement these things and it's already here. I think the people should be solved here like the the actually let me let me check one one more thing. I know there's like also like something called unencredced RS, which is something very similar to credits. It's like some sort of small further iteration on the credit eggs is unencredced RS repo. They're just they extracted Indy credits. I know they're just like some sort of small differences. And but I want to see what's actually in here. So source. Okay, there's data types here. Let's see if there's any more generic. It looks very similar. Aha, there's not. Yeah, this seems better. This seems better. Yeah. But I guess it will be pretty similar. I guess ultimately the same thing, but pretty much agnostic to what they did in here. So we should probably take those types from here then. Yeah, that looks a bit better. schema. There's also some other stuff which revocation status list, which is, for example, not in the unencredced in the in the in the shared RS. Right. And let's see what else is here. Services. What is that is sure. Hmm. Create schema. Some generic. What is the generic with the issue ID. I think what is, yeah, to create schema. It's an issue ID and issue ID is what I'll check out that project we can take a look more easily. I think I can have it. Yeah, so that looks better. From like just the first quick look. And yeah, ideally, I guess the goal would be to just use that, like, Hmm. Hmm. Yeah, this looks pretty like they, it looks like whoever did this kind of targeted the unencredced RFC. Just looking at the, not the RFC, sorry, the, like the specification, just looking at the specification alone rather than kind of considering in the or something like that, which is, again, the goal to have these things uniform across any ecosystem. Yeah, the initial implementation on uncredced RS is derived from in the shared RS. Yeah. So. And then it's a question like just how to kind of. Hmm. No, I don't know exactly how different on uncredced RS is from like the. It doesn't have any specific stuff from what I see, like sequence number and whatever operations are happening under the hood, which are in the specific, and that's what I didn't really like about like that in the data types. Like, I know they need it. I understand they need it, but they need it for their ledger and their ecosystem. And we don't want that. So this seems better. I'll need to have a closer look, but. Yeah, and just I'm wondering now, like, let's say, you know, assuming that we kind of use this want to use this. How what's the impact on the existing critics kind of implementations, but I think I don't know I assume there's a conversion in place. I don't, I don't know because that's that's the problem with having two types from different crates. And even if we create our own types consumers would have consumers of our library would have this problem because then there's this, there's the orphan role in Russia wouldn't be able to convert from a foreign type to another foreign type, which would ultimately be the case, regardless of what you do. You would technically have to like create your own type and convert from one to the other, I guess. There will be there will be that sounds like a workaround but um, yeah, I don't know. Maybe we can, I guess kind of wrap it up, I think. Good, but we can look into this I'll have a look and yeah. Yeah, we'll just have to. But yeah, the goal is to migrate to to this stuff. Right. When was this contributed. Yes. Like there's like pretty active still. Yeah, it seems like. When was the oldest commit oldest I see three years ago. Okay, well, I guess we have food for thought and some some stuff to research. I think we, we have the direction, which is important. Let me just quickly jump back to like our agenda to kind of finish it up. So, yeah, break down a very easy score into smaller stuff. I'll just have to figure out those types and like how to go about maybe migrating the critics to show we first migrate actually the critics on on crates or or because then we so we wouldn't have like three different implementations at one time. Like VDR tools and in the eggs and on crates, but it's kind of do it somehow systematically. Oh, okay. And and the typeset pattern. I mean, I guess one of the tasks was to like revisit the connection protocol. But I would say that both are like equally important. Maybe I was even prioritized the areas V6 core and this this trades before we continue. Yeah, I would I would do the same. And there's not a lot done in the connection protocol. I kind of wanted to talk about it too, but we can, we can do that sometime later. Yeah. Pull this one up a little bit. As a kind of priority. I might be that I would say like, I would say like, I would say, I would say, I would say, I would say, I would say, I would say, I would say, I would say, as a kind of a priority. I might be that I would say like, maybe I can perhaps take this one since he already implemented the resolver. He probably the most suitable person to integrate it. He knows a lot about it now. And then the typeset pattern. And George is working on that and my I might I might join in if I have a capacity. But I think these are the three important topics now, and that's it, I guess. It's been a long one. Yeah, long one, but good one. Productive, good discussion. Yep. Alright, pleasure to talk to you. Likewise. Good one. Enjoy your weekend. It's almost here. You too. Take care. Bye-bye.