 Good afternoon everyone wondering whether we are in the correct meeting actually, because I think they recently changed the the meeting link again. But since we're all here, I don't know if I'm going to quickly check the other link and see if there's more people there. Wait, I'll suppose to hear without come back. No one in the other link so I think we can just use this one. All right. I was just checking is the high pressure wiki down for for you as well. Let me check. Yeah, it seems to load so I think so. Okay. We're gonna do it with. How can be for today. I'll try to convert it to to the to the wiki if it's back up again. Cool. I think we can get started. Small crowd today. Why that is. But yeah, let's get started. Welcome to the air soon just group group call of June 29. Remember you to bite by the high pressure code of conduct and antitrust policy. So, well, I recognize you on the call so I think we can spare the introductions feel free to add yourself to the tennis list if you wish so. Any status updates. People want to make. I think clay show the shared components and update to fj for zero for zero is finally been merged right. Yep, it's finally merged and in by vote and we are. Yeah, no, it's working great. A few hiccups kept bugs but nothing, no show stopper so awesome work. Cool, that's great to work to our greats to here. It's been a while so happy that's finally over now and that it's working mostly as it should. There was also bifold call this week. No, don't buy for this work. Cool. As I could buy. Relevant update from a call. I did not attend my meeting. Okay. Then for the gender for today so the wiki was not online so I couldn't look at like we had a long list of topics from last week that we in the end didn't get to but I know one was focused on like the zero for zero release now it has been now that it has been released. So you want to talk about the future of fj right. Yeah, I want to. I've had a few people reach out to me about areas components and the state where all of them are and I want to ask you the community about it. Talk about it how how does other command components fit in. And what is the vision for a fj. Anyway. Cool. Yeah, I think we can go for that today. And the other topics. We want to discuss with the people want to ask to the agenda. Okay. Oh, yeah, go ahead. I'm sorry, not an agenda item per se, but I opened an issue to update the documentation for the storage config parameters. But I didn't quite know where to look for did do that completely. So if anyone wants to point me to where that lives, I would be glad to do that. And so, in the docks repo. Sorry issues. So I figured out how the memory database actually ended up working. But this issue was to update that because you put on that link. It just has the, you know, like a, it takes a key and a random random type of keys and values. So this issue is to update the documentation for that. Yeah. Okay, so you're mostly about. Using the. In memory option, right? Well, yeah, no, so I figured that out. I was just, if you click on that link on the top. I was going, this is an issue I open it. I can update this section right here. If someone can point you where that lives like there's a Postgres section right for storage that has a bunch of key values down there. And then there's some SQL it ones that aren't really documented anywhere. So, so the issue is an offer to update the storage config with the various back ends. So that it's not kind of looking for various things all over the documentation. Yeah, makes sense. I think it's. Maybe Ariel knows this, but like, it's the storage object. It's different. Is it different between. Oscar and in the SK. Yeah, right. They are similar. But yeah, there are some different configurations, both have the type, the type field where you said if it's a light or if it's a postgres. So there are some other parameters like, for instance, with the timeouts and some other stuff. Usually used on the Postgres, but, but it's a bit different. Right. Yeah, so yeah, if I can do the documentation update if you guys will just point me to where the config options live for reference right. Yeah, okay. Yeah, and then we can probably add a section on both how to do it within the SDK and with Oscar. And then once we update the wallet API a bit more we can separate it a bit more between the two. Yeah, Ariel, could you add some pointers on like for the different options or Okay, I will, I will add it to the, to the issue so like I said, yeah, how it works. Because yeah I'm glad it's on tension I just wanted to make sure I was doing it right. Yeah. Cool. Awesome. Okay. Be as well to know there is an issue that that we encounter doing the bifold wallets about the auto linking link secret creation. Yeah, this one. Right. Yeah. Yeah, so issue is link sequence art created by default anymore we expected that out of the wallets and now you have to do that manually. And then a PR was created by Jason to automatically created. And we had some feedback rounds on it. I think there were two. Yeah, two, two things to consider here I think is one, where do we create the link secret if you want to create it by default. Taking into account, you know, to Tennessee. Maybe that you are not going to use AFJ as a holder. So, then it wouldn't really be needed to create a link secret is it. Well, does it matter if you have a link secret that you're not going to use, I don't know. You also need to make sure. Or maybe that's a consideration like race conditions if we do it in a request credential call and you request two credentials at the same time then they could both create a link secret for example. Yeah, any thoughts on this. Yeah, so, so from our perspective is was really about kind of the, the, the usability from that perspective that is like, we expected that that when we initialize the agent things would be ready. I think where exactly is going to be initialized, I don't think it's that important, more of the expectation that when the agent is initialize it's fully initialize and ready to go. Okay. Ariel you left some comments like do you think what what needs to be changed before we can merge this or No, actually, I was, I was saying that that that you're right about about this issue on the on the multi tenancy. But if we are going to to add this logic to the credential request, or the first credential request, for instance, it will not be so or I couldn't find a very straightforward way to to add it to the to the code in a clean way. One of the issues is what what what you have mentioned recently today about the the race conditions that it's certainly possible, but also to, you know, we will need to be calling to the from the other service or from the from the credential format service which is a little bit weird from my perspective. So probably, probably, we can, we can keep it as a JSON implemented because it will be any way an optional parameter. Maybe we can do it. Maybe we can do it false by default, if you want, instead of being true. And so, where would we create it in that case. No, no, I mean in the, we can keep it as a JSON implemented now in the initialization, it will solve this. I mean, it's, it's simpler. But in initialization this this method is called only runs right. Yes. So it won't work for multi tenancy. It will not work. I cannot find a solution to to to be confront to everybody but if we are going to do it in the in the credential request we have this program you mentioned about the race condition that is possible. Not likely but possible. Yeah, I think it's very unlikely so maybe we can go ahead. With that approach. I don't think it would be a race condition right it would be more just that you have to link secrets while you probably want one. Well, yes, but that's a problem. Yeah, no that's that's very true. That's true. Is, is that a little bit of architecture problem there's a system in initialization but there is no tenant initialization process for each component. Is that what I'm hearing. Yeah, kind of. Sort of we have into the station of modules but modules are more meant to be global so I think like this initialization is more if you need to set something up for your module in general that is not related to a specific tenant so for example. It is used by the individual module to connect to the ledger on agent startup, but like the ledger pools are shared by all tenants so that is like not a tenant specific action. We do have an agent initialization. But the. This is like a custom package to our crates package. And so we don't have custom module initialization for each tenant. So that is a limitation. Maybe. Yeah. Yeah, so we have implemented a workaround by phone I guess it's just up for discussion. I don't think you don't have to accept it so you can leave it let it simmer for a little bit and see where it goes. But others might have issues so if there's a way to at least raise an error somewhere how identify and tell the user like hey this thing should happen. Yeah, I think it's weird that there wasn't a an error thrown because it should show an error if we look at the at the code base. And we look at the unknown crates RS holder service. Great credential request. Here it in here. It looks for a link secret ID if you want to use a custom link secret. If not, it tries to find the default link secret and if it does not find it. I, it throws this error. So are you, could it be that you're swallowing the error or that AFJ is maybe swallowing the error on some layer. Maybe it could be. I'll ask Jason about how, how this surface. I can get a little bit more information about it. Yeah, I think we can maybe like the race condition is a very, very small chance so I lost. Maybe it's fine to have that race condition. I'm not, I'm not going to shift that is the intent to have one link secret for all the tenants. No, you will have a unique link secret for tenants. So the default link secret that is being fetched here is for a specific agent context and the agent context is different for each each tenant so this will return a different value for based on which tenant you're currently interacting with. Yeah, the bad thing about that is that we have, we will need to implement that in both older services I mean in the unencredited race and the in the SDK and we have to make sure that we will not forget when implementing another if in if we are going to implement another older service. Okay, so if we implement in the older service we need to do it twice. I think yeah it's it's not the biggest change so having to implement it twice is probably fine for this. Yeah, so based on this what do we think would be the best approach here. I'd like to do it in the in the holder service, probably, but I mean it's, it's, it's a, I think it's the more straightforward way to do it right now. But I think we will need to find a way to do what you put there about the initialization for our nation context, especially because we already have this issue on the mediation. And we will probably have it for other models as well. Yeah, I think that's also my preferred way to do it. Okay, so sorry what do we mean by holder service is that live it in externalized. So it will be in here so in here instead of throwing an error. Okay, hold their service. Okay, got it. Yeah, and then we'll do the same in the in the SDK older surface. Okay. Have you thought about how we're going to do the duplication of the in the SDK how is that going to be communicated setting the roadmap. What do you mean, exactly. In this in the SDK, I think about the in the SDK rest library that we just went through for removing and replacing. Yeah, is that what you mean are talking about that old one. Yeah, yeah, so we still have here, because we didn't want to make it like you have to move over now but like allow for periods so we still have support for the in the SDK service and that has the same create credential requests. It has the same check here so we just have to do like the default creation two times. Is is the go to keep supporting or duplicated. I think deprecated as soon as we can, I think we should keep it maybe in for one or two, two versions more. And then remove it. If it's not needed anymore, I think, yeah, would would be really nice if we can get rid of it sooner rather than later. Do we need to start adding some duplication markers or duplication warnings that this module is going to be deprecated. That's good one. Yeah, we have for new modules we in the module we now have this warning. I think we can add an extra parameter and could have an expected breaking changes when using this module. So maybe we can add like similar warning but more like this module is deprecated please migrate to this and then we can add a link to the documentation. Yeah, anything else on this issue. But just about checking so right now it raises an error, I imply that instead of raising the error wheel out of create. Yeah. Okay. I think so I do we need an option for this. So you can choose whether to auto create it or I'm not too keen on adding more options so if the if the default to its make sense to create a link secret then maybe we should just create it by default but yeah, maybe we need to add an option for this. It's a, it's a computation option. The auto create secret or something like that. The question is if it will be true by default or like Jason did, or if it will be false by default. Currently in the in the in the in the SDK is it automatically created a link secret or are we doing it manually, or preview. In, we do know it's automatically created when you create the wallet so the wallet. When you created the wallet we also created the link secret. Okay. And you had the option to pass the link secret ID because that is a use case we've heard I think from the app side team or they already had a link secret in the wallet so then it wouldn't be marked as the default and a of J but they did want to use that specific link secret ID so if we Yeah, we need to look at a way how to Yeah, how to make sure that still works. Yeah, should that also be an agent option then like the link secret ID you want to use or No, I don't think it will be an agent option that You can then just use you can then send set out to create link secret to false you can manually create the record and stuff probably. Yeah, because also you, you, you can also specify the link secret ID on the on the other services. So, you can also have a you can always have a way to specify your, your own ID for each flow. Yeah, it's fine. Okay. Yeah, that sounds good. Cool. Then. Maybe we can talk about the future of J or Let me see. I also wanted to give a short demo of a We can do that now is of a wallet we've been working on that's built on AFJ that's also open source. Let me see. So this is the repository. And it's also published to the to the Google Play Store and the app stores. And it's currently a very simple wallet. It supports receiving credentials and sharing them and it's fully built on open ID for verify credentials so it doesn't yet. But it doesn't yet support a difficult morano crats or any ledger at all. It's fully It's based on the web that key did J2K. So no blockchain and it also supports J2K credentials. I think. Yeah, what I really like about it is that we, yeah, it really shows that you can now also use FJ to build stuff that is not necessarily high pressure arise or high pressure in the or high pressure on crats but you can also build use it to build a Open E for VC wallet where you still use the, the, the core of the framework for the crypto and the tits and everything. So, yeah, the only we have in terms of oh it's not here it's in the the apps. So we use Oscar for this one but not in the VDR or on a crats rest so just Oscar for the crypto and the storage. And I can do it. Quick. Then my phone. You see my screen. Yes, perfect. So this is one of the flows like it's it's it's a part of a huge intro profile we're working on that's based on open view for PC and that's what we're also been working on with this blockchain coalition and and so I can start off by getting a credential. And if you want you can install the wallet from the stores and also test it out. I'll post the link here. Also the repo link here. There's all the links also. So I fill in all my fields. And just for the demo purpose normally this would be derived from someone else. So, once I have done that, I can open my wallet. I already have quite some in there. And then I can receive a credential with branding and the credential the attributes we just had. Now it has been added to my wallet. And the next thing I can do I can now use this for several use cases but one of them is signing into the digital coalition website. So I can scan this cure code and I get a proof request and it says like red. Which fields we want to share and under the hood this uses the presentation exchange specification from this. And so I can request I can accept it. It will be shared and then I'm signed in and you can now see I'm signed in as Timo. So I think, especially for cases where you do want to do sign in. And the PC stack provides a quite streamlined flow, because it's basically all and all that stuff which is, yeah, being used primarily for authentication and stuff. So, yeah. As I said, open source so feel free to to run it yourself or modify it or build your own wallet with if you would like. Very nice. So, did you manage to to to get it published on the app store in Apple because I have seen in your Twitter that you got rejected rejected because it was too similar to what it said. Yeah, we got rejected and then we published it like with like all the. So, like all the previews we have we removed those and they accept it and then we tried. In the end, what did the trick is we removed the title wallet here and we added a logo here and I think that's what did it because if you look at the Apple wallet design. The title wallet here as well and I think that was causing it to be very similar but yeah as you can see it looks quite similar to to the Apple wallet. But I'm happy they accepted it in the end. Yeah, that's fine. That's awesome. Cool. Then. Next topic future of a fj. Do you have specific topics or like questions you want to start with clay show or do you want to share some slides or do you want me to go ahead and just start talking or how do you want to approach. I don't have any slides. I actually just answered one of the question it was about expo so that the wallet that you guys are creating it. It seems to be was done using expo right. Yeah. So the question that I get, I get people reaching out to me on a fairly frequent basis asking about Oh so there is a wallet. There's a bifold wallet. And there's a whole bunch of components in this airs ecosystem. Which one should I go where do I go right. So of course we like fj and the shared components and the solution that is that is happening, but it's also a whole other libraries out there. So the question is, is the goal for fj to remain JavaScript native in a way although there are a few native dependencies already. So the goal to to maybe facilitating that the rapid development that maybe was having issues with india in the SDK and some other stuff under the hood. I understand there is a flexibility into enabling that fast development in the JavaScript side it's easier potentially cheaper to develop. So where we're starting is that persistence in the in the ecosystem across different implementations. Is there an opportunity to to start moving as maybe VCX matured then AFJ just leverage that or did calm. Stabilizes and there is leverage of the did come from from this. There's a rest implementation or something like that. I'm just trying to understand a little bit where, where do you think the project is going to go or where's the vision for now and what do you think about the things, the other things that are at play and that's a good question. Anyone that that wants to have some talk on this already or right then I'll give it a shot. So, I think, yeah, one of the things you mentioned is like having a lot of it implemented in in TypeScript JavaScript allows for quite flexible development. I think it's nice like there are maybe some downsides to using JavaScript and some things that you maybe wouldn't have implemented in Rust, I think, probably, like in the end you can run it in more exposed to more languages if you write it in in something like Rust, because you can write rappers and the performance, probably also better if you write it in Rust. So, I think there's something to say for it. I am less fan of having a lot of it implemented in another language because then it becomes complexer if you want to do. You either need to have a very minimal API exposed in the wrapper. Or you have a very advanced API that means the wrapper layer becomes really complex and I think also FFI has quite some performance impact so that you also lose a lot of the advantages of having a fast language like Rust for example. So then I would rather say you move mostly to another language. But I think in terms of future of AFJ, I think we probably want to like add more features to make it more suitable for I think a server environment that's something we're really interested in now it has been used a lot in mobile environments but we're now starting to use it in server environments and want to actually start using it on a large scale like having managing hundreds of thousands of wallets in an agent. So there's definitely work to be done there because like we now have no Tennessee and but like there's definitely components that are going to break on that skill. And I think making it more modular maybe extracting some stuff like there's a lot of code in the framework which also adds complexity so I think Berent has lately done some great work on like writing some smaller libraries. Let me see if I can find them here. Yeah, so like implementing selective disclosure jobs and implementing dits in TypeScript so as like, yeah, more very sculpt libraries, which allow you to parse a date create a document and have the validation in there. And I also ask Berent to give a presentation on that. In the next few weeks, I think, yeah, so extracting more code over time out of the framework and making them general purpose TypeScript libraries is more of the direction I would see it going then moving stuff to Rust, for example, and having it in another language because I think with that we could remove some complexity from the framework itself. We could make it usable for other libraries for example you have the forano framework and if there's like general purpose libraries that we can create we can share some, some code between those frameworks as well. In the framework AFJ really becomes more of the glue that glues together the different libraries so if you want to use dits with SD jobs. AFJ would depend on both of these libraries and make sure they work nicely together instead of you having to write the glue between those different libraries but you can always directly depend on it. Yeah, I think that's why I see it mostly going I don't know if people have things to add or like talks with this. Well, I think you can, there is a, there is a remain discussion about the, about moving on to the open wallet foundation right you asked me about my opinion about that last week but you didn't respond. Yeah, sorry, I, I've been really busy with. We had deadlines for this wallets this week so I abandoned all of my other. I think that some, so something I'm sorry. Something I'm thinking is that now that there are some other, some other libraries also written in JavaScript or TypeScript like veramo. What's the different that what would be AFJ position against those other libraries that also somehow serve for the same purposes. Because, you know, with veramo you can also deal with deeds and this is maybe not an address but this is in general, and also do some did come and implement some custom protocols as well. So, maybe if we are thinking or moving towards the, the open ID for VCs approach I mean, if we are going to support different, different transports. We are moving to the open wallet foundation maybe that could, that could be an opportunity for AFJ to become a more generic or more general SSI framework like we mentioned some weeks ago. Yeah, that makes sense. Basically, you also wanted to say something. Just want to share like this document, which I'm trying to figure it out and get confused with all those governments acronym so is this Dutch government. Yeah, yeah, I think I shared this with John last week. Yeah, yeah. And I've seen this question over and over again about the, again, mobile development is like, do we go native, do we use something else right. And for me, it's less of what is the language that is developed, but it's more of like, okay, what can I build on top of it so if it is a react native and and and job and JavaScript and provide SDK. I'm not concerned about how pure is that implementation is as long as it's working, and I can work in in the language that I chose for whatever reason that's fine. I think one of that they make it's about this kind of a cross platform compilation, and they mentioned phone gap and react native and flitter and those things come and go. So, so it becomes less less agnostic so that's that's my, that's my concern and in my point about it. But that's fine if the intention is to to remain that kind of a more closer to nodes development and no language as well. That's understandable that's a direction that the project want to go. But I just also want to raise that in the scenario some some all that would automatically get some government automatic exclude this, this framework, right from the get go. So it depends where where you want to go so so I said I've had people reach out and asking to me about integrating existing applications into their adding verifiable credential or or I did calm features into a app and existing app existing that are not necessarily written in react native it could be written native code. And that hasn't been that smooth for what I understand. So it's just a question for the community where would they want to go I mean there's no right or wrong it's just where do you want to go. Yeah. So that's a good thing yeah I think. So I guess that the make the main the main topic is do you want to remain as a areas JavaScript framework or it's more of, I don't know if I can compare for instance to AWS SDKs that behind the scenes they call executables do whatever it is that needs to do. And that is compatible with some interface right so it doesn't, it's not necessarily fully implemented although there's some sometimes code duplication, which is fine. Coding duplication is not all bad, but it's just, I just want to ask the question. Yeah. Yeah, I think. I think there's a lot of like assumptions in this document that I don't agree with, I think their take on cross platform development and then all these things. I don't think they're the right assumptions they're making. But that aside, I think it is an issue that like you can build natively in iOS and Android easily with this tech. The question is always like in the end. Do we need a single implementation. For all use cases, or not. I think having it implemented in rust can work. I know, for example, like the, you have the spruce ID libraries, which are. I think they have. Yeah, the did get. Which is written in rust, and I think it exposes. They expose it to a lot of different languages, which is nice and I'll now shoot to build an iOS and Android and in Flutter and I think red native was on their roadmap maybe. So, I think, yeah, that's, that's something that would work in this case. But I think it can also sometimes add a lot of complexity if you want to have the same thing working in all environments. And if you look at, like a, a lot of libraries are just like if you look at JWT libraries. They're often now just implemented in every language again. And the question is like, over time, I think more and more libraries will come available for this like you have more did libraries more. They would see as the job libraries, VC libraries and then. Yeah, if we also get that for Kotlin, because I know a lot of people are now working on Kotlin or as the job libraries VC libraries and if we then also get that for Swiss for example then it would become a bit more like you can now have with development where if you're going to make a mobile app, you often have like different dependencies to achieve the same thing, which isn't always the easiest, but yeah. So, I don't know if that answers your question it's not a very concrete answer. But I would say it is a problem but I don't think it's a problem for AFJ to solve. That's her. It also depends really on like we, when we build wallets we for now like we've always been in the, in the situation where we can choose react native or we start from scratch and then we choose react native so like it has been a limitation for us and I, there would be not a lot of cases where I would go with writing to wallets in Iowa as an Android separate. I think separate from having to do it two times I think there's a lot of complexities in building native applications that are just abstracted away for example with with expo. Yeah, but that's also my personal opinion and we're a small team so yeah different considerations to make. I think Charles you wanted to say something. Oh, no I didn't want to say any particular. I kind of agree with the glue. The glue comment the glue path seems like a good one. This is a beginner comment. The reason I was attracted to the areas jobs for framework was for the chance to do rapid prototyping in react native. And then if the idea plays out, maybe making that decision to reimplement or, or, you know, adjust from the framework from there, but, but that seems like a goal that that that is that draws people people seem and I talked to him about it, about oh it's in reactive, we can do it really quickly. That kind of thing so that was my only comment on the issue. Yeah. That makes sense. I think something that might be worth investigating in the far far future would be just instead of anything with ffi because what you mentioned is there are performance drops in ffi. And there are small use cases where like calling something over ffi to rust is actually faster implementing it in typescript. A lot of times is faster than going over ffi. But looking at WebAssembly would take a lot of those things away you don't have to deal with unsafe ffi wrappers. You have a unified interface, it is, it works very well it's composed to WebAssembly you can reuse it within Node.js browser and well very sketchily react native right now. And I think if at some point reignited themselves would support WebAssembly. Then that would open up like, I think a lot, because then we can, well we do get some performance back for using a WebAssembly or a Rust library compile to WebAssembly. And we would be able to reuse it because right now we what we did with shared components we have to reimplemented in Rust and we are reimplemented in or sorry Node.js ffi and also reignited for their specific turtle modules, which is a bit of a or was a bit of a pain and will be a pain for maintenance. So my preference from that experience will always go to if it's possible to implement in typescript, implement in typescript if you're going to use the typescript. Also I think if we have like the shared components right now with if there is an issue specifically for AFJ there are not all the people in our AFJ group that could pick those issues up. And we have really rely on Kotlin or Swift libraries for example to to get the job done and to get the end product, then the end product works but if there is a small issue. Yeah, there are probably a lot of people in our team that could just fix those issues because we are experienced is not in those languages. So from a maintenance perspective I think it's, yeah, quite important to, if it's possible to stick to typescript, because that's where we are experts in and that's what we can maintain. Yeah, makes sense. Do you know on the performance trade-offs between WebAssembly and ffi? I think it depends on the exact thing you want to run because there are all the benchmarks like comparing pure Node.js ffi and WebAssembly with just running like Fibonacci calculate the 1000s number which is like they're completely useless benchmarks. I, so I'm not 100% sure, but I do know that working over WebAssembly and working over ffi, working over WebAssembly is a lot easier especially with libraries like wasn't bind gen which just generate complete typescript interfaces for you to call those WebAssembly libraries. And with ffi now we did it together and it's, it's, it's a lot of manual labor and you have to align certain structures because they're aligned in C. So if you like, if your property is in the second place instead of the first place in the class then it won't work and like tools like wasn't bind gen that they just take those complexities away, which is so nice. Yeah, I would be very hesitant to use WebAssembly right now for Reignative. I think you use standard ones and select that there's, there is an implementation working of WebAssembly and Reignative. And I think I also once got some functions to run but very minimal. Yeah, I think if we want to support WebAssembly it will be if Reignative themselves implemented because then you know you have some support it will be a lot more stable. We cannot hope for it to be more stable I guess. But yeah so it's probably in the far future, I guess. Cool. Okay, make sense. We're out of time. So, yeah, I think we can close it off for today. If you have a topic you would like to discuss next week. Please let me know. I think there's some topics left hanging from last discussion so once the wiki is back online I'll make sure to get them out and we can continue that discussion. Next week. Cool. Thanks everyone. Take care everyone. Thanks. Bye bye.