 Good afternoon, everyone. Hello there. Hello. Do I see a Fabrice in the call? That's the first time. Hi, Gary. How are you? I'm good. How are you? I was connected last week. I wasn't there last week. All right. Let's get started. Sorry. I wasn't very well prepared. Came out of another meeting. Not to rush to this one. So, let me see. Welcome everyone to the Earth Summit, Jessica Brooklyn group call June 22nd. I need to remember you to abide by the hyper-legit code of conduct and anti-trust policy. If you would like to add yourself to those tending lists, so people know you were here. Feel free to do so. I'm going to start with that cover. Is there anyone here that's new today and would like to introduce themselves or share what they're working on? I think I recognize most of you here today. And quickly some status updates. Did we have a bifold call this week? Anyone that knows or attended? Yes, I was there. I don't know. I don't know. I don't know. I don't know. I didn't, I didn't catch all of it. It looks like they're on the home stretch of integrating AFJ. 4.0. Or 040. There's just a few little remaining things. I think a code review and some merge. Collisions to clean up. But they're getting very close to that. So I'm going to go back to one of the other activities around looking at moving to the latest. React native and, you know, updating a whole bunch of dependencies and the like. So that was. I think a fair amount. Of the discussion. Was around that. There's also been. It's in an alpha at the moment, but they're using that one to learn. And before moving on to publishing other parts of the. Project in NPM. Cool. Yeah, I think the PR for AFJ 040 has been over for a long time. But I think they're now finally, it's now finally ready to get merged. So it's a good thing. This week, that's good to hear. I saw that Jason fixed some of the last merge conflicts. Nice. Airways call. I can give a quick update. There was a discussion on the refuted discussions. One. I'm going to talk a little bit about. Mediators and how do you do a scalable mediation. And this show. Announced a. So I think it's called, which is like a way that you can put in front of your mediator that can keep web sockets open and like it's agnostic of the agents. Running behind it so you can have like that separated. The agents mediator itself a lot more scalable. I don't know if there's anyone from the initial team on the call today. Hi. And the thing I missed or you would like to add. No, I mean, it's just a way to manage web sockets and make it a connectionless. Process between the sockets and the service in the back end. So that way you don't have to maintain an open web socket. And you have a good way to send messages through the web sockets. From the mediator. This allows the. Cluster environment not have to pass messages back and forth between the different. Services on the back end. So for example, I know a lot of people are trying to figure out, well, how do I do that? So the message makes it to the right node that's holding a open web socket connection. So that's the main problem that socket. Docket stock was trying to solve. Okay. Nice. Yeah. And so you have tested with. We actually tested this with our. Our cloud skill mediator. Which is a separate mediation based on. Right now, Amazon Lambda, but it's open to other, other platforms. Okay. We know the Akapai community has been talking about needing to solve the same problem. So we brought this out and open sourced it for everyone. Cool. Okay. Well, in addition, there was a. I think that took over most of the meeting. I'm probably forgetting something. That was discussed. Was a very short discussion about the open wallet relations stuff again. Maybe we can get into it later a bit. And it was something else that I'm forgetting here. I think, no, I think most of it went into the mediator stuff. Yeah. Okay. Cool. Then for the agenda today. We have to did conflict two days ago. Artemis here today who can give an update on like. What's the current status of the conflict to branch. What's like. Limitations of the current implementation. I think also like what were the limitations when. The work stopped in November and like, are there any things like what's still blocking to get it merged. And when can we use it. And I think then we can start out. We can have a short discussion maybe on the open wallet foundation discussion. And maybe we can continue on the. On the wall of API discussion. I don't see Ariel here today, but he created the discussion. And I think we. Yeah. Ended the meeting last week with him having given a presentation. But not really. Yeah. Next steps. If time permits, we can also get into it. Documentation and getting started being continued. Yeah. And otherwise we'll put that to the top of next week's agenda. Anything's people are missing or would like to get addressed or discuss this week or in a future meeting. Well, one thing, Ariel just joined. So that's good. I don't know if we can do that this week or if it's part of the open wallet foundation, but you and I had a discussion about. Recently about some ideas on. Not. I guess it's not modularizing the framework because we've already done that, but like splitting it up into. Sort of standalone libraries. Maybe we can touch on that. I asked parents to give a presentation on that in the next few weeks. So I think it would be good to have that like have a dedicated presentation called to do it. Cool. Good. Good point. Cool. Okay. Then let's get started. Art and do you want to share your screen? Or how do you want to. To do this. Yes. I would like. I prepared several slides. To better understand. Hello. Hello everyone. My name is. Somebody doesn't know I work for this. And. Today I'd like to cover the current status of get convit to branch. Support in. The initial work was done in last year. November by SIGPA. But it was put on hold. And didn't finish. At that time. Now with this are volunteered to. Complete it. Finalize. Get it. Finally supported there. We did it. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you very much. Thank you. Thank you. We did some work, which are going to cover. During this presentation here is. A gender. First of all. Brief. Really short overview of what's the key difference of it coming to compare in the first version. Next. Tell. What was done. after that cover concerns and issues about the current implementation and what's wrong and after what next steps. Okay, the specification of GitCon with can be found here. I'm going to share this presentation attached to the meeting afterwards. The key requirements and characteristics of the protocol preserved are the same as for GitCon V1. It's designed to be secure, private, decentralized, and transport agnostic. And the key difference is that it's designed to be rotable. What it means, it means that each message of the protocol should include everything needed to interact with another party. So you don't need any kind of explicit handshake protocol like it was before when parties establish a connection and exchange messages using the exchange in advance. Now agnostic is same like for emails, if party knows the agnostic of another one, it can easily prepare the message for him and pack it and send it, resolve all the required information based on the DID document and send it directly and interact. What's done? First change, this is crypto. Just on the envelope used for GitCon V2 differs from the first version. There are another set of cryptographic methods, which are used under the hood. The general format is the same, but different crypto operations. And the initial implementation was done using SIGPA, GitCon library, but in fact, it didn't good suit for AFJ architecture, it requires implementations of the interface and making some methods of the wallet public. And it was decided to change JVA pack-on-pack methods to use Ascar directly as it's currently it's a plugin, optional wallet storage, which can be used and it provides all necessary crypto. So we implemented pack-on-pack functions and now they support both versions, GitCon V1 and V2 for RS Ascar wallet, Indie wallet, do not provide crypto methods required and for now it's not supported, it cannot be used with GitCon V2. I believe it can be done in future, but for now we postponed it and skipped. So RS Ascar is the only option for the moment. Next messages, we define it common agent message interface, we define set of common methods, how base agent message should look like, and this interface used across of the core package to reuse common logic, there are implementations for GitCon V1 and V2, which defines the general structure of the messages and if you are going to implement some specific protocol, you should extend messages from the protocol and reuse either first version or second version of GitCon message implementation, it's currently inside of core. Message receiver, there are almost no changes there, functions handle both versions, everything is hidden inside of the Ascar wallet, unpack method, it returns the version of unpacked message, so doing the next step, we can determine which version of the message is used for sender, currently there are two versions for methods for send messaging, the reason for it is, as I mentioned before for GitCon V2, there is no concept of the connection and this is key reason why we had to create two versions for sending message function, I will touch this topic once again later, the key thing to understand right now that there is send V2, which version of the function which doesn't depend on the connection object, it takes, it resolves all necessary information from using from and to fields of the message, it resolves the documents of sender and recipient, it finds keys, which can be used with common key type and it also resolves the service which is supported by both parties and send it directly, for V2 version, the functionality is smaller, it's limited comparing the first version, there is no support for sessions, for message queue, for priority, it can be done as the next steps, for now we just wanted to demonstrate that messages can be sent and received and we can exchange messages, protocols, for the moment there are options for two protocols out of band, really basic version, just creating an invitation message, which can be transferred to another party and another party can accept out of band invitation and create connection state object and another protocol is trust pink, it also a basic one, as there are just two messages, ping and ping response, party which accepted out of band invitation can send ping message to the inviter, inviter upon on receive all trust pink, process it and if response is requested, send the response back using sender G1, the implementation approach is the same as for supporting multiple versions for git com v1 protocol, for example for issuance of representation we have two versions, there are folders with protocols for each version defined as a set of messages connected to protocols, handlers, services and so on, so here we used the same approach and for trust pink there are two folders v1 and v2 and each of them reflects git com messaging flag, it may be a problem, I'll touch this topic again later, moving next, how to identify which version to use or git com v1 or v2, when we create invitations there is a parameter to define in the version explicitly, when invity accepts invitation he creates connection state object and inside of connection state object there is the protocol field which was before and we said the fakey idea of protocol did exchange with in fact there is no such protocol, we just used it as a constant to identify that this connection object refers to git com v2 and next when we send trust pink message using this connection we know that we need to prepare git com v2 trust pink message and use corresponding encryption and functions and about DIDs we used peer DIDs for both parties peer did this method too when service is embedded directly into the DID, there is ability to use another options but this one is the simplest I believe, this is why we chose this one we also created a demo in the branch you can find it in the independent folder in this demo you can create out of event invitation Alice can accept it next Alice can send pink message and Faber can process it and reply if it's requested the important thing here is that there is only one direction of communication right now only Alice can send the message to Faber on the Faber side currently we don't create connection state object I would like to discuss it next how we should act here currently right now concerns about the implementation as I mentioned the first one is connection git com v2 doesn't depend on connection and parties interact just using DIDs so should we current afg implementation strong depends on the connection state objects and all protocols requires connection to be established in advance and if there is no connection you cannot send messages but for git com v2 there is no such requirement you can start any protocol just restoring a DID of another party so like meaning it looks like we do not need such object anymore but if you want to use as much of we can as we can common functionality and avoid duplication we need to somehow create fake authentic connection objects and this is the first question to answer about how we can how to properly to do it the second point is strong strongly connected to the connection in fact as I mentioned there are two versions of sending the message function functions and for git com v2 functionality is limited comparing to v1 we need try to unify this version somehow provide a single method handling both cases uh and once we get a common function uh once we get this single function the set of features for both protocols will be the same it will be easily to maintain and extend the protocols adoption specification specification for now provides some examples of protocols how they can be done in git com v2 but v1 specs defines much more protocols for example git com v2 doesn't explain how issuance and presentation protocols should change how they should look like and as I mentioned for now we only adopted out of brand interest pink regarding the implementation and as a concern how to properly organize the code in fact we have two versions of git com v1 protocol like for issuance we cannot just create one more folder with v2 it will be confusing and we have v2 for git com 1 and v2 for git com 2 uh we need to deal here some other way find a better approach probably we should we can consider conversions of the messages back and forth and just use some identifier of which version is actually we need to use in the end crypto as i mentioned uh only a scar wallet supports git com v2 for now according to the specification uh git com v2 requires resolving of the id documents and because uh we need to get keys uh just on the envelope also contains key references and we need to resolve the id documents from the key references and current interface of the wallet do not accept git resolver we cannot inject inject it there and due to this we had to uh resolve all necessary documents one layer atop uh we currently do it inside of the core package so we in fact we already passed uh jwe and analyzed some fields uh to prepare git documents as parameters and we pass them into pack and pack functions this is not uh a good solution uh but it allows us to support uh uh different git methods uh if we only limit to use uh git peer for instance or git key uh we can resolve all necessary information right from the id identifier but uh if we want to use some other methods like git software git web uh the id url doesn't contain uh real key and we need to resolve the id document first so in order to provide to support all possible git methods uh the implementation of git com v2 uh is a little bit spreaded between uh wallet and core package we need to think how to better organize it or implement or rework the wallet and the last concern here is about the id's creation uh uh in all out of band service there is one more function to create a peer or the id method it can be a duplication of existing logic i didn't check uh it just uh left from the november we need to try to reuse the existing methods from git register as far as i remember it's quite a new model i just one more thing to take into account uh what's next a part of the concerns which we need to resolve answer these questions and provide the best solution for them we also need to support mediate mediator as the initial work was already done in november this branch this merge request is currently closed and uh outdated the right ones of conflicts we need to actualize it as well in scope of this pull request we added mediator coordination protocol and the message pickup protocol versions so right now git com can be used only with uh when in point past as parameter so it can be used by mobile applications only by services and one once we get implemented mediator support mobiles mobile apps also will be able to use this feature there is also a concept about the negotiation between parties on what protocols are supported by each of them and how to detect which version of messaging need to be used to send message another party can understand it and reply we need to adopt more protocols issues in presentation as the most commonly used was powerful and the conv2 also provides not only just one web envelope but just one web signature and plain text messages uh for instance just just some website message can be used when we transfer the very first message out of band invitation for example to to prove that i'm an owner of the dig which is reflected in the invitation so we can extend our wallet implementation to provide joe s methods as well and the plain message also can be sent back and forth in some cases i don't know now examples cannot provide them but there is such option i think that's it that i prepared i'd like to go a little bit back to concerns and we can discuss each item step by step cool thanks a lot for this presentation this is really helpful and uh yeah brings us all on the same page where we are um does anyone have questions i have some but i would just like to hear from others maybe if they have questions or notes on on this presentation hey kaleen kaleen is here kaleen from verin i don't know if you can hear me well because i'm on on the workshop at the moment and the connection is all very good hopefully you can hear me well yeah i can hear you yeah it's dropping quite quite often um artem you have mentioned that the next thing that it needs to happen is to have a mediator right so that way uh once the mediator is there the mobile applications can can also use that that protocol right but i was thinking i think in the aries um uh framework golang they have an option to play as a mediator do you think that can be used also i mean to play the roles in mediator so the mobile phones can connect to that mediator even it's on golang what i meant it's not only to have a mediator deployed somewhere we need to inside of afg implement protocols required for to communicate with the mediator uh to be able to talk and how far you think it's it's that do you think it's a lot of work or something that it can come you know in the next month or uh i think it can come quite soon uh before working on this you'd like to to resolve concerns which i mentioned before uh as i mentioned most of the work regarding the mediator support is already was already done in november oh lovely okay and we need to transfer it it just there are a lot of conflicts and we need to refresh it and apart apart from the aries framework go as you mentioned uh there should be sygpas uh bitcoin v2 mediator available as well yeah i think uh team will send it on the chat already okay yeah this one uh this is a very basic implementation it uh not fits for production needs but for testing and for demos uh it's good enough it supports only bitcoin v2 not first version and it's in nest jess and it uses sygpas library i see okay good thank you yeah i think one thing um i'm interested in is is uh uh there's few but i think uh it's like how do we deal with connections in bitcoin v2 i think you also added to the here um and like um yeah but what is the um do people still like do you still create a connection but don't we use like a data exchange protocol so we just like a connection is nothing more than having a record where i store my dates and the other parties did and that is enough to have a connection um or do we also want to support basically just sending a message to a date and not having a connection and i think this can have quite some impact on the architecture for example if i now want to send a credential offer um i can do that to a connection id only or id connectionless um well connectionless um um in bitcoin v1 is a bit different i would say then the like the connectionless in bitcoin v2 um so i think yeah maybe yeah what do we think about like should we require uh you always to create a connection so if you want to exchange information with a date you can just create a connection record and the only two fields basically it has to uh contain our our date and their date and then when we want to send messages then we have all information um um or do we want to allow for yeah connectionless um exchanges as well where we only use the date to send messages um yeah to know if people have opinions on this or are some what do you think i think we should create the record because it in any case it's useful for instance on the mobile we'd like to get the list of contacts uh which i know and i can send messages so we can create an instant record just with two gags and use it and it will be simpler to reuse logic for bitcoin v1 and v2 and it's quite still quite useful from the user experience point of view and therefore it's for bitcoin v1 uh if we look at out of bands protocol there is also option uh when party when there is no handshake and party just uh create create instant record and it's quite similar what we have now i think there will be the benefit to to just send a message to it without having an associated record to it um just mainly for ease of use if you don't want a a context necessarily with the other party um and if the API is just like if the record is just there that an hour did and i think it will be fairly nice to instead of supplying a connection i think you could also just supply it and that takes care of it um don't know the direct use cases you might have but it seems useful to me and especially if the underlying logic is exactly the same except for retrieving the connection record then why not yeah okay um yeah i think it makes sense it's just not probably the easiest to answer in this case because it requires like a very big change to how we handle sending and receiving messages in afj but maybe we could more like instead of having a connection id everywhere um we have something like a recipient and then when you call the api the recipient can either um like take a connection id or it can take a recipient did um you can optionally then provide a sender did if you want to uh say like i want to use this this did for sending the message um we do have to look good then um for example now we have a credential exchange record which you have a connection id in um and um if you don't um use a connection id you can do connectionless and then you have the out of band um record that is associated with it um but if we now also support like direct sending of this then we would need to have like another type of way to store who we're interacting with and then we would need to store about what's our did and what's their did uh they're using um so i'm thinking how we could have a good abstraction in afj that makes all this kinds of flow possible uh warren yeah if i'm not sure uh how this would work but i wonder if um we're conflating a contact with a connection and uh and perhaps they should be different things like perhaps a connection doesn't have to be revealed as a contact and so maybe you can have the same underlying abstraction and then an indication of whether it should be saved as a contact or not uh and then that that might make the whole abstraction easier to deal with in terms maybe not if you were starting from scratch but in terms of you know trying to bend the existing architecture to support this yeah i think uh that makes sense maybe yeah oh erl yeah yeah warren you you mean that probably if we even if we are sending a message to that did directly we can still create a connection record for that exchange because actually i think it makes sense because every connection will have a our our did and their did right so uh yeah i think it's a it's a good solution maybe we can use the the concept or at least internally the concept of connection for for both for both cases yeah i think it maybe would allow us to reuse the connection abstraction we already have and then we could keep the api very similar but that you then have different type of connections and a connection doesn't always mean you have to show it as a contact but it's more like an uh cryptographic relation that you have between two two uh bits i think uh uh yeah i think yeah isn't the connection just a bit there yeah in in this case i think for like the older um in the beginning like a connection was uh it was also yeah basically a bit fair because it doesn't provide any trust basically um so yeah it's basically a bit fair so then we could say connection is still the foundation of most of the exchanges but um you can have like a thermal connections in that case and connection is not the same like really having a contact or a long-term relationship it's just a cryptographic connection um parent do you think that that would work also um yeah yeah i think so i think uh introducing just yeah if you have a connection record then you introduce ephemeral true false and that would basically be a contact or a connection something along those lines um would be good i think just like from the api if you could just supply it and then under it would create a connection record um that would be like a short-lived connection record or something uh that would be quite quite nice um and a bit less yeah but you have to retrieve the connection ID first if you already have a bit um just a nicer api i think yeah okay um yeah i think that makes sense um um i think that would also make probably it for now the easiest approach because then we wouldn't have to change that much like we can have the same way to handle sessions um cues everything let me see there was a comment from alex uh you can still receive a message from a dit you have never seen though right yes that's correct so what do we do in that case um we could create a connection with only um the other parties did um but yeah i'm not sure how we should happen let's say you receive a credential offer from um a dit um you don't have a connection with um how how will we handle that do we create a connection record on the fly um or but yeah i mean that that requires if we don't create a connection record on the fly it requires custom logic in the protocol implementation i think so yeah that's a good question i i think that if we design something that would be a configuration option um because mainly i think if you have someone's dit and you can send them a big amount of messages to i don't know to to feed those them or whatever you would probably drop them if you don't have a connection if you are a big party or maybe it's a small party um but yeah if you receive something from if and if you don't want to receive any random message from other people i can imagine that you would also just want to ignore them um yeah that kind of that kind of sounds like an application layer decision yeah that's why i'm in configuration so you can configure as an app in afj to what would happen with the messages right i guess what i'm i'm wondering is uh are you thinking about a configuration that would be global or a configuration that would could be more granular because you you may want to allow traffic from like uh basically ask the user whether they want to accept something in some cases but they also may want to create a block for instance on certain did so they don't get bothered about it um and i don't know that that afj would be able to make that kind of decision on its own it would need to be or like run at runtime yeah i i think that that could also work um not so i don't know whether like a connection like under the hood i suppose a a dynamic connection could be created or you know the whatever notification gets sent to the application layer could provide a context that needs to be passed back and if that context is provided and passed back then you can establish the connection at that time or discard it if you know there's no action taken or like so you don't end up with junk in your connection list for things that the user doesn't want to deal with at all yeah yeah i'm not a hundred percent sure on the exact implementation um i i think what you just proposed sounds sounds good to me it's just as long as uh it is something that should be done by the user and i think if afj that basically was just set as afj we can't really make that decision um so i don't think we should deal with it in in a way like that i i think there's probably also a happy medium now that i think about it which is perhaps you know you um depending on the application the application might say okay this is the default behavior i want afj just take care of it um and the default behavior might be you know send me everything or you know send me nothing if it's unsolicited um uh and then they have the ability to do the filtering themselves so maybe maybe there's a happy medium where there's some kind of configuration that would allow for some default behavior that would be valuable for some use cases but the flexibility to let the application make it behave the way they want yeah i think um yeah i think having a simple default would a way to customize whether it's a uh an interface you have to implement or call back where where you can basically implement your spam filter as as alec said i think that that makes sense um um yeah i think what i would really like to have in a solution is that it is something we can handle generically and not something that has to be per se handled by the protocol implementation so that the issue credential protocol doesn't have to account for maybe maybe there's a connection maybe not maybe it's from a dit maybe it's a dit conflict like that it's because then the the the ways becomes like exponentially complex for each protocol to implement but for example having a um dynamic connection which is first marked as like uh like in verified or like unhandled or we have a callback interface where you can dynamically verify incoming messages and say like all right i want to accept this message and that will create like a uh a dynamic connection um i think that's yeah interesting approaches to explore um what do you mean alex with other non-afj agents need to support connections to interact with it i'm sure if you can solve but uh i think he's probably agreeing with you that you don't want this in the protocol layer for the individual protocols if i read this correctly okay okay uh i i may be misinterpreting but that's my so and i think that i think that's a good thought that the protocols probably shouldn't have to be aware of this okay yeah it's an it's an internal implementation detail as to whether you know uh an unsolicited request becomes a connection or not um and whether that connection ultimately is revealed as a contact or not those are kind of application level decisions and not not protocol or network based decisions i would think yeah okay i think uh that makes sense um yeah cool uh i think in a lot of cases like when you use peer-to-peer it's then uh like there there's like you wouldn't just randomly receive messages um so maybe we should look at then what what would be a good first iteration that we can have without making it too complex like i think there's been a lot of work in the did conflict to branch and there's some stuff missing but i do think it would be good to have it get it ready to merge then we can iterate on it um um so um art and do you think like something like this where we create dynamic um connections um whether we have the the way to like uh have a dynamic maybe we can for now keep it with a simple default behavior like you allow or just allow do you think that that would be something we could implement quite easily into the did conflict to branch i believe yes cool um are there any other things then that we would be um that would need to be addressed um like i think mediation is a nice thing um to have but also something we can add um in a follow-up iteration i think if we have like a first thing merged with just out of band and trust being then it becomes easy to add other uh ones do do people see any other parts um about yeah that need to be addressed or or things to note here i guess i just have a question i'm not sure where the specification work is at at the moment on the protocols layered on top of didcon v2 i'm getting the impression from some of this discussion that that work has either not been done yet or is incomplete um can you fill me in on what the state of of that is and or whether like part of this work has to be actually defining the new or redefining if necessary the new protocols to fit into didcon v2 i think there has been work done uh so for example if you want the mediation there is a mediated coordination v2 which is basically the didcon v2 adaptation after the v1 so not really a lot of change in functionality but optimized for using it with didcon v2 and there's some other protocols so for example um whereas it's the issue credential v3 um has been defined which um works with um didcon v2 um so there is some work being done but not too much yet i would say uh so we're probably gonna run into some issues and as you can see it's like there's not a lot of activity on here um i think there has been work also on a eris intro profile v3 which is based on didcon v2 um and then supports issue credential and percent pro v3 which are didcon v2 um so and i think the the requirements for didcon v2 uh intro profile would be a lot less because a lot of it is already incorporated into didcon v2 um itself so there is a foundation we can build on um but it's yeah i would say newer territory um yeah let's answer your question yes it does thank you cool um then um artem do you have time in the coming weeks or so to to to work on these final tasks i know that farine um was interested also in the the didcon v2 uh work i don't know if i think he left the call um yeah oh well so i will ask him next week but um yeah do you have work time to work on this or i try to find a little bit time unfortunately i'm quite quite busy for the moment and if i will be able to change to apply this change quickly uh or if i have some problems and i understand that it take longer time i'll notify you and inform okay yeah no that's uh that's uh that's a good answer um okay thank you and i think uh yeah we at least i think it was a good discussion and we have some consensus on like how do we want the api and integrate it with the connections um so then we at least know what's still left and needs to be done um cool thank you for this presentation could you uh attach it to the uh the meeting notes uh i attached but for some reason it shows unknown attachment i'll try to do it once again well i think yeah it it it's uh added here i think if i do it like this i can all right yeah so i i can download this in attachment that's that's perfect okay okay thank you um so we're out of time basically um um i wanted to still discuss the open wallet foundation maybe i can also put it in the discord and we can pick it up next week um but i was curious to hear like um what uh we have already discussed it here a bit but whether um the fj community would be interested in like a potential move of the project um to the open wallet foundation um arise like from the areas discussions there came out of like um we're not ready to move uh currently to oh wf also because it's very early states uh but that we are looking at more collaboration and maybe moving projects over gradually um so um nothing is final yet but i was thinking like yeah i'm quite interested in it so i was thinking we as the earthstone JavaScript community could be like one of those first projects that move over try to see how it goes whether everything goes well and then other projects could be moved on moved over as well later on um so yeah something to this consider i'll bring it up in more detail next week so we can have a discussion but uh yeah think of that uh uh yeah for next week um okay so then um we yeah didn't have time for the other discussions we'll uh touch on those all next week um thanks all and see you soon thanks goodbye thank you