 Good afternoon everyone, I think we can wait one more minute or something and then we can get started. Alright, I think we can get started. Let me see, I think it's already recording. Yeah. Okay. So welcome everyone to the earth from JavaScript working group call of May 18. I need to remember you to abide by the higher blood code of conduct and anti trust policy. If you would like to add yourself to the tennis list, feel free to do so so people know you are here. Yeah, I think I did, but I'm trying to look probably. I didn't always a hassle to find the correct page in confluence. That's why I don't want to navigate. Yes, I can understand that. Yeah, so if you would like to add yourself to the tennis list feel free to do so. Is there anyone new here today that would like to introduce themselves. I think I recognize almost all names. Alright, then we can get started. The right away. Are there any status updates on different projects that people would like to report on. Okay. Then I think we can get started straight away with the agenda. We have a presentation from cream on how the repo is structured and with all the new things we're adding that are not arise and how that works. I don't know what, if you have a title for cream. I do it's very cheesy though. What is it. It's the future architecture of areas framework JavaScript with a cheesy subtitle navigating the changing areas ecosystem. That was just a bit. Alright, well, so that's the presentation concrete. Anything else we would like to add to the agenda for today. And I think we could discuss. Did comfy to work in more detail. Okay, I saw there are some PRs. Any other things. I know we were going to have a discussion on the wall API at some point. I don't see a rail here today. Any other topics. Sorry. I suggest maybe, maybe I just wanted to suggest discuss and suggest others about as card libraries. And honestly, we just still suffer a bit because of using only the latest version of iOS. Yeah, hi. So actually, I've seen some new pull request merged into areas Oscar I believe yesterday. This lower areas version support. And I believe it should be done soon for individual. Is it right. Yeah. Yeah, it should be. I'm not sure though if parent has already tested if it fully works now in like with the new release. But yeah, I think is now done on pets RS and errors Oscar and and only left to do is the R. Yeah, I just saw it before the meeting so yeah. It's a good progress. And I think yeah, changes that parent has done are closing all issues that they created, I believe, because he also corrected bundle name and so on. So I think once we'll get all three shared component libraries, including in the video, we can just test it on our site. And of course we'll provide some feedback, maybe I will just write results to the issues that I created. Okay, yeah, that sounds good. Okay. Perfect. I think to like continue on the shared components then I think the other final thing that needs to be done is like the lower version support for Android as well which we have to custom cross images for. I think clay show you were able to build it in get up actions right the custom images or not. Yes. So I'm just making some changes and then I got to provide to bear it soon. Okay. Yeah, that sounds good. Then we can. I think if that's done. Beards can integrate those into the different pipelines. Are you going to publish like make it a hyper lecture repo and publish them to the hyper lecture GitHub container registry or I'm going to provide to bear because I'm not quite sure we have a repo for the shared for the cross shared images yet and I don't know if you should create a new repo or what is this plan is or would be stay with animal for now as it's easier path. I'm not sure if we can just create a repo and a hyper lecture I think that that would work fine as well. But I do think it will be nice to have it as a separate repo because it will be used by all the shared components three point and we can at least make sure that they have like a consistent build setup and Android version support across those. If you just like transfer to us or like provide us with a link then I can go to the process with rye of adding it to hyperledger. Yeah, absolutely. Okay. Okay. And I think that's it on the shared components stuff. Then we can get started cream do you want to screen share. Yeah, that might be good. Let me see if that works. Please let me know. God, I think my screen. Is this presentation view visible. Yeah. Well, as you, you presented it as a presentation. I do have some slides but it's not really a presentation. I guess it's more of a discussion. We have had internally in animal and. Yeah, I think stuff has been changing recently. And what makes this even more relevant so I'd like to open the discussion here to see what other people think of it so a little bit of background why are we discussing this. Well, we all know areas was initially conceived in the in the ecosystem. And as a result, we, well, all or most areas implementations at first dependent on the in the SDK. And as well. And did come was also part as being part of areas was also baked into the core. And quite some stuff has changed over the last, well, years, I guess. Recently we extracted what one we modularized a day. Recently we extracted in the SDK from the core shared components were added. We now have a separate packages for the unknown credits format. Also, because that became its own hyperledger project. In the meantime, did come as moved away from areas and is now being maintained by Dave. New supports for other credential formats, like the link to receive for months we added support for checks. Other protocols exchange protocols like open ID is is well is still being worked on but issuance side of it has partly been added. And now we also have an ongoing discussion, which was partly held yesterday during the areas call, if they want to do with areas, if areas is going to be moved to the open wallet foundation, or stays as is. And so, because of that, I think we things are a little bit messy right now to give you some examples of this. We now have unknown credits, or what logic related to the unknown credits credential format in their own packages. But that W3 CPC related format stuff still lives in core. Did come is part of core. Did come transports, some of them, like the HTTP and Web so could transports live inside core, while the Bluetooth transport lives in the extensions repository. We have all kinds of did come based protocols that are also part of core. Think issue credential, I present proof, while others live in have their own module action menu being one of them, for instance. Yeah, so this raises, I think a few questions. One is what is the scope of core, should it contain modules like now core is a is its own package but in the in the core source, we have, we have a directory modules that has all kinds of modules. So, to credential, or is a module present proof, the protocol and related stuff for that is its own modules. Is that something we want should, because should we have modules live in the core package as well as outside of the core package is a question you could ask. Should we have like credential or proof format specific logic living core, or should we have that outside of core again this goes back to the first point here is that we have. In the Anocrates format we have separate packages, but the w3c format is still part of core with the move from did come out of the areas ecosystem to or, or, well it's, I guess, you can just, you can argue if it's still part of areas yes or no but it moved to to div. Is that still something we want to be part of core or should that be like a separate module you can you can either include or not. Let's say you only have you only want to use open ID then there is really no no point in including that logic to your project. Should court also have like transport did come transport implementations, or should we just make or a very lean package that basically only as a dependency manager defined some basic interfaces for modules and stuff. And for the rest every everything. Yeah, lives separately from the core package. Then you can also ask. We currently have to repositories with the main AHA repository we have extensions repository. What is the scope of those and where do we draw the line. Do we want to include all modules in the main repository. This means that like whatever funky module someone comes up with that that the main repository is the place for that. Should we include only include modules in the main repository and this is an example of this is is that come transports. Should we include them there. Or should we maybe say no transport session or an extension of did come so we put them in extensions repository. We don't want to include modules, we don't want to include at all, or that we don't want to maintain. Again, let's say some contributor has a very writes a module for a very obscure database for instance. Should we, as as the community, take it upon us to maintain that yes or no. And what is the scope of the extensions repository. Initially, it was mostly stuff built on AFJ. You can think of the react, react hooks, which is like it's a helper library that you can use with AFJ but it's not part of AFJ itself. The same goes for the Redux store. We don't want to also have modules live in the extensions repository. And lastly, like, does it doesn't even make sense to maintain both we've seen quite some difficulties with maintaining or keeping the diversions. How do you say that they sink, I guess. And so it, like, doesn't it make more sense to put everything in one repository. Here are just some two ideas that were discussed but obviously, I'd like to open the discussion after this. So one idea is just to keep it as is sort of so areas from a JavaScript stays areas focused, whatever areas turns out to be because that's also a bit of a question. But so the main repository just stays focused on areas. So here I am assuming that did come will will will be be considered and keeping considered part of areas. But this would mean that open ID related protocols, for instance, would live in their own repository. This raises all kinds of questions like, again, is did come part of areas, and therefore also all relate protocols is in the, do we consider in the part of areas, and thus, doesn't have the right to live in the main repository in the same way that we're at W3C, because W3C is not a every standard, but well the areas protocols, or the did come protocols, allow for other formats so you could argue, if other formats then also should be included just for now. And the same goes for PECs, the presentation exchange, which the present proof to present proof V2 protocol relies on, and also if we're going to like make all kinds of different repositories, we probably get into even more difficulties with regards to maintenance. So the other idea is just to make every framework JavaScript a sort of generic SSI framework, and I think, like, we're moving towards that more and more. And this would mean like we don't. Yeah, we welcome, like any standard SSI related standard protocol into the main repository. So in that case open ID related protocols would will have the right to live there, not in core. So in this case we would make core a strictly a dependency manager, again with some basic interfaces to to interface with the dependency manager. But then that also means we move every, like all the business logic so think of well did come related logic. We would move all the protocols so issue credential etc etc logic related to specific credential formats through formats etc etc we would move all that out of the core package still in the main repository, but out of the core package and give everything their own package slash module. Yeah, this was it basically. Welcome. But yeah, this has been has been keeping me up at night. So it's, I'm happy to discuss this. I'll stop the screen share now. And yeah. Are there any ideas, preferences about this. I know you have a lot of ideas. I have comments. So, as you mentioned, open wallet and I was not in the call this week. So, I'm going to have to watch the recording to catch up with the, with that conversation specifically. I think, I think it may be areas JavaScript might be morphing into something I don't know if it's. I don't know if you be something like the open wallet or, or it's just a generic area more than areas agent right because it's going to support multiple protocol it's seems to be evolving to something else and I can't quite figure out what it is, but, but it's more than areas. That's the problem, isn't it. But, but I do take your point and have multiple repositories and sometimes have a multiple repositories blessing occurs. And I feel like those components are so tightly coupled version wise that it's, it makes sense that they you're all together, the extension and, and just breaking down multiple packages we already have right now. With regards to did calm. We already using the breast library or is that the JavaScript library from diff. Is that. No, we're using any diff libraries currently from implementation. So, and I think if that is the future for us I think we should maybe consider that as well because if we already have, we're really not dealing with the, with the storage part because we rely on ask our we're really not really dealing with some some of the concrete stuff because that's moving from another to another library as well so so it feels like more and more the areas JavaScript is becoming more of a thin layer around bringing all those other libraries together in a developer friendly way he's more more of a facility than than it's more of a kind of a sugar syntax as opposed to re implementing things. I don't know if that's, I don't know if that's the goal because if the goal is to bring everything together to the for the for the JavaScript community to to use, or is the goal to keep it as JavaScript implementation as possible. Yeah, so that is a good question. But, but I think regardless of if we implement stuff in in JavaScript ourselves or use a rust library or whatever. And the main question here is what what, and this is also something we cannot answer in this call and should be like further discussed, I think higher up. Is like what is areas is areas is did come still part of areas. And if so, like, should we make because currently you cannot you, like even if you want to make a 100% open ID related agent, which now is probably not the right time because we don't have everything implemented yet but but that will soon be the case. You don't have the choice right you include your did come logic. So should we externalize that. Yes or no, which I find difficult to answer because it really depends on on what we consider areas to be. And if we want to make the framework, like, or if we want to keep the framework and areas and like focused on that yes or no. So I think for me personally I would switch it around not look at what is arise but more on like what do we want AFJ to be. And then see if that fits in the model of arise. Yeah, yeah that makes sense. Yeah, what I my personal preference is because I just think with all the changing the big changing ecosystem and and also like in Europe, people, or the European Union has been jumping on open ID so there's probably a lot of people wanting to do that. And while there are other. Yeah, other organizations and parties in more interested in Bitcoin. I think the most like the last option. I mentioned like just areas framework JavaScript as a generic as a side framework makes the most sense because I think it will be usable for the most amount of people. So but it will not be called areas framework JavaScript is called SSI framework JavaScript. Right. This is the difficult thing. Yeah. Yeah. Does the name make sense then. I think it lately. We are not sure that that's something that we were discussing some month ago in our philosophical sessions. Karim. But even if it's not clear for everyone. What's areas is about right. I think there is some agreement that areas is a is a collection of RFCs. So, and what we are doing in this project is implementing. What's on the on those RFCs in the areas RFCs repository. So I'm wondering, I have to talk to us about about this. One of those is what's the relationship between the open ID connect to areas right now. I mean, is there any RFC related to open ID. So it's that the case I don't know if it's at least at the current status of the projects. I don't think it's, it actually makes sense to have that into the main repository. But, but as you as all you say, all of you say probably there will be some relationship with between both projects that say or I mean, especially if we are now considering to, I don't know if to marriage or what to do with the with the open wallet foundation that clearly will use open ID. But, and the, and the second thought was that most, if not all RFCs, well, not not all, but most, most RFCs in areas are related to this come. So, I don't know if it will be really useful to, to externalize that it comes support. Because otherwise, I mean, if we do so, we will always need an external dependency to make a project work. So, yeah. So just just to clarify, like there are two, I think two levels of externalization, if you will, of this. So what I was referring to was especially like it did come is now part of the core package itself. And the main repository because that's where the core package lives, but like should it be part like question one it shouldn't be part of core. Or can it also be moved from core still in the main repository but as its own module. So your to the question before that, yes, you're right, like most areas protocols not all but most areas RFCs are based on on did come. But if you look in in at I don't know what is it did come to the work or something the website that's maintained by this, those protocols now also live there. So, and that is where they are maintained, I guess, and and for now probably new protocols are developed they will also be become an areas RFC and then also also they've gone to come to the work, which makes it very confusing and difficult, obviously, but yes, absolutely. So, yeah, I don't know what it's a mess. Okay, I understand. I think it makes sense what you are saying about about living all the interfaces for the for the core package I mean to maybe to extract all the, all the proofs and credential protocols and that stuff to separate modules like action menu or question answer for instance. Actually, recently we had some a sort of of this extraction when we did extract the proof and credential protocols, the one I think we moved those to one on credit and it works. I mean, it was fine. So, so yeah, correct me if I'm wrong. Yeah, sorry. Those are those are only the implementations right. Yes, yes. Yeah, because that's the one. Yeah. But then again like because for v2. You can have multiple implementations right you can like that you have different formats, group format services and preventive format services again. So those interfaces. If we define those interfaces in core it's still like core still is a did come as a strong relationship to did come. So the question is do we want to make a separate like did come package and I think we have to be very careful with this because like if I'm just thinking about this, we will like just just extracting did come and related protocols from the core means we like the amount of packages is going to grow immensely. And like for then it would mean you have to install 1000 packages before you can do what you want. Which I forgot to mention in my presentation which is also something like in the last in the last option, like making it a very generic SSI framework. In that case. Yeah, exactly this. So, yes, what you're saying, like then if we do that we should we should really consider making sensible default packages. Okay, boom, one install command I have all those modules pooled in. Do I want open ID. Fine, I maybe do an open ID holder package and boom I have everything for the open ID stuff and then I don't know you can like maybe credential format specific stuff at their own date default packages but like if we're going to go that route we really need to do that because otherwise, that it will be so confusing. For me, it makes sense to make it more a generic SSI framework as well because I think at least what we've noticed is that when you're now building SSI agents, wallets, whatever. There's like, it's becoming less and less of the requirement like oh you need to build an errors agent know it's like there's different profiles and there's different things and you need to support them all so I think having separate framework makes things harder especially if if AFJ is the thing that combines the different implementations that are already there. And then having all the other protocols and exchange stuff implemented but still seeing it as an arise framework where did come is first class citizen but the others aren't then also don't make a lot of sense to me I think like if we're going to support them we should just support them. And means extracting did come out of core I would say so you can have a core that's lean you can add did come and if you add did come you can add all the different protocols for errors into a profiles and then you can also add open ID, and the core is just an underlying interfaces that connects everything, mostly also related to crypto so if you support like Edward signatures, you can support those in in all the arise protocols or things that need it, or in the open ID stuff or if you support the credentials that you can use that with both the, the arise issue credential v2 protocol Jason or the format or you can also use that same implementation across for the open ID implementation so that it all becomes like the underlying packages can be reused so that we never have to reimplement things but it is more separated I think in my head that makes the most sense. And then we do need to account for the, like, how do you set it up in a good way where it's not like you have to install 100 packages because I have also noticed that with the current version that that is already like quite a lot. I, I do, I do it very often like in creating and test setup with AFJ to test a specific scenario and like the increase from zero three, installing two packages to zero four where it can be like up to six or seven or something that makes it a lot of complexer but there is a lot more flexibility now which is nice but yeah I think that's the only thing we would need to like with the separate like splitting it up is like okay how can we keep bundled logic that you probably want together. For example, a IP one. Yeah, because then the question is, I think, like, if you're going to bundle these or make these defaults. On basis of what are you going to do that and I think intro profiles make a lot of sense to say okay IP one is one but there are, I don't know, like the European Union has their family has finished their thing and that has a name, then that might be a profile. But maybe there are other defaults, like, we should, we should not like intro profiles are one thing, but like maybe people would also want to use it purely as a difficult messenger, for instance. So, yeah. Then, then I think we get we get in. We need to. Yeah, really define what a bundle is and what it isn't. Or maybe it's okay to get to let me keep it completely open. And I think it's still if you like, but we currently have if you now want to build a did com messenger with AFJ. You also have a lot of things enabled that you don't need so I don't think it's such a problem that if you want to build that you just pick one that aligns with that, which would probably be like right I want to use did comfy to so I'm then choose just a IP three package. And if you have really custom needs you can always like create your own bundle that is lightweight. But I think, yeah, I think having some extra dependencies you may not need is not too big of a problem. I think that's the case right now. Yes, we are trying to like with this move we are trying to change that right. So for instance, like, like, to me it makes total sense to extract it come from it because that because right now you don't have a choice. And in the future people might really not want to use that come at all, which is, it doesn't make sense to any of us I know, but these monsters exist. So, so so the point here is also to extract stuff but then indeed you could also say okay well if you want to go that deep then then you'll have to run like 40 install commands yourself. So I, I'm just missing a little bit of a visual if you can if you could provide with a little bit of a block diagram of those things that'll be helpful. I can work that out. Yeah, I understand that separating did come and make it reusable. You mentioned for instance, for instance, I use case people who are using just an agent as a did come messenger. Do we understand how people are using FJ right now is that is that an opportunity for us to ask, ask around and sort of survey, like, how are you how are you using FJ is it just a, is it really just a areas and no credit agents. So, and yeah, sorry, go in. Yeah, so I just feel like I don't want to go around the SSI terminology I'll rather stick with VC, just another comment. Yeah, I just just kind of feel I need a little bit of a diagram to set okay what is. Okay, we're talking about areas framework JavaScript if I can create a mental connection to areas occupy cloud agent. I can see this being as kind of a some sort of wallet agent or areas agent whatever want to call for JavaScript. And we need to talk about, okay, there's a storage part that is independent of anything. There's a transport protocol that could be did come could be something else could be different types of credentials that goes through that transport protocol. And then there's W3C that is kind of a wrapping everything together I know I've been having conversations with Steven that maybe we should just move towards adopting that as the default standard that I know Craig always wrapped in W3C that would also answer that question. Yeah, not sure if I have there's more questions than answered that. That makes sense and I do think that diagram is a very good idea to see like it's okay if we would do this, how would because also how would the dependencies between all these different packages look like right because you would have like if we're going to externalize every did come protocol, they, you cannot use them just without and they come itself so all the protocols and they come, like the core logic of did come like then they would, that did come package would always be needed for all the other so it's, I think it's a good idea to sort of visualize the dependency that we would end up with. Yeah. And to be fair, I've heard comments about did come doing too many things. So, there might be a possibility that did come itself goes through a refactoring and split things up. Yeah. And as for your question like how are people using it yeah, maybe a survey is not a bad idea. Like if I just from from what I see in the community and here is I think most people are definitely using AFJ, especially currently for mobile agents and they like they always are usually do something with credentials. I think the pure pure did come messaging agent. I think I will demo created one, I think, but I don't think a lot of people are doing that. But yeah, I do think that that did come is such a broad, as you said, maybe it's doing too much or it's too generic it's such a broad thing that to me personally is a very sensitive diet to verifiable credentials necessarily, because it just has a lot of possibilities and applications outside of that scope. And, and to add to that, again, as a maintain of areas bifold, we do get a lot of comments and sometimes misunderstanding about what is bifold what is the FJ and I just recently had meetings about as we are using bifold is like, well, no, you're just using FJ, which is great. So, so I sometimes I feel like there's a little misunderstanding, even though I know FJ can be used as the issue verify and not just the holder part of it so it's more generic than that bifold is more focused on the holder part. But it's also evolving now with the mobile verifier we also have that. So, so I feel like FJ the way that I simply explained to other people is like for me, FJ is kind of headless UI agnostic bifold. So if you don't want to, if you don't want any opinionated way of how the navigation supposed to be that is the core that's that's what is JavaScript. And, and I don't, I don't know, I've been thinking about if maybe even there's a possibility that this could simply merge maybe bifold core is what areas JavaScript is. So I think the one, yeah, with the one thing there I would like to argue is, although AFJ is mainly used in mobile situations. It is, it is also possible to use it server side. We are using it ourselves for server side component. It's not super popular. But so merging it with bifold necessarily. I don't think that makes too much sense because yeah, that would sort of take away the generic sort of multi platform ish. That's fine. Yeah. And as I said, there is even even like every now and then I guess now there is a hype on AFJ as a mediator. Again, it's a feature that it's there and not quite sure how production ready that is but it's there. But I think we need to make those questions whether it is supported and and kind of endorse for for production use case and we should be clear when a feature or something is intended as a production or is intended as a kind of a playground or it's evolving right this is just a kind of a lab thing that may evolve to be production supported or it may just stay there as a lab thing. I mean I think I think we should intend to make everything production ready right if we merge it in so like a mediator. I guess yeah I mean if you can mediate and it's not production ready then then how much sense does it make to have it in the first place I mean they will definitely probably be a period of time where it isn't because of scalability issues but I think that should be the aim of anything we merge in that it should be used in production. Is this is anybody using FJ a kind of a as a scalable server side. Does it is it scalable can have multiple. If I'm running in a cloud open like Kubernetes does it support multi pods is resilient to do what kind of properties are features we we're supporting. By the way we're using it currently in the development. And I think I can share that we encountered some issues after some initial loading testing. We somehow managed to bring areas framework JavaScript storage to a state where it was really really slow. After testing it with thousands of requests per second or sometime we actually found that our storage in postgres become. Well I suppose that it was the storage but it's just become very slow. So it was the case. On our side. But in future we plan to make more tests and load and scalability tests. And right now we use only one instance for generic agency and honestly the same for database. Of course, we don't keep a high load in this situation. And during the next few months we will have a lot and scalability test and of course, we'll be happy to share our results. Yeah. Yeah, I also have some more questions about mediators so by the way, do we have some deployment or public mediator that based on FJ currently. We have a like a deaf mediator but it's like not in a it's it's just for development so it doesn't it doesn't set up to handle very high loads or these kind of things. Yeah just for the context recently we encountered some strange problem with implicit mediator strategy pick up pick up strategy in areas by fault and FJ based mediator. So basically we connected areas by fault to FJ based mediator to implicit pick up strategy. And there was a case where we just restarting the areas by fault app and we can't receive any messages from mediator later, but this is not the case for pick up protocol version two. We just change the conflict and it's just become all normal action. Yeah I would have advice against using the implicit way because there's, yeah, quite some limitations with how it works and how many messages so I would recommend to use pick up feed to either way. Actually that implicit support was mostly left to support what's in Akapai right it's not something that is actually standardized. So yeah I noticed that most of the mediators are using Akapai and yeah with Akapai based mediators there are no issues whatsoever. And I think I will bring together some details about this issue and probably will create an issue in areas framework repository two. Yeah maybe it's just not critical as you're saying that implicit strategy is not really good but at least for the record, it will be useful I think. And I think on these things like scalability is one thing I would like to explore more over the coming months is also of not using like Oscar as a encrypted database, because I think in a lot of scenarios like using a custom layer that encrypts all data and I think that there's, I think a lot of performance gained to be held from just using for example, a relational database directly without encrypting everything and I think for a lot of use cases for as a mediator. It is not really needed to use a secure encrypted Oscar storage as long as you have your keys managed in a good way but like using a database directly which are really built to scale. There are insane amounts of like traffic and records I think we can have a lot of performance gain in using it in the server but we have to look at okay how can we like correctly map the records we're using an AFJ to like relational database structures and then these kind of things. That's what I was going to say. Isn't the problem or the main scalability problems related to the storage. Isn't this happening also to to occupy. I have seen in the in the latest month that there were some concerns in a cup by also to for the for the mediator scalability and what mostly for mediators right but because of the handling of the Web sockets and that stuff. But also for for issues. It's a little bit different. I could buy does abstract that out so you could use a relational database and, and see the records being encrypted so. So, so again, it sounds like we're evolving a little bit more there so that storage layer I think yes, I think it's, it's probably worthwhile to abstract that out and not necessarily have a strong dependency to ask our directly could be something but I just want to make a note, since the Timo you put mobile holder wallet, I just want to make sure that that is evolving right now that mobile wallets also verify it. And probably be a issues as well as new issues issues will be coming. Yeah, I'll put that on a separate separate line because I think it's like a difference in use case and how often. Yeah, and I think, I think mainly like mobile is a bit easier in this case because you don't have the scalability issues. So I think like a mobile is your wallet we probably also work fine it's just that when you go to the server side and you want to handle like a lot of traffic then. Yeah, there's still a lot of limitations in in AFJ probably and also in the storage layer and everything. I think in mobile it's a little bit of a different lenses is not scalability in the factor that we, we're not going to have multiple copies, but performance issue important. We wanted to be super quick startup. So, so, so the startup the performance the loading has it's important, but not the scalability and redundancy point of view. And also what we are facing at the moment in our app, you know that our application is, is mostly a chat application based on the FJ. And when we, we have to manage lots of several events, like, for instance, receiving a message. We were marking things, I mean chats as read or something like that. If we are going to, to rely completely on, on, on AFJ storage. We, we are having some, some problems on that. So, what we are doing right now is, is to, for the moment is to offload some of the, of the parts of the application to, to another kind of database like realm to, to manage those events in a more lightweight way. It's not easy to admit, at least for us, which, because we are not so experts on how to recognize the one that stuff, right. But it's, it's a bit difficult to, to get some instant reaction of the, of the events when, when they come very fastly, I mean, several times per seconds, or more or less. And, and also another issue that, that you already know, Timo, because we were talking about that in the last month as well, it's about the, the pagination, which is, which is not easy to, to, to have in, in a secure database like Ascar, or, or in the, because even if you, you can support the offset and the, on the limits. If there are, if there are some new records added to the, to the, to your query, to your query, let's say you will need to handle the pagination in a different way, for instance, by by taking the, the records before that some particular date and also order the records by date, for instance, by created at, for instance. And currently, the sorting is not supported by, by Ascar. At least not for, for the, for encrypted tags, because it's not possible to sort when you have encrypted that tax, it's something obvious, but, but, but it's, it's a problem in, in such cases. I think we can make this a topic to discuss in the, maybe next week or in the future on like talking on these issues. Because I think they're very relevant, and there's a lot of improvements probably to be made. And it should be more flexible probably so I think we can pick that up in the future, and probably, probably also something we can pick up separately from like the future architecture of Ericsson JavaScript. I see we're at time. I think this was a good discussion. I don't think we came to a conclusive answer. I think we are in a, in a, in a direction. Like, we need, like, I think people liked the idea of like having a more generic SSI framework, just need to see like what's going to be included, we won't be able to do, make the change in one day anyway. So, maybe we all think a bit more about like right. So, if this is going to be more of a generic framework, what would that mean like what would the structure look like cream can work on the, yeah, we can ask around a bit and then also like what would that mean like do we still have an AI framework in that case then what is the scope of areas I think we can continue that discussion. Yeah. Yeah, I'll, I'll try to write up or draw up a diagram for next week. Perfect. Thank you. Yeah, thanks everyone and thank you. Thank you. Thank you guys. Thanks goodbye. Bye bye. Bye bye. Thank you. Bye.