 Today's meeting cancelled. I was wondering about myself. Yeah, I'm just writing them on a slack if it's happening today. So, let's see. Good afternoon everyone. Can you hear me? Yes, I can. Hello. Hello. I'm sorry. I forgot about the time completely. I was working on AFJ and I was very deeply focused. Quickly making an agenda, and then we can get started right away. All right. Let's get started. And welcome everyone to the Erasmus JavaScript workgroup call of July 28. I need to remind you to remember to have ledger code of conduct and anti-trust policy. If you would like to add yourself to the tennis list, feel free to do so. I'll just link in the chat. So, yeah, any status updates from the, we had a call two weeks ago. Any status updates you would like to share? There was an Aries working group call yesterday. The discussion mostly focused around some work that's been done on marketing copy. And the results of a survey that we're informing that marketing copy. So, and there were links in the, in the meeting notes to the survey results and to that marketing copy proposals. So if anybody wants to go and look at those. They're available. I think the intent is to make. Apply the changes to the main wiki sooner rather than later. And then iterate on it as necessary to try and get some of the benefit of the rework that's been done. That's number one. And there was also a presentation given on. Aries VCX, which is a library. Written in rust. That uses a whole bunch of the other rust libraries to provide a bunch of the Aries functionality. The intent is not to provide a complete batteries included agent, but rather all of the stuff that you would need to construct one or wallet or something else. Looks like they've made good progress. And there's work underway at the moment to provide great support for Mozilla's ffi project to export or describe all of the rust bindings to their primary API so that they can be made available in other languages. And that's using unify or Yes, I believe so. Okay. Cool. Thank you. Any other updates. The load testing framework. That's under the Aries mediator service. We recently used that to test over 12,000 users simultaneously. Cool. That's the soccer dog. Right. No, that's the load testing underneath the Aries mediator service. I'll drop a link in the chat. Okay. So this is a test year run to to test mediator load and you had 12,000 concurrent open sessions or So this is, it can be used more than just testing mediation has some other tests inside of it such as issuance. We're also working on adding verification workflow to it as well. So this is a test A of J as the client. He's as low as test the orchestrator. Cool. And so the difference with like the the air ice load generator is that this is one is fully focused on mediation. No. It started off with just mediation. We've added issuance into it. We're working on verification flow right now. Okay, cool. And do you know how it's comparison to the areas low generator. The areas low generator my understanding is that it starts up all of the services. The concept here with the areas mediator services it's focused on being a client to an existing infrastructure. Right now the issuance and verification flows focused on an API API end, but I'm sure it could be modified to use any other issuer or verifier as long as the end points updated, because it will contact the issuer and the entire API end points to request the connection and request the issuance or verification. So this is intended to be able to point at some areas infrastructure to be able to determine what its load characteristics are as opposed to the load generator which sparks up its own infrastructure. So primarily I guess to test. That's things don't tip over. I guess that would be the primary difference in the approach. Yeah, the goals to test the structure. That's existing. Okay. Good. Sounds interesting. Any other status updates. All right, I think we can get to the gender. Any other specific topics people would like to discuss on agenda today. Last time we went through a lot of the poor requests. And so, yeah, are there specific topics people would like to discuss otherwise we could maybe do also a quick quick tour and the poor requests again. Yeah, let's do that. I think there's a lot of progress being made. Maybe it's covered in the in the poll requests, Timo, but I would be interested in knowing where the work is in terms of supporting the newest versions of like expo and react native and dependencies and like. Yeah, and so the newest do you mean expo 49 and then or Warren, do you mean like the latest like expo 49 or what is meaning specifically. Yeah, I believe so I think there was work intended to be done to get like beyond react native 68 or 69 and and the related expo versions. I don't recall the exact version of nurse but Okay, yeah, so that work is is completed. And so we haven't tested with the latest expo version, but that came out like, I think two weeks ago or something. But I don't expect too many issues, but we have tested it with like we got it working with the latest versions and bear it did some very complex things that you make. We go to the, for example, the address. repo. So react native. It was mostly with Android, I think. Yeah, so. There's now custom logic for different react native versions. And as you can see it works like we have tested it upwards to zero dot 71. We haven't tested with zero 72 but that's also just came out so I think it should all just work out of the box and everything with auto linking and with an expo project. So if you would like to have an example is the Erdan wallet repo, which has an expo app in here, and that uses. Let me see. It uses react native zero dot 71. It uses the latest areas Oscar release, and it uses if j zero four zero without like native code so I think this this you can use this as an example if you're looking for how to set it up. Does that answer your question or. Yes, that's great. Thank you. Perfect. Yeah, so, and we need to. Yeah, add some more documentation exactly on how to set it up but it should all work. Cool. So, any PR people would like to discuss I haven't had a lot of time to to look at the hours we discussed last time there's some reviews I need to need to leave. Any PR people would like to discuss. Maybe. Then there are some issues we can maybe get some consensus on. One is that started in another PR for some updating of the samples but it's currently like with the rappers that only work in. Or like only in note 18 while we also support note 16 and it adds a lot of complexity is that we make the rappers only support note 18, because they basically already do. And the patched patched rap nappy to those rappers so you don't have to do the custom resolutions anymore. And we update a J to only support note 18 and we drop support for note 16, which is a bit ahead of the end of life which is in September, but I think it would make the setup a lot easier and improve performance so I'm curious if people are. If someone is like against dropping support for note 16. So this will be in zero dot five, because like it would be a breaking chain so zero dot four will keep support for note 16. Then for item. I was only successful in launching the areas workshop demo and as well as running through the tutorials of hyper ledger areas JavaScript by using note 16 on Linux and WSL to Windows Linux. I tried note 18. And it gave me a lot of errors. So I'm not for doing away support for note 16, primarily because of a lot of troubleshooting and blockages that I experienced. Okay. So, have you opened an issue for that or. I have not because I was successful with getting it running on note 16. I can log the issues for note 18. Yeah, if you could do that because usually what we do is when a note version reaches end of life, we will remove support for it. So that would be in September, which is like not that much in the future so if we can get that addressed. That would be great. They're like there may be some issues with the, the Linux sub shell on Windows where it's not working. So are you running it with India CK or with areas Oscar. So I just npm installed based on the tutorials based on documentation, and that didn't work. So it was just using the areas JavaScript online documentation. There was no mention for India Oscar prerequisites. Okay, so are you still on zero dot three. I downloaded the zero dot four zero repository and workshop demo, the one that was hosted last week. And I ran that successfully. But I think the older tutorials might be zero dot three. I don't think it's it was the latest actually because it's based on the documentation online. Okay, yeah. And then I think you're using the latest especially if you also followed it from the workshop. So yeah, then please open an issue. And then we'll take a look and then we'll make sure that that is resolved before we remove support for before we drop support for node 16. It's it's called Windows sub shell for Linux or something right. Yeah, WSL to Okay. What's your username and get that deniker 86 DNA I CK DNA. Okay, you posted in chat. Yes. Okay, any other concerns with dropping support for node 16. Okay. Perfect. So I just have one other comment I guess which is, do we know whether this will create a problem for the bifold for folks who are primary could actually they're not using the node version anyways right they're using react native so I guess it doesn't apply. No, so it doesn't apply. I think we know we I think we just we need to make sure that we set the engine version on only the earth framework slash nodes package and then it shouldn't be an issue. Perfect. All right, there was also discussion on breaking out the demo. I think. Yeah, this, I just need to comment on like something but I think it's not controversial. Are there any other issues people would like to discuss or would like to work on address that we need to discuss. There is a unqualified did migration update this is something that's being discussed in the the errors working group calls to be able to migrate from legacy did to qualify did. We already have a custom implementation that goes from unqualified to get beer one did. And I think we did with this we just have to update all the in all the did peer one did we have migrated from the unqualified did to now did peer two and did peer three did. We did store all the still the legacy did did documents so would be a migration script that we have to write I think we can get that into 0505 zero. That does raise the question on whether we should change the default did peer num algo that is used for creating connections so currently we in the did exchange protocol we use did peer one. Because for did exchange, you need to attach the did documents to to the did exchange message and then sign that problem is with did peer to the three you don't necessarily have a document because you resolve that based on the the did itself. So, and I think we had raised started this discussion in the areas working group call but we never came to a very concrete decision on how do you handle it if you don't have to document should you attach the did document either way so like just to resolve the document and and sign that. So, yeah. Should we change the default did peer method if we add this, or are we going to use did peer one for did exchange and migrate all the legacy. Did to did peer to slash tree. Does anyone have an opinion on this. I guess there would be a need to have agreement across the areas projects. In terms of did it, you know the did exchange, right. I don't know it's a decision we can make in isolation so I'm not sure that I have an opinion on it, but it is still on the agenda within the areas working group and so if we need like it sounds like it's getting time to get serious about finalizing that stuff so maybe you can raise it higher priority on the agenda for the next meeting. So, I think the one thing that isn't currently talked about and that's the, like the, the did exchange protocol, not having very clearly defined how to use non did peer one did so, whether it's public dates or like documents that you can resolve based on the, or did documents that you can resolve based on the did. I think there's maybe an issue opening RSRFC. And there is the, let me see. There is a legacy did this one. Yeah. This repo is there I think the idea is now to migrate this transformation script to go from like a legacy did to a did bear to, and I think Stephen added support for did bear three. I think with that we are mostly there in having the. Yeah, the, the process to find. So I guess that then comes down to do we want to go with the most recent SPAC, or do we want to go with something that might achieve lighter compatibility with folks who haven't gone there yet. I don't know. Yeah. So I think what they are suggesting also in the community coordinated updates is that you need to support. Let me see. Yeah, I think because it's a community coordinated update there will be quite a long period process where we see rework to step one step one is so I think what a step one here I think it's to support. Okay, first. Okay, so we need to agent bill must update or agent code basis and deployments to accept into all unqualified and new forms. During this step. Agent must continue to unqualified. Yeah, so what I'm uncertain about is that it says it should that agent builders must update all agent code base and deployments to use only fully qualified digital communication. And also include the connection protocol because in that case. It probably going to be very complex because like it has been implemented a few years ago, like it's very it uses an old way of structuring and the document well did bear to uses a new one. Currently, how we implemented an AFJ is we use just to unqualified exchange and then internally we translate it into a qualified identifier and use that. Well, I think this is just thing. I think we need to use deep peer to or deep peer tree everywhere, even in creating a connection for example. Is anyone involved in the discussions chair and know more about this or I've only been peripherally involved and so I don't feel equipped to like make any definitive statements about this. It seems to have been driven more by Stephen Curran and Sam. I'll leave a comment on this PR with these questions then. Yeah, it should be quite easy for us to to follow whatever is is described here and get that implemented while still supporting the the old ways of doing things without breaking backwards compatibility, because I don't think we should. Like, I don't think it's like if we do this like updating everything to use only fully qualified did it means we're going to break so much backwards compatibility with all implementations that have been made over the years and maybe are not going to adopt this. So it would be good if we can have a bit more of a like gradual a if you support qualified let's do that otherwise will keep using the unqualified ones directly. Are there any other feature issues people would like to to discuss here or rates. Okay, then I think we can just cut the meeting short for today. And we can. Yeah, continue with work on PR and issues. One thing. I do want to highlight is. I see your and mute. Do you want to say something or. Yeah, yeah. Good catch. I just wanted to raise my hand. Yeah, you were first. Yeah, I have a question. We don't have to discuss it. Now, but about it's it's about the migration to the AFJ like, like two new libraries of scar BDR and on grits. Is there any any documentation about that and a and a. A description about about some pain points or or like tricky part which we should be aware of. So, there is the migrating from zero three to zero four. Which introduced to break and changes, and they're good. Listen, migrating from in the SDK wallet to a risk Oscar. So, that's there. One thing that we haven't documented farewell is the migration from in the SDK to in the FDR, or in the SDK to on credits arrest so like the changes in the API are covered here. So, like that you now have to register on credits module but they should see this still uses the in the SDK module here. But there is in the agent setup it does define like okay how do you use the, the in the FDR module and configure it with the different ledgers. So, that's the documentation there is. And it's no specific like these are pain points or something to be aware of. Okay, yeah sounds good sounds good. I, I, I, I know that the, actually, I asked the baron or like Ariel on the on their presentation about the FJ for version zero four zero point four about this and my question was, was, if, like, if if we should migrate everything at once, or if there is specific process, if there is better, if there is some some process which might be better. And what I mean is that we have like zero point three right now with in the SDK, right so now it's a question like, I remember that Baron said that it should be maybe better to do everything at once. But I think that he also mentioned some that there are some issues probably with some part but I don't remember that that that what what exactly do you have, do you have any, do you know anything about that or. I think we have done mostly everything at once, also what we did in the bifold and some other projects we are just doing it all at once because we would like to get rid of the in the SDK as soon as possible. You can do it in two steps like you could do first and upgrade to zero four and use the in the SDK still, and then at another point you could do the upgrade to errors Oscar, for example, when zero five releases or whenever you're ready for it so it are two separate migrations you can do if you haven't just chosen to do it at once. If you don't have in the SDK wallet to migrate yet. So, haven't released your wallet to the stores for example, I would definitely recommend to do it all at once because then you don't have to do the in the SDK to Oscar migration, because that does require. Like we have to do this in the, in the bifold wallet, and it does require you to have like a custom package you need to on every agent started basically you need to do a check like okay what's our previously in the SDK wallet, if so I now need to migrate it and do that to an Oscar structure because like the database is completely different so we really have like to make a connection to the postgres database, create new tables, move the structure decrypt everything re encrypt so like if you can get away with not having this package. Yeah, I would say sure do it all at once. In our case we have it already out there so it's it's already in production we have we already we already did the migration from the VCX library to FJ as you know but there was also not only it was also not only about like frameworks, but also our data so we already did this migration in the SDK. Yeah and now it seems as we will have to do this migration with those libraries but I think it's great that there, if there is some. Let's call it script right to do this migration. Yeah, that's definitely great so I hope that it should be fine. But it's not that complex I can send you the. I think it's the implementation from the bifold wallet. See. Yeah, so. Basically, this is it. In the SDK, is it migrated to Oscar and if not there's a custom method implementation here that calls this in the SDK to Oscar migration update. Okay, cool, cool, that's great. Thanks. Yeah, I seem to recall so so two things one another thing that came up in the Aries call yesterday is that Stephen current is pushing towards officially deprecating in the SDK. And they'd like to do it sooner rather than later. And so is is trying to rally everybody to do that so just as a point of interest is that the wants to move and the SDK to archive to state as soon as possible. So I don't know whether that goes into your decision about your migration path and the and the like just so you know that's happening and if you have concerns with that then you should chime in and get in touch with Stephen and you know, let him know what your concerns are. And the other thing, the only thing I seem to recall as being an issue and it may have been resolved but with the migration was if with AFJ and ask our was if you were using multi tenant. I think there was that that's not supported in the current migration but I might be incorrect about that. So I just wanted to bring that up as a question in case that's something that is germane here. It isn't implemented yet. Like we need to do proper migrations for multi Tennessee needs to be implemented still anyway, it is something we are going to implement because we are using multi Tennessee with AFJ in zero for zero. I haven't written the migration for multi Tennessee and no just completely yet for Oscar is because we don't know anyone that is using and it's multi Tennessee in production. And so I added to like the docs and everything there's some warnings in like hey multi Tennessee is not supported. If you need it, please open an issue. But I don't didn't want to go through all the trouble and complexity if nobody is ever going to need it. Yeah, so if you are using multi Tennessee are on zero three within the SDK and you are in production and need to migrate it to Oscar then please open an issue and then we can look at getting that implemented. But for example we have mediators running with in the SDK in zero three and we have successfully migrated those to zero for and updating in the two Oscar. So for that use case. Yeah, it works fine but yeah you're right that that is not implemented that or that deprecating the in the UK might be a good one to discuss also. I'm in favor of it. I think it adds complexity to this project to also have to support it. And the installation is like very cumbersome also for newcomers. So, yeah, I'm totally on board with deprecating the in the SDK. Maybe what we do is already start adding notes to like we have for. We have in the, like experimental modules we have warnings like hey this is experimental, maybe we could also start adding like hey this is going to be deprecated. And then maybe we say we remove support for in the SDK in either zero five, but maybe we should set it for zero six release so people can still do one more upgrade with the in the SDK to zero five, but then in zeros dot six, we will remove support for the in the SDK. And if people are really interested in keeping support for 10 that would still be possible because like it's currently there's no logic in core to support in the SDK but I would then suggest that from zero six onwards we remove it out of the the errors from JavaScript repository and it could be like a custom maintained implementation outside of it if you really need in the SDK, but then. Yeah, I think that would provide the clear migration path. Kim. Yeah, if you have a clear migration path here it'd be good to let Steven know kind of the timeline, because one of the things that came up was removing some of the build artifacts from the repositories to encourage no longer using in the SDK and so having a timeline on that would be helpful for Steven to know when a good time would be to remove those build artifacts from various repositories. Yeah, and so build artifacts because I think we're moving built artifacts can mean that current deployments can break. Is that something we want. I think my preferred approach would more likely be to like not update it anymore so if you have like an older deployment it doesn't suddenly break. The concern there is deploying artifacts that aren't maintained anymore. So if there's security holds or things like that and so at some point. Having the artifacts deployed out there can be more of a liability than they are a benefit to anyone. Yeah, that makes sense. I think the thing that would require some communication with Steven then is about a prospective plan for, you know, you mentioned perhaps, you know, deprecate putting in deprecation warnings and removing support in 050 or maybe in 060. So if we had an idea of, you know what what you would desire to do there and what the timelines are, you know, at best guess at that point for this release, then that could inform some of the other stuff that that Steven and others are doing to try and wrangle the in the SDK to the ground to make sure we're coordinated on that stuff. Yeah. Yeah, it makes sense. Are people any people here that are using in the escape and don't intend to upgrade to Oscar and related libraries for zero five, or even zero six. Well, that's positive at least cool. And then final notice I think also mentioned this last time already, I'm not 100% sure, because it's two weeks ago already. And application in between so I wiped all my memory from before. And that's that we wanted to switch hosting the AFJ call to being bi-weekly, because there is like with grants, things that are happening I think having a bi-weekly call would be good enough. But if they're, well, in the future again arises like so much to discuss that we can do it in in the bi-weekly call then we can always go back to having weekly calls but I think a lot of the stuff can also be picked up in issues and pull requests. There are people against that here today that that would like to keep it at a weekly call people that are agreeing after bi-weekly call or have any opinions notes on this. I think it definitely makes sense during the summer occasions right. Maybe let's see again on in September or in autumn. So does it mean that we would skip next week and do it in two weeks again. Another call would be like in two weeks from now. Yeah, exactly. Okay, good. Okay, I think. Sorry, I just this is my first meeting. And I thoroughly enjoyed it. There's a lot of insight. And I'm a bit sad and if it goes to sort of further away further away from, you know, the consistency bi-weekly is it every two times a week or then twice every second week. Yeah, so it would be once every two weeks, two times a month basically. Because I've been away. I haven't, I was so desperately looking to be more involved in the community. And this is my first meeting and I, you know, thoroughly enjoyed it. So it'll be a bit sad on my part. Okay. Yeah. No, that's good to know. I think yeah. I, we have done it like for weekly, I think for a really long time already I think at first was bi-weekly. I just think with the conversations we have lately. Maybe it's something for the summer months. And then we can always reconsider it after the summer months. Or if there are enough topics to do it weekly. That would also be fine by me, but I think we can also. Yeah, we should have probably some more like we have in the past looked at a bit like doing alternating weeks of having a maintainers and a user's call, basically where the week will be really focused on in-depth discussions on the implementation. The other one would be more focused on the user side of things, having people give presentations on what have they built with AFJ, what can you do with it more from a user perspective. I think that's one of the things that I haven't had a lot of time lately to prepare well for the working group calls. And I think that's also one of the reasons why I would like to move it more to a bi-weekly call. Because yeah, having people to present on these things with presentations and everything I think that helps in making it a more well, a better working group call. I have also discussed a bit with Jakub and Ariel and Karim and Berend and asked to maybe do it a bit more in alternating fashion where we host the working group calls. I think that that could maybe also help a bit. But yeah, I'll definitely take it into account. I would like to propose for now to at least for the summer do it bi-weekly. And then as Jakub said, after the summer we can reconsider to see like what's the interest and do we want to make it weekly or bi-weekly. Yeah. And so if you have topics you would like to present or talk about on the Airstream just call presentation or something like that. Also please yeah, raise that to us. And then we can have those on the working group calls. Or unmute it. Yeah, I just wanted to say I think that the, you know, the cadence of the calls doesn't matter personally to me as as much one way or the one way or the other. But I will say that I think the last few months have been very busy for the project because there's been so much both refactoring of the framework. It's done pretty well as a lot of rework due to moving to shared components. And those two things have taken a lot of coordination and I think have needed the cadence of the calls to to maintain the velocity and coordinate those complex activities and so I'd like to pass on some congratulations I think to the group to for managing that like that's a very complicated set of things to to get to and deliver and I think it was done pretty well. And for the next little while it, you know, people need a break from that and there's a lot more, you know, independent work that can happen that doesn't require as much coordination than, you know, perhaps less regular calls might be might be appropriate you know, community will take that into account but I certainly do appreciate the amount of work that's been, you know, and the amount of coordination that's happened to happen over the last few months it's been pretty intense. Cool, thanks. Yeah, I think what you may what you say makes sense. Like there's been less activity in the last weeks and so after the a lot of the refactoring and that makes up that we have less to discuss yes. Okay, then let's just keep it biweekly for now but always keep it open, like we can have it more often when needed. I'll communicate this with Brian. And then we're out of time filter our nicely. Thanks everyone, and then we won't have to meeting next week, but we will have it the one after. Yeah, I need to think. Yeah, I'll be still yeah I'm going on vacation but the week after that so in two weeks I will be here with you. Thanks everyone. Thank you.