 Good afternoon, everyone. All right. I think we can get started. Let me see. Your recording is already in progress. Yeah. Okay. So, welcome to the earth. So I'm just working group call of April 13. I need to remember you to buy but I've let you go to conduct and antitrust policy. And if you would like to add yourself to the tennis list, feel free to do so. I'll post the link in the chat again. And they will kneel here that would like to introduce themselves or share what you're working on. Yeah. Hello everyone. My name is Francisco. I'm from near farm. I'm a DevOps engineer. And I've been working on this project with near farm that is for creating a digital identity for new I you national government. I'm mostly interested in understanding some of the workings of the tool to properly create infrastructure and network and some any details that might be interesting. Cool. Good to have here. And yeah, maybe if we have time for some questions at the end to a weekend, we can help you answer them. All right, then we can move on to the agenda for today, or well actually status updates are there anything we want to report on for today. I don't know if the bifold call was this week. Yeah, there was a bifold call this week. It was pretty short. Similar to the update here. Ariel has more to add on. I don't think so. Okay, cool. Then I think on the PR that we opened there. Well, there's a lot of merge conflict but it is ready and working. We also tested it with verification and everything it's just there are some issues we're experiencing with the migration scripts in react native, which we aren't experiencing in Node. So, yeah, need to dig deeper in that it's a bit hard to look at these lower level stuff in in react native. Sometimes, but yeah that's basically the last thing we need to do. I know there has been a lot of work on supporting older Android versions apparently you know the status of that. And I know there was a lot of discussion but I think that it's going quite well. I think there's support for Android six for any video I think. But we also got a new issue with. I think for emulators. I'm using actually 664 for our, there seems to be a symbol missing again so we might have to do also some investigation for Oscar, but as long as we have the images. We're adding support for Oscar and I'm on credits will be fairly, fairly easy. Yeah, it's going very well it's a lot better than I expected so it's, it's very good. Cool. Okay. Yeah. And so the new issue with missing some symbols arise when using the new build strategy or was that already there. But we, like we, we mainly does it on a macOS host and then I think it picks the AR 64 image. And there was an issue with the x86 64 image. So it might have picked one for us that works but if you are on Linux or Windows or something it picks the wrong image and then it doesn't work. So, it's a bit of a weird issue that needs a bit of debugging. Okay, cool. Well, at least one issue result. Eric's call. I comment on that because I am. I also had a problem with the, with Oscar on a x86 because of the of some of the petitions on on SQLite, I think, but I managed to make it work in my emulators under Linux at least. I don't know. I don't know about about macOS. I, I made a comment. Do you remember that the hack on the document that you made. Isn't there something about that because I remember that I Which which Android API that you use because the issue occurs on anything above 30. I'm using from from Android seven. It's working. Okay, then I think you might be below 30 if you could try with an emulator on Android, like 31 or the Android API or something what it's called. And if that still works because if that still works there might be some local issues. But I can echo I'll send you a message afterwards. Okay. Let me see. This is the hack and the document you were talking about right there. Yeah, I don't remember if I, if I, I yes, yeah. So there's nothing related to ask are not working in x86 64 architecture. Exactly. Yeah, that what I did was to, to use an older NDK. So I couldn't. I do I do it locally in my computer. Yeah. Yeah. I think that that is the same boy. And a thing with NDK is is I think they added support for air 64 so for M1 silicon and indicate 24. So, I have to think about if that will collide if we go to a little and it would still work on both architectures. But this is a fix that we should definitely just do it like this. As long as we don't break up something else in the meanwhile. Okay, I'll post the link here. We should probably also share that with Jason and case show. Cool. Anything else on the five fold shirt components reignited thing. Okay. I think this was from last week right yeah. So the, the errors call yesterday go through and did anyone attend. I guess not. Then let's move on I think this one for. I know there's going to be a good comfy to connect to Tom, I don't think we'll be able to participate as part of, like, a of j right. I don't think anyone has updated it to work with like the latest stuff or have you looked at this area. No, no, no, unfortunately we have some other other issues as you may know. But yeah, that actually I was yesterday on the on the areas call and now that you're mentioning the connection Donna I remember, because it was a very little one. It was a short one I mean it was about 20 minutes or so. And the, I think the only thing that we discussed yesterday was about the release of the did come to point one that introduces some. And what some say was that they will do that release after the IW so just to not add more confusions on this connected on, but there are a few minor changes it's not something very super relevant but but yeah, there will be an update because of course we need to be supported by the by the libraries. It was mostly about having the body, the body field will be optional now because there are a lot of messages that will do not need any body because it with the type is enough. And also about the service endpoint that before 2.1 it needed to be an array of or list of of endpoints and now it can be an either an array, an array, or a single endpoint. Cool. Okay. And aren't these breaking changes and then or. Well, it depends. I think that if if our library is only accepting. And at least as a service endpoint for instance, and it will get a single object. I think probably it will will break right. And the same with the body maybe if they if it does some strict validation about the, the body to exist, even if it's empty, it might fail. So there are simple changes but but probably they will be needed to be implemented to make it work. Yeah, exactly. Okay. Cool. Then. Yeah, the shared components we have been making like updates when we when we see them. I think most books have been. Yeah, fix now. There are some books to be fixed with the replication implementation from Ariel. But yeah, that's just going steady I think whenever we have like the I think when we have the migration stuff working in react native, then we can make the, like the stable release is for all of them but I think the, the death releases now are already quite stable. Yeah. Okay, then for the agenda. I added zero for zero not sure if we want to discuss anything in specific for zero for zero. I have a legacy versus unqualified identifier issue where we have something we how we want to approach it for now for zero for zero release and then a long term what we want to do and seeing, yeah, maybe getting some feedback on that approach. Something about the checked integration being merged. I don't know if we have to discuss it in very much detail. Dave from the check team will give a demo soon of this. And I see this is from last week. Did anything come out of this like do we want to discuss this in more detail or doesn't issue need to be opened from this or because I missed last week's meeting so curious if there's anything we need to do still on this or can I just remove it. I think it can be removed. We didn't really have a lot to discuss. I was more serious about like all we created all these modules now and it's very nice but it's also makes it like infinitely more complex. And I was mainly wondering if people already used offer versions. And just see if they find it more complex and how we can make it as simple as possible for people to get started like before like you just you you create a label for an agent and you're almost done. Maybe some wall of configuration and now it's a whole lot more. So what can we do there. It's not really fixed yet but maybe if there's some time that over and people used zero for zero they can talk about but might be good to track it in an issue or discussion or something. Yeah. Cool. I think we have like an issue it's not the wrong repo. Specifically for like how to it's on. Yeah, I think this is one like simple agent setup with presets is one way it's not really focused on like it's too complex now with more like with what maybe would work. I think we can track it here. Right. Yeah, yeah, I think it's good. I now see the with Jack which is kind of cool to do it like that with short components. Also, probably think about it and see if we come up with something that is easy to use a little bit smaller than the line object. Yeah, exactly. Yeah. Cool. Then any other things we need to add. Do we want to discuss your application PR and maybe some thoughts questions you have for. Okay, if we have time, it's really nice. Yeah, cool. Think would be a good one to discuss. Okay, then I think we can get to this one a bit later on I'm going to start with the legacy versus qualified. Identifiers. Currently, it's a bit broken in AFJ in like the mix between qualified and unqualified identifiers and if you're using the new Anacred's RS library, you actually can issue currently using unqualified identifiers in the latest alpha, which is not very nice. You can only use the qualified ones. And the reason for that is that the schema and credential definition records internally are stored with qualified identifiers and that allows us to know like which ledger a schema credential definition belongs to. But that also means that you can use them with legacy identifiers because then it can find the credential definition record or schema record in storage. So, I wrote something out here and what would work which is kind of complex but it basically means you can use them interchangeably, and it means if you like further than issuing with both but it means if you receive a credential in the unqualified format, we'll actually store it using the qualified format so we know which ledger a credential belongs to. And you can also share it in both formats so if you get a request for unqualified identifiers you can share it if you get it for qualified indie it's only indie then because those are interchangeably basically you can also share it, but that requires some. Yeah, more complex implementation because basically for all credentials that are bound to an indie network. We need to support both identifiers, which is the unqualified legacy identifier and it did in the identifier. Which is quite some work and we don't want to hold up the zero for zero release any longer. So, what we came on in a discussion is that for now, we do not support qualified and unqualified identifiers interchangeably. And that means if you you can issue with both qualified and unqualified. But if you receive a credential in qualified format you can only use it later to share it when a proof request is made for the qualified format so you can use them interchangeably. Which I think qualified identity identifies aren't used that much yet. And. Yeah, so you can receive both, but you can use to interchangeably. And I think for now this is a simpler change because basically the only thing we need to do is for the schema and credential definition ID. We need to store the legacy or the unqualified identifier and that means when I want to issue a credential. I use with an unqualified identifier it will know how to find the credential definition record which actually has to qualify it for the full did in the identifier. But then this is quite simple I have this like almost implemented locally so I hope to have that PR in by today, and I think that's basically the last thing we need to do then for the zero for zero release. And that just mean you can use them with unqualified, or like interchangeably, and that's something we want to do later on is we support query info records that are stored qualified using unqualified so you can use them in any combination, and will create a migration that can basically migrate all unqualified and credits credentials to a did in the qualified identifiers. So we also know how to store. Like, yeah, we can store which ledger a credentials associated with. So, one thing here is that this will be a bit more complex process because you can't infer the ledger stored on based on just a credential so we would need to have to fetch data from the ledgers to know which it belongs to. So that will be a separate migration script you can choose to run in your wallet. Yeah, so that's the ID. I think maybe a few questions is a to people think this like the short term approach for zero for zero is is good and be do people think the added complexity of this to support the like the unqualified and did in the identifiers interchangeably is worth like the complexity to support that or do people think like it's okay to not support them interchangeably and really see them as separate credentials. I think for me it's okay to not to not use them interchangeably. I mean it would be nice but I think we talked about it before and there is. In my opinion, just not too complex to edit and also want to do it before zero for zero. It's another blocker before that release. I think it would be good to add it later in the long breaking way that might be nice. But for me, yeah, I, I think it's just be good to get zero for zero out, especially if it doesn't have that much value that I know with qualified identifiers not being used that much. I mean for like the this as the short term but I didn't like the B was more like in the long term, do we want to add it so not for zero for zero, but do we want to add it at all. I mean, yeah, I mean if someone wants to add it in like a like a module or an extendable way, then I think that's fine. But I, yeah, if there's a need for it, I don't think we should add it if there's no need for it. That's, I guess, what it comes down to. But I'm okay with with adding it as long as it doesn't lose. And that's what we have now. And that's a lot of backwards compatibility maintenance legacy issues like that. That's my only concern really. Yeah, I think it will add some, like quite some other logic would need to be added to like the core modules. So the generic Anomkratz because it's very. Very specific behavior. But I think it may be justifiable because it's part of the Anomkratz specification to have those different, like have the legacy identifier support it also. What I'm worried about is that people will have like people will start will keep continuing issuing credentials using unqualified identifiers for quite some while still, and not being able to use them interchangeably will mean that all those credentials will never be able to be used with it in the identifier server make proof request I always will need to include the legacy and identifiers and I think it may even like make the migration path to unqualified identifiers harder because if the credentials in the wallet can only be used with unqualified identifiers people have a restriction on updating to the new type of identifier because they can use the new type of identifiers for credentials that have been issued using unqualified identifiers. That's a bit of my worry I think with not supporting them interchangeably. Yeah, I think that makes sense. Yeah, wouldn't really wouldn't really want people not to update because we don't support their their formats or something. And then it will just be stuck on an old version, which is not very very good behavior I guess. I think this has the most impact on mobile wallets probably like holder wallets is someone here that has an opinion on that from like a mobile holder wallet perspective. Okay, then. I think for now for zero for zero we're going to do take this approach that allows to at least issue with both so you can still issue with for unqualified identifiers. And at a later stage, we can look at like supporting them interchangeably and the effort required to do that but it's I think yes parents said it shouldn't hold up to zero for zero release. Okay. Then. Next topic verification PR from Ariel. Do you want to share a screen area or should open PR or what what's best. Yeah, maybe I can, I can share a screen. Okay, you can use your screen right. Yeah. Yeah. Okay. Basically the, the, the, the goal of this PR was to ease to to give us a way of issuing revocable credentials as the title say, but at least in a basic way because it's the process of issuing a revocable credential is not simply in the sense that it's not just that you need to put a bullion flag to true and that's it. Because in order to to to issue revocable credentials you will need to, apart from creating a schema and creation definition you also need to register a revocation registry definition. And also, maybe something that it's quite important and not so evident, at least from the concrete specification is that you will need to upload somewhere details file. So, basically what the, these PR ads is the, the API is a method to create and store these objects. For revocation registry definition location is a list. And also improves a little bit the interface of that we already we already have for managing the tails files. Because at the moment we have a simple utility methods to to download the files and and and store it in the in the cache in the agent cache. And now it has been extended to have an interface that allows you to not only download it, download the details files from somewhere, but also to upload it. Using the server you have or, or whatever. So, how does it work, I will probably, maybe if I, if I look at the tests we, we have maybe it's a bit more clear. We have a, let me see. Well, the implementation right now is is generic in the sense that all the changes have been added to the Anoncretz module, and also on the Anoncretz RS module. But there is not any implementation yet for in the SDK or in the DDR. And of course, I checked because it's, it has emerged today. But the idea is that it will be quite a straightforward to implement it for for Cardano or to the web, which is, which is the method I'm using right now. So, we have the tests here. So, let me see. So, but basically when in order to create the credentials and to do the protocol exchange about the issue credentials, it's exactly the same as it is right now. And then the difference is that when you want to, to revoke a credential, what you need to do is to to call the Anoncretz API to do the update of the revocation status list. And then you pass it, you pass to it the, the revocation registry definition ID and the indexes of the credentials you want to revoke. So in this, in this step, what the framework will do is to, to create a new, a new entry on the, on the DDR. And then if you, you want to, to send you the, the notification of the revocation where you, you can call the credentials API to do so for each connection associated to each credential you, you want to, you have revoked. This is something different from, from what I have seen on the, on ACAPI that were, because I think that ACAPI does several steps at once. But in this case, we are using it separately to mostly to, to, to have a, a, a simpler state management because my, my main concern was what happened is if I can, I can do the, the update of the revocation list, but the notification fails. So that, that's why it's quite, let's say primitive right now, or I don't know if primitive, but it's modular and it's, it's, it's made in a way that maybe the logic of the retrying and so on. And all the stuff, the stuff have to be managed on the, the controller side. And for the, for the tails, for the tails file, what I added, well, you will see the, that we have a simple interface. I did, for the tails, are you using the, in the server? No, well, that, that was something I wanted to, to, to mention at this moment, very, you read my mind. Because it wasn't possible to use the, the, the, the, the, the VC gov, the classic VC gov in the tail server, because for that one, you have to use an, an indie server, because actually for two reasons. One of the reasons is that you have to, to the, the, it, it checks that the tail file you're adding is actually on the, belongs actually to, to a, to a, a lecture object. So you have to use a, an indie VDR, any, any lecture, which is not the case of, of my test because I'm using an in memory registry. And the other problem is that the, in the tail server uses the revocation registry identifier. In, in the, in the URI, they use, so if you use an, an, an indie and, and, and, and, and qualified in the identifier, you are good, but if you are using a fully qualified identifier, you can have issues because you will have some slashes and on whatever the, the unencrypted method you have, you are using defines. So it's, it's not, it's not easy. This is something that also happened to us recently on the areas. And there's some awareness that also expects to use unqualified identifiers that work well for the URLs, but it's not working fine with the fully qualified identifiers and that's why AFC is not, is now failing because of their, well, what Timo has explained me some, some minutes ago. In this case, what we have is the interface for the tails file service, but that's how I call it. That allows you to, to get the, the, the path of the, of the, of the tails files you are going to download. And you have the upload and the download tiles file. We have a default implementation that will be used if, if you don't provide to the, to the unencrypt module, any configure configuration parameter that is working like the implementation we have right now that only supports downloading text files. So for the holder, it's okay using that because we don't need any specifically implementation. And as you can see in the upload files, it says that only supports text file downloading and for the actual demonstration of for using it, what they did was to, well, for the test, actually, we will have an in memory tails file service that that's nothing actually uses the same, the same file that we will have in the file system because in the test we are going, we are, we are creating all the files that we are using. So we will have it, we will have them anyway. So, but for the demonstration or for what I'm, I'm doing right now with deep web. I have, I have added some a tail server, very, very basic tail server in the samples directory that provides an endpoint where you can post a tails file and it will give a tails file ID that will be the, and we have a get for it to get the file. And it is more or less respecting the same interfaces as the VC go up tail server because it's just getting a file and with a file and it will put the hash as a file name I think and a put, sorry, not a post but a put that will receive the file and will, it will receive the ID as a parameter as well and it will store it and that's it. We have this server that works and work locally and also the, the service implementation that that implements the upload tails, tails file method. Using the tails file ID, this is where it generates the new ID for the tails file and with the form that I, it will upload the, the actual file, it will not do any, any particular check on a video or something. It works like that maybe if we want to, to have a robust implementation of this we will have to do it. I'm not sure why we will need to do all those checks but if we are going if we are on the issuer side but but well if you so I suppose that if you are using a server that is used by different services, maybe it can be useful to, to make it more secure I don't know. So the question. Sorry, the, those methods for the tail server resizing which module. So it's part of which model is it's a specific module for a tail server is part of an on credits module. The interface for a for a tails file service for a generic file service is part of the unknown credits module. Okay, and it does not define the way you have to, to get or put or whatever details, it just gets, I will show you the interface again. Yeah, because, because it just, it just gets as an input their definition the object. And it outputs the, the URL in the case of the URL to download afterwards. And in the case of the download it will get it will give you the local path of the file. So if you want to define any kind of tail server you can with this interface you just to implement this interface, the, the, well the, the basic interface, the, the file the interface, and you can do whatever you, you want you are not tied to a particular API. And it was because on the unknown credit specification the methods do do not define details, details part right so this is, it's not part of the unknown credit method required. So but but he is, is included there right so there is a different on that so if you follow the spec I can just write my, my method. Just to store all the other objects, but not the taste pipe. And that may be the case as can be a different method right. That's my, my concern. Yeah, but, but the, the problem is where, where should we define the details by management, if not something because it's needed for the for the unknown credits, right. Yeah, maybe it's a misunderstanding between this and the unknown credits and then we should say something on the right. We should write that also on the on the other working group probably. Well, okay. I don't know. No, because currently, for instance, the in a cup by they are using specifically the in the and on credit in the tail server, and they are using the the API provided by by it. Of course, that will not work. Once they implemented for for checked or or any other and on credit method. So, I guess they will also define a generic interface to allow the issue to do to choose their own, or, or the detail server they decide to use, and maybe even they can also specify a particular tail server for each and on credit method. That's also possible, possible to do. In this case, we are using the same for for all the methods but but you can also actually you can in your implementation of this interface, you can also maybe we do, because you receive the register to definition as a parameter. Maybe we can add also the ID. So we can from this class we can also decide if we are going to call the classic basic up tail server or or or another one or maybe we can we can do that. Change it. What wants to. Yeah. Yeah, I guess a follow up question of Redolph was saying then is, is the Hill server that you have here. I'm compatible with ACAPI, meaning can ACAPI use it, or is it specifically the methods are only usable by a J at this point. The reason I ask is because, if the methods are only usable by a J, then I do think it is a non cred standard problem versus a something else. Yeah, but but but that's something I want to be clear about is that this is just a sample. The server I added is a sample that it's actually not used by the tests suite we have. Actually in the test suite we have an in memory implementation that actually doesn't use any of this API. If you are if you are going to be an issue or using a FJ, you can just need to implement the disinterface and put any server you you want. Maybe if if it's confusing to have this sample tail server in this repository, maybe we can can put it somewhere else and just reference it to. Anybody to know about working implementation for this but it's not enforced to use this particular server that that's what I want to make clear. I'm definitely on board with that I guess my concern is over the interoperability between the different frameworks right. Yeah, at least they should be similar right I think it's a it's a right to get to get the to get the tail file at the moment it is it's absolutely the same as as in the case the of the. The VC gov in detail server, but still if you if you this is not on on on the on the test file service in there I mean on the AFC interface. So, this is up to you to implement if you want. If you want to use the the the VC gov tail server to upload the files you will need just to to put here on what what you need to call it. But but what's specific on this on the spec actually is is not so. So extensive about that but what this is specified on the I don't really expect is that the file must be put somewhere that is that. In a way that you can get the file by getting the URL for your URL that you have and you will give you will get the fight. And, but yeah that's. That's possible and actually that work is exactly the same as it is working right now. Well, and about, I don't know if I if I was more or less clear on what I was saying or maybe. I know that I'm not usually clear about about I always mix all the several concepts or maybe I. I got you more confused than. Clear about that but and then. About the some other notes I put the here is. Yeah, that for the moment, in order to revoke the credentials or to to work to send to send the notifications. We have to use the, I'm sorry, for the for the book in credentials we have to use credentials API, and it will feel more natural to to use the credentials API to do so. But it will need more work to do because Well, yeah, we have to deal with different credential formats and to figure out what what format corresponds to each credential we have we want to revoke and what it can be a bit more complicated to do. And I'm not sure it will be actually makes a study necessary for for the. For all the cases. And of course it will also depend on some fixes on anchors arrest because I found some some bugs on the traditional status list management, especially on the JavaScript side. And I'm still having an issue. When managing the timestamps that I will, I will shortly add to the issues on the unknown credits arrest because it's not for me, this override. The revocation intervals override that is not is not working at this, how I understand it should work. But well, I hope we will figure out what the problem is and we can fix it as soon as possible. I don't know if you have any question or comment. It's very cool. Yeah, same is very very nice this is this is like has been so long on the to do list and I think really important to finally support all the roles and fully so yeah really eager to get this merged. Yeah, I want to add something else that I didn't mention here is about the way the framework works when we are issuing the issue in the credentials. You know that when we issue credentials, a regular credentials, we have to assign to them an ID on the revocation status list. This is done automatically by the revocation by the credential format service. And when the maximum credential number for for the current revocation registry registry is reached. It will mark, it will change the state of the revocation status list, the revocation registry record to full. This is something similar to a KPI. And then, well, you will know if you, for instance, if you from your application listen to the to the repository updates. In particular, the record type, you can figure out that a revocation status, a registry was full so you can create another one. This is, this is something that in a KPI is managed automatically. But I think that for the moment, it's okay for to live to live also to the to the controller to to do that that logic, if they will, if they want. For the moment when you issue a revocation credential, what the framework does is to to find active revocation registries and it picks the first one it finds if if it doesn't find any, any revocation registry. It will throw an error so maybe you can catch it and and create it and retry. So that's that's it for the moment. Cool. Nice. I think we're almost out of time then so I didn't know if we have time to discuss any of the other topics. Let me see. I think. Yeah. So one thing, maybe that's just is that the tech integration has been merged in the in the today. So, when zero for service release that should also be fully supported with on credits, and it was over in red star. So that's quite cool. PR did introduce some issues again with the CI. It's been fixed because right has added larger runners, which is quite nice because the test now run in under 10 minutes. But yeah, it is probably an issue that somehow it it it goes out of memory, which I'm not sure it should happen. I mean it could happen but I think it's like something that has been popping up recently so maybe it still has something to do with the shared performance or maybe a memory leak or something, I don't know, but yeah, something to look at. Then I think. I'm sorry for interrupting. Can I ask a really short question. It's Renato from DSR Privacy Check. Is the pull request contains the separate module or it's integrated to existing modules. Well checked integration. It's a separate module. Oh cool. Thank you. Cool. Yeah. Yeah, so I think that's it for this week I can attend next week due to IW I don't know if other people are also attending. If anyone wants to take over hosting the meeting, then please reach out to me. If not, I'm going to cancel the meeting. So let me know. I think it can go through if somebody wants to host. But I think all of our team is there. I think also other so yeah, I need to see. Cool. Thanks everyone. Thank you. Thanks. Good bye. Thank you. Thank you. Bye.