George Mulhearn: Hello!
@kukgini: Uh! Hello!
ckowald: Hello! Hello!
@kukgini: Of Hello!
ckowald: Am I correct in that? This is the Area's. Vcx meeting?
@kukgini: Um,
@kukgini: Yes,
ckowald: thanks.
Patrik Stas: Hi! Everyone!
George Mulhearn: Hey?
@kukgini: Hello,
Patrik Stas: hi! Cocaine, I see. Uh you. You arrive as well. Happy to have you here.
Patrik Stas: Uh That's why it's a little bit more
Patrik Stas: uh to see if uh anybody else is
Patrik Stas: joining Today's meeting uh last week with go from Brazil.
Patrik Stas: Uh!
Patrik Stas: I was at four Am. Last week for him. So hopefully this at this time it will be easier
Patrik Stas: to accommodate his time zone.
Patrik Stas: Uh, in the meantime. Uh, I think we can start with Uh
Patrik Stas: um!
Patrik Stas: We can start with the uh obligatory. Uh
Patrik Stas: um disclaimer of hyper ledger.
Patrik Stas: Uh, I just have to find it. Uh, just give me one moment, please.
Patrik Stas: Okay, Almost there, almost there.
Patrik Stas: Okay, Now I have to figure out how to share my screen, and
Patrik Stas: and for some reason I have some issues. With that it would appear that way.
Patrik Stas: Well, I started my camera. How do I share my screen? Yeah, the button to share screen is straight out. So um. In that case I kind of display the slide. So
Patrik Stas: uh i'll, i'll just read out the Hyperlanger uh anti-trust policy allowed so uh
Patrik Stas: uh hyper ledger under trust policy, and all this uh Linux foundation involves um meetings involved participation by industry competitors, and it is the intention of the Linux foundation to conduct all this
Patrik Stas: to trust.
Patrik Stas: Is there for extremely important that attendees, and here to meeting agendas
Patrik Stas: and be aware of and not participate in, any activities that are probably to be prohibited under applicable State federal, or foreign anti-trust and competition laws.
Patrik Stas: Examples of this uh type of actions that are prohibited as an installation meetings, and in connection with Linux foundation activities are described in Linux foundation. Anti trust policy.
Patrik Stas: Um. If you have a questions about these measures, please contact your Company Council, or if you are a member of Linux foundation feel free to contact Andrew uh up up deep role, or the firm of just more up to grow lp, which runs legal console to like some Linux foundation,
Patrik Stas: all right. So now that we have uh this uh, we can move to our uh meeting agenda.
Patrik Stas: Uh, so maybe we can first start uh uh, with uh, just a brief introduction Uh,
Patrik Stas: it's to kind of get to know each other uh as I, as I mentioned cooking, you haven't been with us last week, but maybe you know we we We know each other briefly over the like uh the discussion. Maybe you had some full request or some comments sometimes. So uh, you know, you maybe know, you know, as a little bit. But anyway uh myself, uh my name is Patrick Stash.
Patrik Stas: I'm. Uh I'm. Based in a bracket Republic, and i'm a contracting for uh South African Uh Bank. Um upset uh i'm One of the maintainer of uh of uh
Patrik Stas: a hi.
Patrik Stas: And uh, yeah, happy to have you here. So maybe you can just tell us a little bit, You know very base to
Patrik Stas: what's company working for, and how or how you're using everything you saying something like that.
@kukgini: Okay? Uh, I will start um.
@kukgini: I am so excited that I can get an opportunity to introduce myself.
@kukgini: Hmm. I'm. South Korean acting under the name of a cook, Jenny.
@kukgini: But my real name is Zooming Flee,
@kukgini: and I'm working at an architect and Lg. Cns, a System integration company in charge of the Lg. Groups. It systems.
@kukgini: My organization has been researching Ssi for a past several years as a blockchain specialized organization,
@kukgini: and our big term goal is building in the area space, the staff solution for
@kukgini: our energy groups.
@kukgini: And but, as you can see, i'm not very familiar with the English, so no money. Maybe I can understand correctly your speech. So uh
@kukgini: so please for me to just time watching. By now.
Patrik Stas: I think your English is fine. Oh, yeah, uh, Thank you for introduction, anyway. Uh: So yeah, I think we can. We can. Uh,
Patrik Stas: no. This is, let me ask maybe one more question, if I may. Uh, are you? Are we currently using in some project? Or are we still in sort of research phase trying to maybe decide or experimenting with various implementations.
@kukgini: Uh: yeah, I I won't try to use ares the Cx in a uh mobile app
@kukgini: Is the holder, or call it. But
@kukgini: uh, our organization uh to side uh our first product
@kukgini: use. Uh:
@kukgini: So yeah, And the cost that issue or verifier is based on occupied
@kukgini: Mhm But,
@kukgini: uh, you know, uh, someday,
@kukgini: I will replace the all that part uh to uh Aries Pcx. Because it's. Uh, I think it's a better solution,
George Mulhearn: I see. All right. Thank you. Thank you. So yeah, let's let's move to uh, to our agenda. Now. Uh I have my screen with the agenda. Is that easier?
Patrik Stas: Uh, yeah, uh, I have a issues sharing my screen. Um, It's purely technical issue. So if I may ask you, George, yeah, could you? Could you share the screen with agenda?
George Mulhearn: Can you? Can you see my screen?
Patrik Stas: Um: Not yet.
@kukgini: Oh, yeah, I can see. I can see it.
Patrik Stas: Okay? So uh, the first one was to kind of overview the recent work which uh has been done.
Patrik Stas: Uh: Oh, okay, that guys, I can share my screen now. Uh i'll, I'll do it so I can also open a github or
Patrik Stas: stuff like that.
Patrik Stas: Well, thank you. Thank you. Uh, i'll hop into the
Patrik Stas: the latest state.
Patrik Stas: Uh: yeah. So just kind of overview what has been done. So um
Patrik Stas: uh, we have. Uh, we have a big Pr. Right now under way. Uh, we just removal of the Ffi layer between as Vcx and a Vdr. Tools uh that being this Pr. Uh. C. To one right here
Patrik Stas: uh there's still some failure. So a colleague of mine is uh working on this actively. Uh it's a largely modifying the slash in the module. Uh, most mostly so a is Uh. Vcx
Patrik Stas: uh in the uh. That's as as that's the module which is, which is linking is the Cx with uh Vvr tools.
Patrik Stas: Uh. So there's a bunch of rework basically all of the calls into um vdr tools uh where it previously it was uh through, like C C Abi calls like this.
Patrik Stas: Um, Now it's uh just looking directly into the rascal of rascal of Vdr. Tools uh making the same. I go on calls
Patrik Stas: uh. So this is, this is under way. I should uh surely uh bring some performance boost, and uh, like safety boost, as we can be more sure with the typing. And uh, I think most importantly, even uh sort of maintenance of this. It will be just easier to kind of
Patrik Stas: see the stock we are calling. It will be uh cumbersome to find out the interactions
Patrik Stas: uh through the the the
Patrik Stas: uh. So there's uh lots of changes, lots of like uh quite big delta here, but they are mostly in the uh, in the in the
Patrik Stas: a module uh, there's uh, There's changes here in the other modules which I know. George uh from Anonym labs has been modifying. But uh, this is mostly uh imports.
Patrik Stas: Um! So hopefully there won't be some sort of big conflict here
Patrik Stas: uh to resolve. Um, then, if I move on to the next point uh we have merge some ci optimization uh pr uh, then my my done by myself uh throughout last week. Um!
Patrik Stas: And they they arguably improve the ci, and most of all uh like clean that that made it more readable.
Patrik Stas: Uh, however, uh, there's actually a new round of ci sort of reward under way where previously uh, we've been building uh basically running all of the tests
Patrik Stas: and doing all lib Cx interactions in docker containers.
Patrik Stas: Uh Now, we're trying to get rid of that and just run basically run, you know. Do all the work directly on the github runner
Patrik Stas: Uh, as this turns out to be a much faster, it's easier to cash stuff
Patrik Stas: uh, so there will be uh the Pr.
Patrik Stas: We just have opens right
Patrik Stas: uh right here uh It's still just uh we're in progress, so probably not worth it looking into. But, uh, the the consequences will be quite nice. I'm hoping this will make it easier for contributors to
Patrik Stas: just all over the uh sort of the entry barrier, as the ci will be faster, it will be easier to contribute because it's it's it'll be faster good to get a feedback loop
Patrik Stas: uh
Patrik Stas: moving on to the next point we had a revocation, notification protocol implemented by
Patrik Stas: a colleague of mine, met us all who is also, uh with us on the call uh so uh, that's something good yet to be uh
Patrik Stas: would say, to be merged very soon. Uh, basically a revocation notification protocol uh enables issue of a credential to notify holder uh in whenever the the you know the issued credential uh has been revoked
Patrik Stas: uh, so that way. The holder itself, you know it doesn't have to maybe check the ledger himself. Uh, but he will. He will be simply notified by the fact that you should revoke something
Patrik Stas: uh,
Patrik Stas: maybe touching on this briefly uh, something related is, uh Pr. Which we already closed uh, and that gives uh ability to hold her. This is use. This. This is useful, especially for the mobile use case
Patrik Stas: uh this Pr. Gives a holder capability to find out uh by checking Ledger whether some credential has been revoked.
Patrik Stas: Uh:
Patrik Stas: so uh, okay, maybe one correction. Actually, my statement was not quite correct. This gives the the holder available ability to find out credential relocation. Id which is a piece of information we just needed
Patrik Stas: uh to check whether a credit you know whether that Id has been revoked. So this is kind of preliminary step to enable the use case. But basically I can imagine that. Uh it will be it. It will be useful for, like mobile device, to do some periodic check
Patrik Stas: to see if you know all of the holders credentials are still valid, and whether they have or have not been revoked, you know, in in in past, and perhaps somehow, you know, uh, show that you need to that fact in Ui
Patrik Stas: uh,
Patrik Stas: okay, and um.
Patrik Stas: And next next uh last piece capable to to verify vocation status of credential. Yes, and that's what I just cover now.
Patrik Stas: Uh,
Patrik Stas: okay, next on it. Well, maybe I before I move on to the next point, i'll just stop for a second just to see if anybody has any question or feedback about
Patrik Stas: what I've been talking
Patrik Stas: up until now.
Patrik Stas: So it seems like everyone everyone's good. Uh. So uh next point on the agenda we have, like a a short presentation from George. Uh,
Patrik Stas: um,
Patrik Stas: and uh, yeah, So maybe we can move. Move on to that, George, can I give you the mic?
George Mulhearn: Yes, sure, sure. Thank you.
George Mulhearn: Um. Am I able to share my screen? But yeah, I think uh to
Patrik Stas: um.
Patrik Stas: I have to figure out. Oh, yeah,
George Mulhearn: okay, Um. So it was touched on in the last Uh. Vcx meeting that Um, A big goal of Vcx is to sort of uh modularize the dependency on Vdr tools, and, you know, make it not so hard coupled with it.
George Mulhearn: Um, so that's the changes I've been working on recently um as part of some mobile uh agent work I've been doing, and a used case to use Vcx without using video tools without any Indie dependencies.
George Mulhearn: Um: So this is basically a diagram explaining the architecture of Vcx. Um currently, and how it works.
George Mulhearn: So you, as a consumer of Vcx um, you carry around uh via tools, while it handles and pull handles, and you also maintain and carry around uh all these handler objects. So connections and holders and provers
George Mulhearn: um representing uh the protocol that you're doing
George Mulhearn: um. And so basically how it'll work at the moment is um. You pass in your wallet and pull handles into the handlers,
George Mulhearn: and then they call on to the protocols uh under the Protocols Directory, and there's all the state machines for the different types of actors in these interactions.
George Mulhearn: Uh, and then eventually those Indie pull handles and what it handles get passed off to
George Mulhearn: um the Indie Directory,
George Mulhearn: and in the Indie Directory. There is, you know, lots of rappers over those video tools, methods, um, and also some functions which sort of aggregate together many different uh Indie functions to do to do different types of things all at once.
George Mulhearn: Um:
George Mulhearn: And yeah. So that's sort of how it depends on video tools at the moment. Um, mainly through the requirement to carry around, pull and and wallet handles and pass them in
George Mulhearn: um. So
George Mulhearn: what I've proposed and have been working on is uh basically the idea is, instead of carrying around um wallet and pull handles, you'll carry around a profile. And the idea of a profile is basically
George Mulhearn: a structure that holds all of your dependencies for the different types of
George Mulhearn: the different types of uh protocols that go on um so within a profile. You have a non-creds functionality uh ledger functionality and wallet functionality.
George Mulhearn: Um.
George Mulhearn: And so this is modeled after how acupy I have done it because they went through a similar period where they were coupled tightly with, uh the in the sdk,
George Mulhearn: and then to sort of separate out um that built this profile structure, and you're able to put in your own dependencies for each of these subsections. Um.
So
George Mulhearn: basically, when you're using uh an Indie Sdk version of this profile
George Mulhearn: um you'll carry around
George Mulhearn: and in the Sdk implementation of a non-creds in the Sdk implementation of ledger and in the sdk implementation of Wallet, and that houses all your functionality and then under each of these structs is um methods for all of the
George Mulhearn: uh a non-cred uh ledger interactions and world interactions that you need.
George Mulhearn: Um. And so my implementation of this just points back to the existing stuff that's within
George Mulhearn: um the Indie Directory.
George Mulhearn: So it points to all of those um rapper methods that have already been created.
George Mulhearn: Um! And then,
George Mulhearn: in addition to the default in the profile Um, I've built this modular wallet profile, and it's basically a different um
George Mulhearn: way of constructing this profile that doesn't depend on the in the sdk at all. Um! So that decouples you from vdr tools.
George Mulhearn: So for this implementation um, I have an Indie credits version of a non-creds in India and Dvdr version of ledger interactions, and a a pluggable wallet. So any wallet can be plugged into that, whether it's as
George Mulhearn: um, you know, some in memory thing for testing or even an Indie wallet can be plugged in.
George Mulhearn: Um. And so yeah, for the Indie Credits
George Mulhearn: Functionality of an on credit, of course, points to the Indie credits dependency.
George Mulhearn: Um and media points to Indie video, which is,
George Mulhearn: oh, sorry. So credit is a part of the Indie shared Rs. And this is a separate dependency.
George Mulhearn: Um! And as part of this work um, so as I mentioned, there's a lot of stuff in the Indie Directory. Um, it's mostly rappers over the Indie functions. Um, so you know, wraps it up with Vcx errors and other stuff.
George Mulhearn: Um, But there's also a lot of stuff, useful stuff which aggregates together multiple calls.
George Mulhearn: Um. So, for example, in the signing module
George Mulhearn: um, there's methods for assigning connection, response messages and things of that nature.
George Mulhearn: Um, which aren't, you know directly Indie related.
George Mulhearn: So for all of that um
George Mulhearn: none
George Mulhearn: non-specific indie stuff. I've moved this out to
George Mulhearn: another module um, so that it can be used with profiles rather than with wallets, and pull handles
George Mulhearn: um, and i'm yet to come up with a name for that.
George Mulhearn: Um.
George Mulhearn: So yeah, as the consumer, you'll now carry around a profile uh a profile trait um instead of your pool and wallet handles
George Mulhearn: um, and
George Mulhearn: to sort of illustrate the difference. Um! So this is
George Mulhearn: within uh the rust agent implementation, which is a rust agent that uses a
George Mulhearn: um. So this is the structure for the agent, so you know, Originally it would carry around a wallet handle and a pool handle. Um! But now, instead, it can carry around a profile. Um!
George Mulhearn: And why this has to be arc is still something i'm working on and figuring out, if it definitely has to be so just gloss over that for now.
George Mulhearn: Um! So that's what's stored in there
George Mulhearn: and then, you know, for the agents connection stuff.
George Mulhearn: Um, you know, when it wants to create an invitation
George Mulhearn: instead of calling connection with the wallet, handle. It just calls it with the profile instead.
George Mulhearn: Um, And you know lots of things like that, and similar for
George Mulhearn: um prover, for example,
George Mulhearn: uh prove us sending a proposal
George Mulhearn: rather than having to pass in an Indie handle and an Indie uh pull handle. You can pass in your profile instead,
George Mulhearn: and then, you know, this is going to use a non-creds and uh ledger
George Mulhearn: interactions under the hood. So you know, the profile will resolve its dependency for that, and
George Mulhearn: use its respective dependency at the moment. I have the agent pointing to just the in the Sdk profile. Um. But
George Mulhearn: the next step for me is to try pointing it out here and see if it's still
George Mulhearn: functions as expected.
George Mulhearn: Um,
George Mulhearn: yeah. So what's remaining is to put up the Ml. For that and get the community having to look at it.
George Mulhearn: Um, I still have some integration test to flesh out, and a lot of documentation. Um!
George Mulhearn: And I need to come up with a simple solution for handling all the breaking changes in the Lib. Vcx.
George Mulhearn: Um.
George Mulhearn: But I think I think we can come up with a simple solution for that. And then towards the future we can move towards a sophisticated thing where the Vcx consumers can construct their own profiles. However, they like
George Mulhearn: and things of that nature.
George Mulhearn: Yeah,
Patrik Stas: yeah, thank you. Thank you. Jar so much. Uh I. It's uh, just for maybe transparency. I already like we already have the session with George. Uh and uh, we're basically uh, you know, to present the same thing.
Patrik Stas: Uh. So I just wanted to, You know. I I invited George to prison in here in open uh, just to make sure that we operate, You know opera transparently, and this is obviously very like very well done. So as a as I said uh in proud i'm saying out here as well, uh, I think I I really like the idea. I think it's uh very well
Patrik Stas: uh thought through and kind of like, you know, really prepared. And all these diagrams also very nice. Uh: So yeah, really, really uh, awesome John George. Um. Happy that, you know we have this uh community efforts. Now. Um,
Patrik Stas: yeah. So uh, we we have Uh, we have, uh requested for you, George, and the Uh. Contribution, like Ais v. Six, contribute to role to repository. So uh, whenever you have moment. Just it. It will be great if you open Pr. There, so we can, you know, check those changes and kind of
Patrik Stas: keep keeping track uh, like, you know. Possible uh possible uh conflicts in the code. So maybe we can like keep, you know. Kind of uh keep it in kind of consider it when we do some changes considered uh your delta, which is as open, important
Patrik Stas: Uh: open. Pr:
George Mulhearn: Yeah, Yeah. The The Delta is getting pretty pretty big on this one. Um: But yeah, yeah. So yeah, I've been working on my own, for in my own branch. But I need to move that um
George Mulhearn: into hyper ledger as well on my own branch there.
George Mulhearn: But yeah, it sounds like um
George Mulhearn: uh the changes to the Ffi layering won't affect me too much. Uh It seems like like the interfaces for the Indie functions. Haven't changed. Really, It's just what's happening inside, you know, using controllers and types.
George Mulhearn: So I think I should be good at that.
Patrik Stas: Yeah, yeah, uh, maybe one uh you. I think you might currently, if you were based on the latest master. You may. I think you will run into conflicts on my whole, on a holder like state machines. Uh, I don't know how much changes you had to done there, but there's been some a reorganization and restructuring function. It's one of the pull request we we merge last week, where originally we had this,
Patrik Stas: we have we used to uh up up until last week we had this very different sort of approach in the connection State machine and all the other State machine where connection, state machine was kind of nicely uh split it out into either individual methods, whereas
Patrik Stas: implementations of State machines for holder, issue, or verifier and prover uh, they typically have this like one giant uh function called handle message, or something like that step function,
Patrik Stas: and uh, and it's it's just perform some action based on
Patrik Stas: past in enumeration. So this has been split into uh, you know, individual small functions which are the the the handle message functions still exist, but it is calling smaller function now small function. So I think you you you will have some conflicts there. So
Patrik Stas: uh sorry. On On the other hand, this is like This is like long overdue, where, uh, as a technical, that from the past which we finally kind of paid off, and it, the code looks much much nicer and much more readable. It sounds like a good change.
Patrik Stas: Yeah. Props to
Patrik Stas: fighting through these. Okay, uh. So moving on to the next pieces in agenda. Uh, i'll share my screen again.
Patrik Stas: I figured out how to do it. Uh, I've been using zoom for a while. So um
Patrik Stas: uh yeah, We have create that. Uh
Patrik Stas: come on board uh on my Github projects. So if you go to I navigated navy navigated directly from the repo, so you open the repository, and you go to our idea projects.
Patrik Stas: Uh, there's only one there is Vcx, and we have this come on board. Basically it's a reflect, as in the current state. It is reflecting the list of issues we have, uh, where we previously been tracking the work. So
Patrik Stas: uh, now we kind of fast put it out in this uh a bunch of columns, and uh,
Patrik Stas: I don't know. Maybe we can figure out what what those calls should be named for. Now, the way I organize this.
Patrik Stas: I put sort of higher priority, or like things we want to do in a closer future into to do,
Patrik Stas: and things just to keep in mind, uh for the later future into the backlog uh column.
Patrik Stas: Um,
Patrik Stas: So I think these actual links uh well,
Patrik Stas: um
Patrik Stas: to the next piece on agenda, which is the upcoming work. Uh, so I think if uh, too many tax open
Patrik Stas: uh So one of the most uh important pieces, I think, uh, in upcoming future,
Patrik Stas: uh which we mentioned last week as well, is the implementation of non-mediated connection, handle and load mediated public agent as right. Now, if you want to use, you know, If you want to establish connection with Ariz Vcx, you are essentially forced to deploy Dcx agency notes, maybe it, or somewhere
Patrik Stas: uh in order for as V. Six to function. So we want to uh remove this limitation uh basically want to still enable uh, whoever wants to use to let him use uh the existing connection with mediator. But, uh,
Patrik Stas: we want to outlook the possibility of, you know, having connection which is just. Stand alone without mediation and let it up to the the every six, user the developer uh to decide.
George Mulhearn: Do I have an approach in mind for that? Or is it saying, you guys still thinking about.
Patrik Stas: Uh, yeah, it's uh.
Patrik Stas: There's like few questions coming up like I try to.
Patrik Stas: I try to draft out the like this work before. Uh,
Patrik Stas: and I run into like few questions.
Patrik Stas: Uh, for example,
Patrik Stas: uh, right now, we implement collection
Patrik Stas: protocol um, And but arguably in the future we want to implement did exchange protocol, which is like the next generation. Uh, and then the question is like, should both of these protocols be like under
Patrik Stas: the same handle connection, handler and a user would somehow choose which of them he wants to use,
Patrik Stas: and it will share the same connection. Interface, or should it be like two different handlers.
Patrik Stas: Uh. And the reason why I'm saying is because it is gonna be like two different handlers.
Patrik Stas: Uh then I think there there there might be lots of duplication uh like in both cases. Arguably, you can choose or choose not to.
Patrik Stas: Uh used a mediator. And um,
Patrik Stas: yeah, it's just the question like how to structure it, Should we, you know, or should we,
Patrik Stas: how to structure like connection, and did exchange for a calls in the future? Should it be under the same kind of roof or separate? And then, uh,
Patrik Stas: basically also, same
Patrik Stas: kind of question comes up with just removal of the mediator itself. So shall we just make the current connection handler smarter in a sense that
Patrik Stas: you would somehow opt in or opt out to use the mediator. But it would be one interface as it is now,
Patrik Stas: or should it? Should we have like different handler for these two different cases, like something like connection as exist today, and some let's call it non mediated connection, handle and have them, you know, as a siblings uh
Patrik Stas: next to each other. But then, again, the if you have it separate uh, It's nice, because you can have different Api's. Obviously the non-medated connection. We don't have functions like download messages,
Patrik Stas: which is something you want with the mediated connection.
Patrik Stas: But then, if you start to think, okay, but in the future we want to add the Did Exchange. Then are we gonna have four of these handlers for each variation. Or are we gonna put it? You know, underneath them
Patrik Stas: it just yeah. So this is kind of the kind of questions which are popping up in, and you know, when we, when we think about it, I think, or at least for me, the things that are unclear, but one way or another we we definitely want to, you know. Uh,
Patrik Stas: remove the dependencies.
George Mulhearn: Am I? Am I right in thinking that you can almost use it in a non mediated mode at the moment, like if you're passing in the message yourself to specific methods. Um, you know, rather than doing. Find and handle message you do just to handle message.
Patrik Stas: Um. So
Patrik Stas: in case of like
Patrik Stas: is um
Patrik Stas: any case of issuance protocol, or, you know, proved verification for the call. They don't know about connections, so in in their case you can have it without an aviation, because they're unaware. But then connection protocol. There is
Patrik Stas: The code directly, you know, is in some cases interacting with that
Patrik Stas: agency.
Patrik Stas: Uh, and it is creating, you know, when you create a connection object, it Uh, it calls the agency to create sort of like uh
Patrik Stas: account there. Yeah. Uh. So with connection protocol connection, handler as it is today, you you have to uh have
Patrik Stas: the mediator deployed.
Hmm.
@kukgini: I wonder if this feature also had the return route thing uh
@kukgini: return route Decorator
Patrik Stas: uh Sorry, Which Which decorator
@kukgini: uh recon route to to return route.
@kukgini: Yeah, there is. An for that.
Patrik Stas: Yeah, I I am not aware of this this one. So uh
Patrik Stas: oh, I don't think we have that
@kukgini: yeah transport to to around. Yeah,
@kukgini: uh Rsc: zero zero nine, two
Patrik Stas: uh zero zero
@kukgini: to First Link,
@kukgini: He said that when on uh a message. They have a case
@kukgini: transport decorator.
@kukgini: The uh
@kukgini: counterparty agent returns the response directly at the response.
Patrik Stas: Oh, yeah, we don't implement this,
Patrik Stas: but uh, we can take a look into this, and i'm I don't really know much about it. So
Patrik Stas: uh i'll take a look. Um, but uh, yeah, I mean any uh, Apparently it's
Patrik Stas: It's a fairly old Rfc. Probably matured, so it's certainly something we can consider implementing or uh can be contributed. Uh, I just not sure right now how it sort of links uh,
Patrik Stas: you know, with the changes we are planning for, how to just kind of concept conceptualize and how to put it together. But, uh, i'll take a look at this, and uh, I don't know. Maybe we next week we can discuss it.
Patrik Stas: Is it? Is this something? What's important for uh your use. Case?
@kukgini: Uh, yes, it is in my country. We they mediator is very uh
@kukgini: yeah,
@kukgini: hard to keep the
@kukgini: uh in
@kukgini: personal information.
@kukgini: Uh
@kukgini: because of our relations regulation.
@kukgini: So
@kukgini: we are trying to remove the mediator and
@kukgini: don't use it at all.
Patrik Stas: Mhm Mhm
@kukgini: Yeah, yeah, yeah,
Patrik Stas: okay, I'll: i'll. We. We can put this on agenda for the next week. Just kind of discuss with you.
Patrik Stas: I'll definitely have a loop myself.
Patrik Stas: Um, Thank you.
Oh, well, So yeah, this is the connection where we are planning. Uh:
Patrik Stas: uh, yeah, then, this this space I was thinking, since most of our uh like uh users, uh, are we working on Mobile? I would like to put together some like a guide, a short guide of like
Patrik Stas: uh, maybe recommendations, or how to approach mobile with Uh Vcx is. We do have some experience with mobile uh like Mobile on top of everything we see ourselves, and just, I guess, to flesh it out uh like very briefly. Um
Patrik Stas: don't use uh update state um as far as possible. It's the kind of uh pattern we want to get rid of, because
Patrik Stas: uh the update state uh methods. They are very convenient, because,
Patrik Stas: um,
Patrik Stas: you know, they they progress. The The product calls forward, and that's what you want. But problem is, you have very little uh like idea and control about,
Patrik Stas: You know, all these really happening, and into what kind of state we have progressed. Typically, you want to
Patrik Stas: you, you as a like
Patrik Stas: in in the role of the mobile device. You receive a message, or we dial all the message from from an agency. We want to take a look at what kind of message it is.
Patrik Stas: Then right. You need to resolve the right object, the right connection or the right credential, and basically just use the message to update the protocol. Um, what's uh what we did like long time ago, when we're starting out
Patrik Stas: uh is that we don't, we we, we, we, we we would receive a notification, for example, uh that uh
Patrik Stas: a message, for you know a message has arrived, and then we will maybe identify which which credential object this message relates to, and we would call update State
Patrik Stas: and the update States. Then we download the message from the mediator, and then do all the magic itself. It progresses. The State maybe replies to a message. But uh, in general, this is this is like this: turn to the uh like an anti-p pattern, because it just
Patrik Stas: doesn't really give you a good control and sense of what is happening. Uh. So we just much better approach to
Patrik Stas: come up with, and like very clear step like you don't want the message you you resolve the particular object which the message relates to. Then you just called update. Stay with message, or you know, or or make some this transition.
Patrik Stas: Uh,
Patrik Stas: and you can check the resolve.
Patrik Stas: So this is the I think this is like the core piece like core, The main idea which which I wanted to get out uh kind of uh just make sure that everybody is aware of it, and probably hopefully, you know, won't fall into the same uh mistake as we did uh,
Patrik Stas: and I just to be aware that in general we want to probably get rid of this generic update stadium. I think, uh update state methods which are currently implemented on that.
Patrik Stas: Uh, I think all of the all of the objects, at least on the
Patrik Stas: um
Patrik Stas: well, and then so so I won't. Write this down, maybe as a as a as a guide on a week, or maybe somewhere to the repo something like that put it into a text.
Patrik Stas: Uh and lastly, um, we had some
Patrik Stas: uh there starts to be some discussions about uh
Patrik Stas: the Id document a resolution uh on a sovereign ledger using a
Patrik Stas: uh, so
Patrik Stas: for that i'll open this issue. We have here.
Patrik Stas: Um
Patrik Stas: has been some discussion
Patrik Stas: opening up.
Patrik Stas: Uh, this is not this issue Six hundred and nine
Patrik Stas: uh so just to uh kind of give you a background. Um,
Patrik Stas: the way we write. Um,
Patrik Stas: you know. Uh in in in the role of uh public institution, the the public public institution typically typically wants to write their service endpoint on the ledger and uh, all the necessary keys
Patrik Stas: uh to interact, you know, to to interact with that endpoint as as as far as uh how to encrypt messages being sent to the endpoint. So the way uh we write this into information right now on the ledger. If you use a
Patrik Stas: in the role of institution. Uh, we sent at three transaction, and basically that a trip transaction, you know, rights uh following, you know, like attribute
Patrik Stas: for following payload as a attribute of the Id, and then um. So we So we write separately with spin keys, routing keys, service endpoint.
Patrik Stas: Uh, these are like, typically what is, you know, this is typically included in uh,
Patrik Stas: like uh connection invitations. But
Patrik Stas: in case that institution
Patrik Stas: simply wants to give you a did. Then it's up to the the device or the the the recipients to resolve that did into the dog, and that's the dog should include, You know, this sort of information. Uh:
Patrik Stas: So this is the way we write it right now. The problem is um, that uh, the specification which came out in uh
Patrik Stas: February this year. Uh for sovereigned method. Uh, it's specified the format somewhat different.
Patrik Stas: Um!
Patrik Stas: So they also have routing keys uh that will be shared. They have endpoint. There's a formatting differences, obviously, as you can see, but another formatting itself that's like, uh, more or less minor thing.
Patrik Stas: Uh
Patrik Stas: so. But but it's still something we need to address, and that's why this Pr. Exist. So the first thing is just kind of align in terms of formatting. Uh, because this is the type of thing which uh
Patrik Stas: so, for example, Aka, I would write on the ledger, and you know ours. V. Six will then right now be able to
Patrik Stas: understands uh this. You know the the format which occupies right? So obviously we want to uh fix that uh, then, the second kind of problem which we kind of got into into into this uh ladder uh comments. Here,
Patrik Stas: uh is that as team of Gloucester dimensions here? Um
Patrik Stas: in um.
Patrik Stas: In case of like other implementations, they usually assume that,
Patrik Stas: uh, the recipient keys
Patrik Stas: is not part of the attributes itself, but they just assume that the attribute key is always the very key assigns to the did on the ledger.
Patrik Stas: Uh, which is not our case where we write out the recipient key separately into the attribute, and therefore we allow, like we assume, that the the ver key of a did on the ledger can be something else.
Patrik Stas: Then the recipient where maybe the you know public institution wants to receive the messages.
Patrik Stas: Um:
Patrik Stas: So yeah, this is ongoing discussion. Uh, uh, obviously, we want to definitely align with the
Patrik Stas: to improve the interoperability.
Patrik Stas: Um, especially from the role of mobile device. At the same time, we probably, uh like want to keep, you know, back parts compatibility with the let's say with, Let's call it like our legacy format.
Patrik Stas: Uh: So yeah, we want to support both. But uh, probably in the long term, you know, we want to obviously align with the the rest of the community.
Patrik Stas: Uh: as much as possible.
Patrik Stas: Yeah, uh, I guess this is uh sort of if
Patrik Stas: uh for for this issue. And actually, I think I I
Patrik Stas: We went through uh the agenda. So it's now time for any. Is we have ten minutes left. So there's anything to ask for discuss
Patrik Stas: whether it's something uh, you know. I I talked about the planning plan work, or uh what there were other concerns or ideas you have.
Patrik Stas: Uh,
Patrik Stas: It's a free space. Now.
ckowald: Um,
ckowald: Patrick, I was a little bit confused with that last topic you were talking about.
Patrik Stas: Um, Okay, it must have been I'm fairly new. I'm. Fairly new to all of this. But
ckowald: it are you saying that what you write to the legend now is in a
ckowald: on. Are you saying it's out of sync with what sovereign one?
Patrik Stas: Uh: Well, yeah, so it yeah, it is. It is because um what we would be right, you know, if you use as Vcx to write your like. This kind of service attributes on the ledger.
Patrik Stas: Um!
Patrik Stas: It's some of the different
Patrik Stas: uh. It's not a big problem, because it's easy. It's It's easy to fix, but it is currently different,
Patrik Stas: and i'll show you
Patrik Stas: exactly
in practice.
Patrik Stas: So if I look for the attribute transactions
Patrik Stas: uh, this is a tribute uh written by A. Dcx. And as you can see uh, this is what we've right.
Patrik Stas: Uh so there is
Patrik Stas: I can be, for you know It's It's what I displayed on uh
Patrik Stas: on the
Patrik Stas: right, and you're saying that's not quite aligned with what sovereigns say you should write. Yes, because in in other let's say this a random one. Let's see how they write it. So
Patrik Stas: So this is how I oftentimes other implementation righted. Uh.
Patrik Stas: So there's this rear. It's kind of a strange uh yeah uh, but that's just how I I define it. Specified it, I think,
Patrik Stas: probably for some historical reasons. But it is what this. So uh, it starts with endpoint, and then within that is endpoint, and I need to open up it,
hey? Sure,
Patrik Stas: um!
ckowald: But this will probably change again, I think, because that's that. Looks like It's related to
ckowald: um. You know how how a service endpoint is declared,
ckowald: and I'm:
Patrik Stas: Yeah. Well, it is in in the in this. So it it is draft. So I believe it can still change uh over time. I don't know how stable this is.
Patrik Stas: Uh:
Patrik Stas: I look for a service endpoint here
Patrik Stas: uh this is. This is:
Patrik Stas: Let's see. Okay. So yeah, So here it is. So in this specification. They say that you should write
Patrik Stas: a trip transaction with this uh endpoint recurs twice, and then within the inner endpoint.
Patrik Stas: Uh, you know, in within the inner object you can specify the endpoint field with the actual Url uh, then types and uh routing keys.
Patrik Stas: Yeah, which is not exactly, you know, in this case. Uh, in this particular transaction this is aligned with with the sovereign draft, because it is endpoint endpoint, and the other free. Other fields are optional, so they didn't specify the here,
Patrik Stas: whereas in you know the way Aries, Vcx Institution would would write some. I don't know endpoint on the ledger. Is that good? Rise this much bigger they will there, uh, which includes recipient teams
Patrik Stas: uh the routing keys and service endpoint. And yeah, one. One difference is in the formatting itself, and then the second difference is, uh
Patrik Stas: kind of more important is the fact that we write recipient kids on the ledger, whereas, according to the specification, you cannot write or like they they don't mention it
Patrik Stas: uh,
Patrik Stas: so they just assume that, uh the specification assumes that the recipient piece value, you know, when you resolve
Patrik Stas: um,
Patrik Stas: you know, when you, when you try to contact the the institution on the service endpoint.
Patrik Stas: Uh you should simply use ver key of the given did
Patrik Stas: uh as a recipient key. So in in this particular case, if I take a look, what is the I, what is
Patrik Stas: of these of these did? C. Twenty-seven.
Patrik Stas: Um,
Patrik Stas: uh, there will be this one.
Patrik Stas: So
Patrik Stas: um
Patrik Stas: yeah, what? Where? Whereas we you know with everything we write that explicitly. The sovereign uh specification
Patrik Stas: uh assumes that you should just take that recipient from here as that as the main bar of the did.
Patrik Stas: Does it make somewhat uh clear?
Patrik Stas: Well done. What the issue is?
George Mulhearn: I think I think Craig's Internet. Died, but I I can pass it on to him. It. It makes sense to me that. Um:
George Mulhearn: Yeah.
George Mulhearn: So it it sort of has to do with you guys needing to restructure that area service Struct
Patrik Stas: Um, two different ones to support the legacy version as well
Patrik Stas: um
Patrik Stas: into this. So uh, basically this just moves here, right uh the types uh that something to look into the routing piece Uh, that's a simple one. Uh, that's It's actually the same.
Patrik Stas: Uh he goes here and uh
Patrik Stas: kind of the biggest issue in terms of in like compatibility. Uh would be the recipient keys. So uh it will be, you know we have to right adjust the code
Patrik Stas: such that
Patrik Stas: especially well, especially, for in the role of the mobile client uh mobile device which is resolving some did we have to assume that the stuff on the ledger is written in this format,
Patrik Stas: and there is no recipient he's written uh in that attribute transaction, and it's simple this and then uh for and then I think
Patrik Stas: for some period of time we'll implement kind of uh backwards compatibility uh extension
Patrik Stas: such that uh, we will try to.
Patrik Stas: We will try to also um resolve recipients from the attribute. But since nobody is really doing it this way,
Patrik Stas: if it's missing there, which will be, in cases of you know, most into institutions or most agents use occupy the recipient keys uh won't be here
Patrik Stas: uh so a is, we say it's have to assume that it won't be here So in that case, uh, like
Patrik Stas: the recipient, is that the recipient is value. I think the way we implement we will implement it is first
Patrik Stas: try to look if there is
Patrik Stas: um
Patrik Stas: in the
Patrik Stas: part of
Patrik Stas: a transaction,
Patrik Stas: and as a fall back to, you know, to the mos of the because this is to support like the legacy we have right now, and the second step will be like, Okay, if there is spin keys, is not there
Patrik Stas: Probably, uh this. This attribute to transaction was written by Aka, by which does not uh specify recipient is an attribute, and in that
Patrik Stas: that case will simply uh resolve. You know, res resolve a very key for the bins, and we pulled it as a
Patrik Stas: Yeah,
George Mulhearn: we We resolve that as as a
Patrik Stas: yeah, yeah, yeah, so well uh, just to ever any confusion. Basically This is how the thing will at the end look like, you know, in Arizona internally. But uh, yeah, obviously,
Patrik Stas: um, this is what's gonna be on the ledger. And yeah, we have to. We have to it just the code to assume that this is this is what the ledger looks like, and it's probably not this. But we will want to support this for a while.
George Mulhearn: Awesome,
Patrik Stas: all right, uh, I think we uh ran out of time. So
Patrik Stas: uh, I think we can close it up. Um, thanks. Everyone for attending um, and i'll be looking again to meet meet you guys uh hopefully next week.
George Mulhearn: Great. Thank you.
@kukgini: Okay, Thank you.