 Hello, everybody. Hi, everyone. Hi, Dimo. How are you? Good. How are you doing? I'm fine, thank you. I hope my connectivity issues did let me continue. Does Hyperledger has a new logo? Yes. If you go to the website, you will see that there is a rebranding there. Pretty nice. Ah, nice. Cool. Looks good. All right, I think we can get started. All right, log number one to the AFJ weekly, biweekly working group call. I need to remember you to abide by the Hyperledger code of conduct and the antitrust policy. If you would like to add yourself to the tennis list, feel free to do so. I've posted the media link in the chat. Is there anyone new here today that would like to introduce themselves? Hey, everyone. I'm Zdravko. I'm technically at the RIN. You might think our CEO picked you a bunch of times via the email and personal and some conference. Here together with my co-worker Alex Wunin, we are specifically interested in deep conversion to implementation in AFJ. And that's why we are here to look how we can help you guys to finish this picture. Oh, sounds good. I added it to the agenda for today. Welcome. All right. So any status updates about any of the calls that happened or other updates people would like to share? Yeah, I've added to the wiki page some notes I took from the meeting or from what I heard from the new meetings this week. I heard that, for instance, Bifol suspended the meetings this September because they had a very low attendance. So not just from there. From Aries Call. Well, I think that the link is not correct, but yesterday they were talking about what we were talking about mostly about the unqualified dates migration. So yeah, which is a topic that I've added for the agenda for today, so maybe we can discuss about it later. But in short, the most interesting thing is that Sam showed a proposal to discover the deep peer tree support by using discover features. And then we had the classical discussion. Should we talk about this here in Aries? Or should we go to deepcom.org? Oh, so I think that Sam will present this to the deepcom.org, to the deepcom user group. Because it would be nice to have, you know that in discover features we have the concept of feature types. So it would be nice to have a place where we can consult about existing feature types. So we can use it in our protocols. So I think the outcome from this discussion was that we will try to find some place on the deepcom website to add not only protocols, but also this kind of things. And also, for instance, for this discover feature, for the deep peer could be useful not only for the peer, but also to discover any deep method that the other agent can support. So that could be also useful for that. Yeah, sounds good. Nice, yeah. I think it would be useful to have a registry of discover feature types, because I think it could also be useful to share which of the credential formats, exchanges you support. Like besides just I support issue credential V2, but it kind of matters of which of the underlying attachment formats you support. Yeah. OK, cool. Yeah, and then I added a small note about the AnonCreds, because in the AnonCreds arrest, Akif is doing a, has done some work for the upgrade to, I mean, to get rid from Ursa and go to the new AnonCreds CL Signatures Library. As you can see, Akif is here. I kindly ask you to review it so it can be merged. And because it will be nice for us, it will be nice as well, because we will like to have it released before merging the revocable credential issuance PR we have since April. Yeah. So I've updated the JavaScript wrappers, I believe. The tests seem to be passing for that. So yeah, I just wanted to get some feedback from the community before we move forward. But it looks like the tests are all passing for the Python wrappers, as well as the JavaScript wrappers and the library itself. So OK, yeah, I can take a look at the JavaScript stuff, but the Rust stuff, not so much. I added a review request to let Berend take a look at it. Yeah, so then we can get that merged. Yeah, OK. Nice work. And is this a breaking change in the AnonCreds or as library or is the public API the same? And is it just like underlying stuff? It might be a breaking change, because some of the methods have removed some of the parameters. So yeah, I think we'll have to. Well, it'll be constituted as a breaking change, I think. Yeah, and only to the API or also to any of the data format or like the things that we store. No, none of the data formats is really just the API. OK. Yeah. Yeah, I think that the main difference from the API perspective is that we don't have to send details file when issuing or revoking credentials if this is a good thing to have. Yeah. OK, awesome. Any other status updates? Cool. Then for the agenda, I think you added these two, right, Ariel? Yes, yes, yes. And this one is left over from last time of, or? Yeah, but maybe, yeah, I haven't modified it, but because as it is talking about the new release, maybe we can have some discussion about what, when, where to doing the next release for AF check. Yeah. I have seen that you added a discussion about what to, I mean, in GitHub, you added a discussion about what to have to for 050, so maybe you will have some time. Yeah. Sounds good. Let me see, I can. Did somebody unmute or what did they say something? Yeah, I was just waiting for you to kind of get the thing you put in that you were doing. Yeah, so one other thing that came up in the ARIES working group call yesterday was related to the post that you did regarding where your animal was planning to go with AFJ in regards to the support for the European standards and the like. And I think there was a consensus or at least an interest in having kind of a larger community discussion about whether that should be like a strategic direction for all of the ARIES projects. So it sounds like your post had an effect to swift kicks to a hornet's nest. And people are starting to say, oh, maybe we should be thinking about that. So that's another thing that came up. Cool. Oh, that's good to hear. Yeah. Seems to be a lot of interest to have more support for EU standards. But that's good to hear. I can add a link here for people that are interested. Let me see. I think it's here. Yeah. So what we're trying to do is basically making extended AFJ with support for all the EU and ARF standards, which then in addition to Anumkretz, it will have full support for open ID, also for issuance. We'll add support for MDL credentials. And basically, well, it will then support all exchange protocols and credential formats. And it will really be more of like a toolbox for any SSI solution you want to build. Cool. I've seen there was a very good table stating what is supported, what is not. That is something. I mean, where does AFJ stand right now in terms of support for that? Yeah. There's a hack and be, I think. Yeah. I can share that here. I think let me quickly separate from like it's more as like in the taking stock of like, where are we right now with the framework? OK. I would need to look into that. But if I have, I'll share it in the in the in the Discord so you can get an overview of like, where are we right now? Cool. Any other updates? Oh, no, we were already done with the updates. We were at the agenda. OK. Then let's do you want to kick it off or are there any other? So lost my rhythm here. Are there any other things we need to add to the agenda? So we have these two from Arielle. We wanted to discuss this Comfy 2 with the Ferrine team and I saw Artem is also on the call. And if we have time left, we can look at beyond stuff. But any other important things we want to discuss? Cool. OK. Do you want to share Arielle or? No, well, actually, it's everything. Everything is there in those links because I'm referencing where where this topic came from. So the idea, you know, I guess this has been discussed in the last meetings as well. But the idea is that we as a community need to migrate from unqualified deeds to qualified deeds. Right? I mean, so I'm talking in general. I mean, in areas committed in general. So the goal is to in a magic date, as Steven said to me, we all need to start supporting the peer version 3. For that, we need version 2 as well, which is something that we already support here in shape. But as far as I know, it's not supported right now by ACAPI. But the problem with this strategy that was proposed by in the RFC in that one, I don't know if you can show it. Yeah, that one. No, yeah. My understanding is that it assumes that we that everybody supports either unqualified deeds or I mean, it doesn't take into account that we are using the peer one in AFC right now because there are there are a few steps where they say, OK, we have to support. First, we have to support both unqualified and the new transition form. OK, and later we have an intermediate step. And finally, we will deprecate the unqualified and so on. But my concern when trying to figure out how to implement it in AFC is that maybe I am wrong. I hope and I'm glad that you, Timo and Jaco are here because you are the one who implemented the connections and the exchange protocol here. Is that we are using unqualified deeds for connection protocol and we are using the peer one for this exchange. Is that correct? Yeah, that is correct. But we transform the unqualified did to a did peer one did as well. And we still store also the unqualified did, but that's as a metadata to the did document that we have stored. So internally, we only use qualified did peer one did and yeah. So we don't have to deal with legacy dids anymore besides in the connection protocol implementation. OK, but for instance, if we are trying to, if we want to connect using the exchange with ACAPI, we cannot right now. No, but I think that's an issue of ACAPI because the did exchange protocol has never supported unqualified dids. OK, so yeah, I think our strategy, what would our intermediate strategy be? For instance, maybe we can show my notes in, by the way, in the I added this link to the to the pull request that Stevens made, they added the three peer processing resolution. Yeah, that one, because they will like you to review or to merge it so they can add the resulting repo to the RFC as an attachment or something like that. So just just to remind you if you can, if you can check it as well. Yeah, I think we want to add it to the RFC, right? But we probably want to to merge it. Yeah, exactly. OK, yeah. So yeah, about the strategy, so the for this first step where we want to support every kind of connections. Well, for the exchange, we are we are not going to support unqualified dids, right? For the exchange, so we will keep it supporting only the peer one and two and well, we will need to add support for the three and we will respond using the same peer that we received. Yeah. I did a first check and it's it seems that it shouldn't be so complicated to add to to to support the peer two. And in the exchange, it's just a matter of adding some because at the moment, at the moment, it only if you are using a peer two for the exchange with AFC, it will reject it because it only allows in exchange protocol to use the one. The reason why that was done at the time is that we have also had discussions in the Earth Working Group call is that the did exchange protocol describes only how like describes that you need to if you change your key from the invitation to the response message, you should sign the response with the key that was used in the invitation. And what you need to sign is you need to sign the did document attachment. But if you use a did that uses the did document in the identifier itself, you don't really have an attachment. So I think that's where we left with the implementation left less time on why did pair two was an issue. So I don't know if there is a solution for that already or No, I don't know. I don't know. You see there. Let me see there. I think I could open to an issue about it at the time. Yeah, so this is the issue. If it is resolvable in an inline peer data, the did or attached at which should not be included. So signatures were never needed in a request, but it has to be included in the response for that. So I think we need a solution for this. I think we can probably make a very small like addition to the did exchange protocol that mentions if you want to do a resolvable did, how you can sign what you need to sign. I think that that is probably like the easiest to do here or not. Right. I think for the rest, it's probably, yeah, should be quite straightforward to support it, too. Right. Yeah, yeah, yeah, it's I did a quick test yesterday and well, there are a few things to tweak, but yeah, of course, it's not something for the exchange. You see, you know that it's for the exchange. It's okay. But then of course, we will it's completely unassailable if we are going to use always the peer to different exchanges. But yeah, in this case that we are using it can be one is not it's not a big problem. So yeah, so by the way, do you know how other frameworks handle this? I mean, for instance, the Go framework, what does it do in terms of the peer support or the exchange? Because I know that they managed to make it work with a buy in this harness, but I don't know how. Yeah, they support data exchange with this pair one and they made like hacks to make it work with a copy and had like custom startup flags, like for a copy interop, which would have different behavior. So yeah, I think there are still issues open in Occupy to fix that. Okay. Yeah. So yeah, so when doing a data exchange, when we do the the request, we include our DAV. So if we are going to, if we want to have support for or I mean, if we want to be able to interact with any existing implementation, suppose we are, we are, we want to to interact with a with an AFCA030 or 040, we should probably use the peer one for the exchange request, right? And then we can ask the discover features if the other party supports the peer two or so. Well, it's true that we did come be one. If we already did this, the connection we don't need to use the peer anymore, but so, but we somewhere we should have a flag or something that that will say what's the default the peer, the peer flavor we are going to use for these exchanges, which by default will be one at the start, but then can can be updated to two or three in later stages of this strategy. Yeah, okay, that makes sense. Or like we don't have to define it per se by default, right? Because if you make the out of band invitation with an inline service, we could just look at what the request is. And if the request is a did pair one, we will make the response of the pair one. And if the request is a did pair two, we will make the response of the pair two, for example. Yeah, that that's the first part of my my step one, if you see the problem is if we are going to if we are the ones who do the exchange request, yeah, yeah, I mean, if we are responding for an invitation, that I thought also in doing something more, I think it's somewhere, I don't know if I write it, but we can also do a kind of of fallback. I mean, we can we can try first with the peer two and if it's rejected, we go to peer one or something like that, something similar to the to the discovery that you did for for the remediation protocol, you remember. Yeah, maybe we can do something like that for the meantime. It's not ideal, but we can ensure that we we are going to to be able to connect with any agent. Yeah, that makes sense. And yeah, OK, let's let's hope that that everybody has implemented properly the the the the the exchange errors. I think it's for for AFA it's it's fine. Yeah, for for a Kappa as well, because I when I I did a test this week to connect through the exchange and and and the API properly reject the exchange with the program report with the proper error code. So it should be fine. OK, yeah. Yeah. And another questions I had as well is that about the I think it's also a question you raised in the RFC about the connection protocol. We are going to leave it as it is right now. I mean, we are going to to update it as well to use the peer or we are just leaving it as using unqualified and that's it. Yeah, I think in my. How I first understood it when we started this whole thing of like it was really a migration of ditch from unqualified to qualified and not making it a change to any protocols. So that if you use did exchange, you can just use did pair three or two, if you want, like with this change needed. But for connection that we still use unqualified dids, because I think changing the connection protocol is like I would rather not touch that implementation anymore and just have it be for backwards compatibility and that we just after we create a connection, like we already transform it to a did peer one did. Now we just do that same transformation, but to a did peer two slash did peer three. So I would rather not touch the connection protocol implementation. OK, yes. So what do you think? So yeah, yeah, yeah, yeah, yeah. So in terms of protocols, the only thing we should make sure in AFC is that we do support the did peer two. In in the exchange and the peer three as well. Yeah. Yeah. And I think I'm still not really a fan of did peer three because it means there's two dids for the same did. Well, I think did peer one solved the issue quite well, like you have a short identifier for a did document. So then I think because then we will need to have something where both dids will resolve to the same to the same documents. I mean, we can probably implement some hacks for it. But yeah. Yeah, I know what you mean. Maybe we can add a tag or something like that. We can find by I don't query and get it. Yeah, yeah, because then like we have a connection record, which is one of these two dids. So we would need to have like a higher level implementation that knows that needs logic for specific did methods, which is like not very you see that I made a note there as well. Connection record will probably need to have a field where the did for exchange will be defined something like that. Yeah, where is that? Oh, yeah, here. Yeah. Yeah, something. Hockey like that. Yeah. Or hey, you guys have a question. In practical terms, can you can you just help clarify what the case is we're using did exchange versus out of ban connection? Because looking at reading through the RC, it seems like out of ban is kind of like the latest and greatest and did exchange would be superseded? No, so connection protocol is superseded and out of band is for creating invitations and you can use that with the exchange or the connection protocol. So out of band is just for the invitation. So bootstrapping the exchange and then you can switch into either the connection or the did exchange protocol if you want to make a connection. So this is really for this migration is for old connections that didn't use the exchange protocol yet and still have unqualified identifiers and also making the interoperability between errors, implementations and did peer and did exchange better. Yeah, maybe a maybe a clarification is that this is every all these protocols are for the conversion one. In the conversion to you still have this the out of ban invitations, but we but you are not using the did exchange because it's not needed for it come with you. Maybe that's what you were referring to. That makes sense. Thank you that clarifies it. OK, I would like to also still get to a bit of the other topics. Do we have a good strategy for AFJ with this or are there any outstanding topics, Ariel? I think it's your explanation clarifies a lot of things to me. So let's hope that I can I can do an implementation with that without any major issues. But but but yeah, we can discuss it later. OK, cool. Thanks for bringing this together. That's helpful. Cool, then the plug fast. Yeah, this I think this will be a short one because for the plug fast that will be held in October. Well, actually, it's it's already running, but but the demo will be run in October. We the idea is to to be able to do to receive some credentials in and do some presentations, right? This is more or less in short what what we should show. I mean, different wallet implementers have to demonstrate interoperability using different credential formats and transfer mechanisms and protocols. So basically, in terms of protocols, we have three options. We have the did come. We have a busy API and the open ID connect. Yeah, the for busy API and open ID connect. It seems like there are no major issues. But for the come, we couldn't find. And a standard way or I couldn't find at least any. Any consensus. About what to use if we are going to use it can be one be two. I tried I made some I wrote some emails and also discussed in. Open the discussion on the slack channel for the plug fast, but nobody answered. So it seems like probably probably. There will be no did come. Tests for for the back fest, but in but in any case, I think that the. For what I have and allies from other parties that support did come other than animal and us. They are using the computer. So and I saw it makes sense because the computer is the wider approach. So in that case, in that case, we will need if we want to to create an end point or something to. To issue and present credentials using it come. I think we will need to add the support of the computer that we are talking in a few minutes. But also to support for this, what's the what's the presentation exchange? I mean, the issue credential three and present proof three dot zero. I think it's not so different from the from what we support already, but this is something that we should implement. And on the other hand, and this is more a question for me, therefore, for you, for him especially or anyone from animal, but I don't know if it's anywhere, anybody else is that. We with with the current support of open ID connect from from the from the framework, is it possible to to receive and present referentials using that protocol? Or with open ID? Yes. So receiving, yes. Proving not merged into the A of J branch yet because we we implemented it in our wallet. But we were a bit tight on that line and we hadn't used these standards as much yet. So we didn't want to rush making an implementation in A of J without knowing what would be a good API. So we have a so on our GitHub. We have it. Let me see. Yeah, so we have an open day for VC clients, which is copied from Eris framework JavaScript because it's also dependent on like an unstable version, like a packed version of this one for which a PR is then we're open in in the serial repository. So it's dependent on this PR, which needs to be merged. So that's why it's all not in A of J. But like if you see here, we have a client API and in there, no, it's where is it? It's in the presentations part. There is like an open even verify for the proving part as well. And presentation exchange and all these things. So it should be doable to get that in A of J. But it's not in there yet. OK, but but you would say that that it works. I mean, it's or not. Yeah, it works. It works. OK, OK. So it's just a matter of adapting it and making it properly. And yeah. But I guess that it will be faster to support that instead of. Well, let's see what happened with it. It can be too. But yeah. We are close. OK. Yeah. And for like the conflict to we would also need like the packs attachment format still, which we can now do. There was a branch open from Mike for this. But that was also an issue we discovered with this. And so it doesn't fully work yet is that there were a lot of issues with the backslide where we were using. But I think they fixed a lot of those issues. So I think now we can add it in here. And we could base that of the like in here, we have a presentation exchange surface, which does like all the heavy lifting for selecting credentials, creating presentations, these kind of things. So it should be straightforward to do it for the packs attachment format. And then we would just need to have the new credential protocols. But those could I think they're basically the same as V2, but for did come V2. So that would probably be a copy based mostly. Yeah. Yeah. So biggest task now is probably the did come V2 stuff. OK, nice. So yeah, we are going to because we also submitted to join plug festery. We are for now going to do it with open ID standards. And like for next time, if then did come V2 was ready and we have the other protocols implemented, then we would like to do it also with did come as well. And then we could also provide like as AFJ community, a did come V2 issuer for for that. OK, cool. OK. Any other stuff on this? No, I think we can move on to the did come to party. Yeah. OK, did come V2. Well, work has been open for a while. I think maybe Arten can give an update. And then we can also look at like how can for Ryan get involved into the development of this and contribute to this so we can get it ready. Yeah, Arten, do you want to give an update or? The only update from my side is this month I handled the last chunk of comments you left in the PR. Main one is moving creation of connection from trust being to the receiving any message. And we can it's ready to take one more look at these changes. And once we get it merged, the next step, I believe we can merge it in main and at least we can sync with the main because I think it's a lot of behind of it already. And the next step there will be a support, you know, for road, road, can mediation protocols for it. OK. And this introduces some breaking changes, right? Because I'm thinking like if. If we could already merge this without mediation support, for example, I think I would be. For that, but if it introduces breaking chases, then we probably again going to have an issue with. Yeah, that we can't release the main branch for a while until everything is in place. Do you know like what the breaking changes are, whether that be possible or like what do you think would be the best to do here? You mean breaking changes if it is without mediation support. Or we can change this for one. Or well, if we want to merge this right now into the main branch, there are breaking changes, right to the API. I don't remember any. OK, I can check. But from API point of view, that just optional. Params, which can be passed. There shouldn't be changes in internal structures. Which are stored in database, but I can. Review it once again and double check. OK. No, no, no. In the API, you you're specific. For instance, when you create a connection or create an invitation, you you specify if you want to to accept. V1 and V2 or or both of how does it work? When you create, yeah, when create out of band invitations, there is optional param to specify which version of the messaging to use. And yeah, depending on the version specified default one is V1. Next message expected to be the same version. OK, but but but the. Is it is it possible to create an invitation that. Supports both V1 and V2. This is just kind of strange because I think if party doesn't support. The general format of V2 protocol, he wasn't able wasn't be able to proceed at all. Like he will not be able to respond to his previous version if he doesn't support it to because the messages has completely different format. Yeah, I'm thinking mostly on for instance, having a single QR code. That allows. Allows to connect. From all their agents and new agents as well so that they can they can easily choose if they want to use V1 or V2 mostly because of that. Yeah, I was thinking something like like what he must say. Just showing us if we are going to use the out of one one dot one. If we use, I think it's another type for the com V2. We don't have the com slash IP2, but there are there are also another one for for V2. Yeah, that one. You read my mind. I think that would be nice because because in that way we can we can ensure that we are going to to support both V1 and V2 peers. Yeah. Yeah, I agree. I think this this makes sense that we could create a did com V1 out of band message where we have an accept of did com slash V2 and then if. It would be okay to receive a did com V2 message afterwards for it. Yeah, I think that makes sense. It would be probably like a bit more complex if we need to implement this everywhere because then we always need to look at the right and what is it did com V2 that is sending this and I don't think we do any of these checks right now. So maybe this is something we can address in a follow up future like once did com V2 support has been merged and released already. Do you agree Arielle? Yes, but anyway I would like to add it as soon as possible because I think this is something important but but anyway I will I will try to take a look at the I mean I didn't have the time this week. Today but but I will I will try to to to play a bit with with this with this branch to see if I can contribute as well. Cool. Jakub wants to talk. Yes, that's nice. Yes, yeah, yeah, maybe like I'm missing something but you know I'm just looking to specification for did com V2 and it also introduces. Out of Ben invitation so I'm not sure like do we really want to support out of Ben we like do we want to really support did com V2 in out of Ben invitation V1 to 1.1 because I would rather move forward. Then trying to combine those things together if it's but I don't know what I it seems like as from what you said this it's not so easy to do it maybe there might be some problems with. Like supporting the did com V2 inside or like all together with obv 1.1. Therefore I'm not sure like and this is like warranty because like yeah isn't it isn't it easier to just add this obv 2 and maybe it's a question to current PR like is there is there the message for out of Ben for did com V2 or I would rather I would rather like do it like. To answer like the, I don't know if it's in the PR but to answer why this is here and why I also think it's a good thing and why the except was added is that with every new version of an invitation, you have a new interoperability problem because you have a new type of URL you need to support and parse, and what this allows is that I could support a V1.1 invitation, and I could parse that and if it says like I also support did com V2 I could use that, or the other way around. If I don't support did com V2 yet, but I do spend the time to implement a to support a out of Ben feet to invitation, and then it could still say like in the invitation it accepts did com V1. So that way, I can still connect and it solves bit of an interoperability problem between the different qr formats, I think. So it broadens a bit of the like ways you can connect, but the except parameter specifies the order of preference so once we support V2. I would think like we would always add the did com slash V2 parameter first, for example, but you can also still support did com V1. If that makes sense. Kind of. But is it. Yeah, maybe I'm like, I don't understand fully, is there any difference in like what's inside accept and what's inside and check protocols. It would be because and check protocols contains protocol types right so should be aligned somehow is there a difference in that. Yeah, I can imagine that it might be helpful but Okay, if I if I want to use it can be too. I probably should send invitation for that can be too. And yeah okay but on other party like the the the invitation for that can be too won't be recognized right so it would, it wouldn't be possible to answer that. Yeah, but I think that if we to this very same invitation message we are seeing here if we add the accept did com slash V2. The other party will just send a message to us, because it did come to be to we don't need to use any handshake protocol right or I'm wrong. Yeah. They will ignore this. This field, the handshake product. Yeah. Well, it's for services. It should use a bit. We have one minute left maybe quickly. This PR like there was updates to the did conflict to PR for connections. So we'll take another look at that how can, for example, for Ryan get involved in the contributions to this, like, how do we can we coordinate this. Very lovely somehow we kind of slowly start getting into what we agree internally it's we'll start what we know the framework. Well now, and we'll review more deeply the tasks, which are coming up in that sense. And my next question would be is the rainy where the finite tasks for the did conflict to like, if we can somehow. No discussion. Yes, that's that's that's the good. We can add a discussion for the convict you. And then we can, then we can add the tasks we identified in order to. For sure at the beginning it will be not easy for us to jump into of course and maybe some kind of an introduction and direct channel of communication will be very lovely. If you have such or it's everything happens through comments in the tickets. Is there any process for communication or it's only through a good luck. The most communication on github would be best because then it's just in a public place. Normal for open source project absolutely good. We can of course use this meeting as well, right. We will have another one in two weeks. So we can do a follow up and do discussions like, well, like we had today. Oh, that's very helpful to you said in two weeks. I thought it's every week. Yeah, but for this summer. Yeah, yeah. Oh, you're taking locations. Okay. No, not me because I know it's winter for me. So, I mean, it's part of the world. Sorry. For most of you. Yeah. So I like to say one if you cannot also like sale running. So yeah, the next one will be the 17th of August. Okay. Good. So as I said, we are quite interesting and very happy to jump into and try to, to help and get involved within the community because we believe it's one way to drive the progress in general of the whole community. By evolving slowly the, the features and the, the enablements that can come directly from the framework. Cool. Okay. Well, then let's continue the discussion in the GitHub discussion and we'll discuss it again in two weeks. Thanks everyone for joining and see you next time. See you.