WEBVTT 1 00:00:02.000 --> 00:00:04.410 Stephen Curran: All right. Welcome to the 2 00:00:04.530 --> 00:00:06.680 Stephen Curran: June 20 seventh 3 00:00:06.800 --> 00:00:14.629 Stephen Curran: one in 23 Aries cloud agent on user group meeting. big agenda. Lots of things to go over 4 00:00:14.940 --> 00:00:23.390 Stephen Curran: so we'll be talking about a pile of things, including probably the main topic getting an on Chris rust into acupy 5 00:00:23.910 --> 00:00:49.870 Stephen Curran: The meeting is being recorded. So we will be posting it after this. The meantime, reminder that this is a Linux Foundation Hyper Ledger meeting Linux Foundation meetings have an antitrust policy in place as well. The code of conduct for Hyper Ledger is also, in effect, please be good to one another. 6 00:00:50.270 --> 00:01:10.339 Stephen Curran: anyone who want to introduce themselves that's new to the meeting and wants to talk about what they're doing wants to make an announcement, or would like to add something to the agenda. Please raise your hand or just begin speaking, and we'll go in turn. 7 00:01:18.250 --> 00:01:23.250 Stephen Curran: All right. Nothing to announce nothing to. It is 8 00:01:24.430 --> 00:01:37.439 Stephen Curran: summer season getting started, so there's not going to be as many things going on all right. reminder of the documentation. I have an idea for some more documentation to talk about hopefully. If we have time we'll see 9 00:01:37.750 --> 00:01:49.739 Stephen Curran: all right. on the agenda act by release 8 to our C. One has been completed. it was just released a few minutes ago. So it's out and available. 10 00:01:49.960 --> 00:02:07.780 Stephen Curran: it's just a minor update. There is one more pr that we're we're considering merging prior to the final 0 8 2. I'll wait a little bit longer, but That may not make it. So we'll see how that goes. 11 00:02:08.740 --> 00:02:22.529 Stephen Curran: If not, if we decide not to include that one as soon as we've had some smoke test done on this 0 a 2 r c, one, we'll complete 0 8, 2 and release it. 12 00:02:24.910 --> 00:02:36.269 Stephen Curran: is there any other Pr's that anyone desperately wants into 0 8 2. If there's anything to highlight, please let me know. 13 00:02:36.600 --> 00:02:37.990 Stephen Curran: or and 14 00:02:38.330 --> 00:02:40.789 Stephen Curran: let us know now. 15 00:02:41.120 --> 00:02:42.699 Stephen Curran: Happy to have that. 16 00:02:45.120 --> 00:02:52.320 Stephen Curran: Oh, we have another AI assistant in the crowd. I wondered about that. Oh, well. I guess we'll leave it. 17 00:02:55.690 --> 00:03:06.249 Stephen Curran: Okay. Invading an opera. It's rust and occupy. I wanted to give an update. We had a meeting yesterday on on where we are with 18 00:03:06.450 --> 00:03:13.039 Stephen Curran: PC. Governor Dco, to talk about the code with us. So I was going to talk about that 19 00:03:13.160 --> 00:03:24.110 Stephen Curran: Daniel. I had a presentation that I thought I'd go through this sort of summarize our meeting, and and please jump in. If there's anything you see that's incorrect 20 00:03:24.860 --> 00:03:30.090 Stephen Curran: or needs adjustment. But in the meantime I'll go. I'll go through with that. So 21 00:03:30.550 --> 00:03:41.149 Stephen Curran: We've had a goal for a little while now that we have an on credit. Rs, so the hyper ledger and upgrades implementation in occupy 22 00:03:41.950 --> 00:03:45.230 Stephen Curran: this talks about where we are and where we need to be 23 00:03:45.250 --> 00:03:56.099 Stephen Curran: So we posted a code with us in Theco. Has said a pr was awarded to a Dco. And that teams been working very hard on that done a a lot of work. 24 00:03:56.120 --> 00:04:08.800 Stephen Curran: the Pr. Submitted for merging, and we decided to merge it into a developer branch. It's not quite ready for merging into main. this will be I I think the likely is a 25 00:04:09.510 --> 00:04:14.360 Stephen Curran: extremely likely to be a breaking change. And so 26 00:04:14.400 --> 00:04:28.680 Stephen Curran: we're talking about now exactly what that means, and and how how much of a breaking change will be the Maintainer's recommended to make it a breaking change that that we were probably holding on to too many things to try to make 27 00:04:28.710 --> 00:04:33.970 Stephen Curran: occupied backwards, compatible in in certain areas. And so it was time for a pretty significant change. 28 00:04:34.300 --> 00:04:43.410 Stephen Curran: Or, if this is likely, a a place where a significant change would actually be helpful to everyone versus a hindrance. 29 00:04:43.870 --> 00:04:56.469 Stephen Curran: Obviously we want to keep things as backward, compatible as possible. But just there comes a time where it's it it. It is a bigger problem to to try to maintain that versus moving forward with a break to change. 30 00:04:58.720 --> 00:05:08.540 Stephen Curran: So here are the things that we're proposing, that we breaking and non breaking as we go forward. So we want to minimize 31 00:05:08.700 --> 00:05:24.540 Stephen Curran: the changes, the issue credential and present proof protocol. So basically the interface between an issuing agents and a holder, or between a whole or an initiative between a holder and a and a verifier. We want to minimize those changes. So we want the protocols 32 00:05:25.250 --> 00:05:27.070 Stephen Curran: to be 33 00:05:27.130 --> 00:05:28.840 Stephen Curran: to remain the same. 34 00:05:28.960 --> 00:05:39.639 Stephen Curran: so basically holds your nose and keep the name of Indie attachments. So, even though it's in the attachments versus a on cred, we, we would retain that 35 00:05:39.810 --> 00:05:56.140 Stephen Curran: and and basically cover over any difference in the use of legacy in the adapters, identifiers, and all other ident identifiers. So basically, when using legacy indeed, and where issuing credentials or or present proof. 36 00:05:56.840 --> 00:06:10.780 Stephen Curran: those would remain the same. And so that if we interacted with a older version of Occupy there would be no difference. And so that is the that is a big 37 00:06:12.440 --> 00:06:29.439 Stephen Curran: interface that we want to keep the same, so that would remain We think we it would be best to drop the legacy and on credits mid Apis and and add. 38 00:06:29.470 --> 00:06:34.789 Stephen Curran: I, I get so yeah, legacy and on credits have been Apis and add 39 00:06:35.140 --> 00:06:38.179 Stephen Curran: new whoops sorry 40 00:06:38.310 --> 00:06:52.309 Stephen Curran: and and add new and on cred. Apis. So basically, that means drop the scheme of the credit death and most of, and perhaps all of the revocation endpoints. 41 00:06:52.820 --> 00:06:57.780 Stephen Curran: So those would go away. And we would add a new and on threads. Api. 42 00:06:57.810 --> 00:07:05.370 Stephen Curran: So basically, instead of there being a slash, schema slash, create or a slash schema. 43 00:07:05.810 --> 00:07:06.970 Stephen Curran: I get 44 00:07:07.140 --> 00:07:13.179 Stephen Curran: slash schema or a get slash credibility, for these would be 45 00:07:13.710 --> 00:07:20.779 Stephen Curran: and on credit, slash schema and on credit. So that would be the idea there. So that would require 46 00:07:20.870 --> 00:07:27.410 Stephen Curran: the recoding of of some of of controllers basically 47 00:07:28.240 --> 00:07:40.500 Stephen Curran: to upgrade to the new release. So that's a big change as a non correct, and on credits Api. So as those endpoints revocation, I want to talk about a little bit separately. 48 00:07:41.220 --> 00:07:43.969 Stephen Curran: so we'll get to that in a bit 49 00:07:45.030 --> 00:07:54.629 Stephen Curran: the next would be enable upgrading an existing act by implementation storage to the new breaking change version. So the idea would be that when a 50 00:07:54.990 --> 00:08:00.180 Stephen Curran: and implementation of occupy with the Controller is updated together. 51 00:08:00.330 --> 00:08:07.280 Stephen Curran: that there would be a way to upgrade the storage so that the 52 00:08:07.720 --> 00:08:11.669 Stephen Curran: This is good function with the new release. 53 00:08:12.560 --> 00:08:22.949 Stephen Curran: However, in doing that there would be no special support for, unlikely to be special support for a multi tenant a by implementation. So 54 00:08:23.000 --> 00:08:24.380 Stephen Curran: basically. 55 00:08:25.060 --> 00:08:32.160 Stephen Curran: you would not be able to do something like pick and choose which tenants get updated to the new storage. 56 00:08:32.409 --> 00:08:36.850 Stephen Curran: All controllers would be updated together for the to the new version. 57 00:08:37.169 --> 00:08:52.410 Stephen Curran: storage for all wallets are updated. that means storage for all the wallets are updated during the deployment of the new version, which means all controllers would have to be updated when a multi tenant 58 00:08:53.020 --> 00:08:54.160 Stephen Curran: updated. 59 00:08:54.320 --> 00:09:01.910 Stephen Curran: So the ramifications of that is, if you had a multi tenant instance that had different controllers. 60 00:09:02.880 --> 00:09:09.379 Stephen Curran: for the different wallets. all of the controllers would have to be updated together. 61 00:09:09.600 --> 00:09:27.259 Stephen Curran: not individual ones. If if you try. If your instance all use the same software. the controller was the same. That that's easy, and and you know no different from from a tangle single tenant version. 62 00:09:27.680 --> 00:09:34.440 Stephen Curran: But if you're if you actually had separate controllers for different tenants. 63 00:09:34.500 --> 00:09:40.990 Stephen Curran: all of them would have to. All of the controllers would have to be up to it together. Does that make sense? Does anyone have any questions on that? 64 00:09:45.320 --> 00:09:51.860 Stephen Curran: I don't know how many people in the community would have that issue. But be aware of that. 65 00:09:52.810 --> 00:09:57.280 Stephen Curran: We do want to retain the endorser implementation 66 00:09:57.500 --> 00:10:00.480 Stephen Curran: as much as possible. Hide 67 00:10:00.640 --> 00:10:26.179 Stephen Curran: endorsers from the Controller in that in that the Controller doesn't have to do anything that endorsing would take place within occupy. And the endorser would just basically be configured for an agent to say, I'm going to use an endorse, or here's the endorseer I'm going to use, and stuff would just happen, and the Controller would not be concerned with it, so that should happen within aquaby. 68 00:10:29.440 --> 00:10:50.020 Stephen Curran: revocation. I wanted to get into a bit of the history of revocation for those not aware of it, and then the plan for going forward. Historically, the first, the first implementation of of revocation required the Controller to do all of the work. So whenever revocation was needed. 69 00:10:50.060 --> 00:11:02.550 Stephen Curran: support was added in the Credit D, then every time a new Revocation registry was needed it, the Controller would have to say, hey, go, create a Revocation registry. When when we wanted to publish 70 00:11:02.610 --> 00:11:12.859 Stephen Curran: revocation registry entries, the status updates that publish it had to happen. The Controller had to manage that 71 00:11:13.350 --> 00:11:16.649 Stephen Curran: hardest. Yet, even if those things was 72 00:11:16.720 --> 00:11:29.719 Stephen Curran: tracking when a new Revocation registry was needed, and and so and that was the big one, that sort of triggered to us. Oh, my God, this this is not going to work! This is too painful for the Controller to be able to do that. 73 00:11:30.260 --> 00:11:35.409 Stephen Curran: So we. We moved away from that. In addition. 74 00:11:35.430 --> 00:11:41.089 Stephen Curran: when endorser functionality came in, that also all had to be done 75 00:11:41.150 --> 00:12:02.929 Stephen Curran: essentially, the controller was doing it. And again, that was difficult to manage for the controller. So what we want to do is where we are today is we want to continue that which is, when we did the second implementation of revocation occupy does the work, and the controller only does the things that trigger occupy to do things. So 76 00:12:03.310 --> 00:12:17.500 Stephen Curran: the the impacts of revocation should be, I'm going to support revocation during the credential issue and set up. So every time I I create a correct F for a new credential type. I'm going to say whether I'm going to support revocation or not. 77 00:12:17.540 --> 00:12:23.520 Stephen Curran: If I am supporting revocation, I'm going to say how big my revocation registries are going to be. 78 00:12:23.530 --> 00:12:24.809 Stephen Curran: and that's it. 79 00:12:25.600 --> 00:12:38.020 Stephen Curran: the controller needs to track the Revocation Id for credentials when issued. So the identifier that is necessary, for when a credential is to be revoked 80 00:12:38.390 --> 00:12:46.600 Stephen Curran: when necessary, obviously the controller needs to revoke credentials, and they would use that revocation. Id 81 00:12:46.810 --> 00:12:48.340 Stephen Curran: to do so 82 00:12:48.420 --> 00:12:59.900 Stephen Curran: when they do. That occupy is tracking the state of of the revoked credentials. The fact that they've been revoked, and finally, the occupy. Instance, the Controller 83 00:13:00.010 --> 00:13:07.359 Stephen Curran: needs to publish Trigger when publishes, publications of revocations are done. 84 00:13:07.520 --> 00:13:13.370 Stephen Curran: And again, this is on a per credential type. So it's for say, Oh, I want to. 85 00:13:13.570 --> 00:13:21.789 Stephen Curran: on A, on a credential type. I want to revoke. I want to publish the revocations, and that could result in needing to publish. 86 00:13:22.000 --> 00:13:40.130 Stephen Curran: multiple. You may have multiple revocation registries that that have been active at various times, and they have a backlog of revocations to publish. That means that could be multiple transactions to be written. 87 00:13:40.980 --> 00:13:43.810 Stephen Curran: all of that. All of that 88 00:13:44.360 --> 00:13:54.159 Stephen Curran: detail beyond these 4 trigger points is all managed within occupy. And we want to keep that. So the Controller's life is simplified to 89 00:13:54.660 --> 00:13:57.880 Stephen Curran: supporting what's necessary for revocation. 90 00:13:58.510 --> 00:14:13.940 Stephen Curran: right now, when we implemented that second implementation, we kept the Admin Api for both modes. So we kept all of the Revocation endpoints so that the Controller could manage everything itself. 91 00:14:14.300 --> 00:14:16.789 Stephen Curran: Probably that wasn't the best idea. 92 00:14:16.820 --> 00:14:29.430 Stephen Curran: The plan now is to only keep the occupy does all the work mode. It's much easier for everyone, for for a and for the controller to just say. 93 00:14:29.860 --> 00:14:37.970 Stephen Curran: occupy manages the revocation work, and the only input the controller has are these types of 94 00:14:38.160 --> 00:14:41.149 Stephen Curran: are are these actions that can be taken. 95 00:14:42.160 --> 00:15:08.160 Stephen Curran: I would point out that these activities are the same, whether you're using a on credits or whether you're using something like status list 2021 and some other revocation mechanism. So this actually could work for any credential format which is kind of why, I was suggesting that the Revocation endpoint may actually still exist. 96 00:15:08.390 --> 00:15:11.130 Stephen Curran: and 97 00:15:11.490 --> 00:15:20.680 Stephen Curran: because it it is generally useful. Basically, the only 2 things you do in the revocation endpoint is you revoked credentials? 98 00:15:20.930 --> 00:15:27.489 Stephen Curran: given an id revoked credentials, and from time to time published revocation updates 99 00:15:27.750 --> 00:15:46.030 Stephen Curran: publish them out to some other place so That really could be done, regardless of what revocation scheme, or even what credential format you're using. So I don't know if we're going to get to that generic, but that that is something to consider and and think about as we go forward with this. 100 00:15:49.920 --> 00:16:00.209 Stephen Curran: And then There's an a bunch of clean up to be done on the Pr. 276, which is what was emerged yesterday into a developer branch. 101 00:16:00.800 --> 00:16:21.049 Stephen Curran: there's some issues that were were raised into the en on Chris rust implementation for a couple of things. no effort has been made to eliminate any no longer needed. Admit Apis and endpoints, so I I think it would be wise to do that. So 102 00:16:21.070 --> 00:16:26.799 Stephen Curran: at least the elimination of the endpoints. And then look at what code needs to get eliminated as part of that 103 00:16:27.130 --> 00:16:33.939 Stephen Curran: We do need migration plan for issue or folders and verifiers, which is the migration storage scripts 104 00:16:34.400 --> 00:16:36.809 Stephen Curran: depending on 105 00:16:37.030 --> 00:16:47.929 Stephen Curran: You know what the new storage looks like what what needs to change, what additional data needs to be tracked or or generated? 106 00:16:48.400 --> 00:16:50.420 Stephen Curran: when doing an update. 107 00:16:50.630 --> 00:17:16.139 Stephen Curran: And then finally, the Dco team has got a pretty significant all in one test that is being used. But that is sort of a standalone test for all of the work. So that test needs to be added to the core integration test. So that at least that one specific test and probably other tests need to be added, I think those are the major elements. 108 00:17:16.240 --> 00:17:25.419 Stephen Curran: oh, no, there's a couple of more. Oh, big one, that is the they what oops come on 109 00:17:29.440 --> 00:17:34.259 Stephen Curran: occupy, does it all revocation? So we want to get rid of the 110 00:17:34.780 --> 00:17:53.980 Stephen Curran: endpoints that allows the Controller to manage the revocation all on its own. Get rid of that simplify ideally the endorse or support some sort of plugin that sort of says, Oh, I'm going to call Endorser. I'm going to call the endorser on pretty much every 111 00:17:54.230 --> 00:18:06.039 Stephen Curran: publication transaction, and if I have an endorser it'll be used, and if I don't it'll be a null a null off of some kind. So put that in. 112 00:18:06.260 --> 00:18:22.769 Stephen Curran: and then the other thing is in addition to legacy and support. support for did Indie and did web implementations. did. Indie would be used for instances of indie that are able to support did Indie 113 00:18:23.100 --> 00:18:28.230 Stephen Curran: using the Ndbdr capability and and 114 00:18:28.570 --> 00:18:35.210 Stephen Curran: implementations that support that and then did. Web should be a pretty trivial implementation, which is basically a 115 00:18:36.010 --> 00:18:48.270 Stephen Curran: a transformation. basically being able to do posts. Http posts to Urls. based on what the did web 116 00:18:48.360 --> 00:19:01.949 Stephen Curran: identifier is that that basically results in files being loaded to a web server. So there will be an implementation of some sort of registrar for for did web 117 00:19:02.100 --> 00:19:15.729 Stephen Curran: obviously that would need authentication to be able to post a file, you know, to a to a web server, and then the resolver that simply converts a did web. 118 00:19:16.240 --> 00:19:21.750 Stephen Curran: did. Did you? Rl into a a Http, URL, 119 00:19:22.090 --> 00:19:23.720 Stephen Curran: so that's the clean up. 120 00:19:25.720 --> 00:19:29.809 Stephen Curran: And I think that's all. Nope looks like. 121 00:19:33.280 --> 00:19:45.690 Stephen Curran: yes, there is. Rfc changes the in the attachment. I mentioned that earlier. we will retain the in the attachment. 122 00:19:45.920 --> 00:19:53.969 Stephen Curran: to be at least the indie. We're in the changes to an ongrad. So this needs to be added to the area's Rfc 123 00:19:54.180 --> 00:20:01.439 Stephen Curran: so that we sort of deprecate the indie attachment and add the and on credits 124 00:20:01.670 --> 00:20:10.849 Stephen Curran: agents that don't support an on credits format, on receiving an attachment in the on credits Format would send a problem report saying, Hey, I can't handle this. 125 00:20:10.940 --> 00:20:20.850 Stephen Curran: Likely it would be fairly easy to say, oh, I got this an oncred attachment, but that's the same as the nd one, so I can use that, and vice versa. 126 00:20:22.050 --> 00:20:34.449 Stephen Curran: The interesting thing is that the non correct format could also be the W. 3 C. Format attachment, and so 127 00:20:34.660 --> 00:20:39.389 Stephen Curran: If we were to complete the formalization of the and ongrad data integrity proof. 128 00:20:39.710 --> 00:20:46.350 Stephen Curran: we could actually use the existing W. 3 C. Format that is used for Json, Ld, 129 00:20:46.430 --> 00:20:57.310 Stephen Curran: credentials and use that in that use that for and on bread. So that's another possibility that it's kind of interesting. 130 00:20:59.630 --> 00:21:06.149 Stephen Curran: And I think that's all I had. I didn't see hands raised or questions. So there we go, Tim. 131 00:21:14.640 --> 00:21:16.679 Stephen Curran: I can't hear you. Tim. Go ahead. 132 00:21:19.430 --> 00:21:20.500 Stephen Curran: Okay. 133 00:21:20.830 --> 00:21:39.589 Tim Bloomfield: fixed. My, how is that? Better. There we go. Yeah. I'm really excited about the revocation changes. all the experience and trying to work with issuers. We just gave up on to explain to them how to manager how on their location registry. So we'd actually pretty much concluded we needed to write something ourselves to manage it. So this is. 134 00:21:39.810 --> 00:21:53.999 Stephen Curran: that's really good. Just one real quick note. You had renovation in the title, not replication. I will fix that. But anyway, really good. Thank you. yeah, that's interesting. So we've 135 00:21:54.820 --> 00:22:18.869 Stephen Curran: so you were actually trying to use the controller doing the revocation like all the pieces. 136 00:22:18.920 --> 00:22:30.470 Stephen Curran: we do have this fully implemented. And we use it all the time. so you know, this idea that occupy handles it all is. 137 00:22:30.730 --> 00:22:34.009 Stephen Curran: shouldn't you know, is is implemented. 138 00:22:34.020 --> 00:22:46.520 Stephen Curran: and and should make it a lot easier. We even have a feature. We ran into a situation those may not be aware. We ran into a situation where a 139 00:22:47.100 --> 00:22:48.480 Stephen Curran: a wallet 140 00:22:48.520 --> 00:23:03.919 Stephen Curran: got out of sync with the ledger as far as what was revoked and what wasn't, and we were even able to put in a a correction that allowed us to re-synchronize So basically, if 141 00:23:04.480 --> 00:23:14.900 Stephen Curran: if the if they re a publication of a revocation registry failed. we would actually detect that and correct 142 00:23:14.930 --> 00:23:17.130 Stephen Curran: the revocation, so that 143 00:23:17.500 --> 00:23:28.640 Stephen Curran: we took a little bit of work. Took a little bit of understanding. but we got it so that we were able to do that. So that would, I believe that would continue to be a feature and the goal of this. 144 00:23:30.600 --> 00:23:33.969 Stephen Curran: any other questions or comments. And, Daniel, how did I do? 145 00:23:36.760 --> 00:23:39.520 Daniel Bluhm: I I think that was a really good summary 146 00:23:39.630 --> 00:23:40.489 Daniel Bluhm: kind of 147 00:23:41.020 --> 00:23:52.409 Daniel Bluhm: I I don't know now. It's a great time to talk about it, but just because it was fresh on my mind. that last point that you raised talking about the an on Peds and W Threec. Format, and using the 148 00:23:52.420 --> 00:24:07.449 Daniel Bluhm: the proof Vc detail. So I I actually happened to do an evaluation recently on on what it would look like for an on cred to the in W Threec. Format and be exchanged over the existing issue. Credential and present proof. 149 00:24:07.650 --> 00:24:09.200 Daniel Bluhm: Yeah, where the calls 150 00:24:09.220 --> 00:24:12.389 Daniel Bluhm: and the Ldproof Vc. Detail attachment format 151 00:24:13.030 --> 00:24:18.579 Daniel Bluhm: is pretty specific to linked data proofs. So my 152 00:24:18.910 --> 00:24:30.829 Daniel Bluhm: inclusion as I was going through that was actually that we would probably need a different attachment format in order to communicate about the requirements of the a non-pred specific credential and all those things that factor into that. 153 00:24:32.140 --> 00:24:33.120 Daniel Bluhm: So I 154 00:24:33.420 --> 00:24:41.389 Daniel Bluhm: I'd be interested in how you came to that conclusion, because our conclusion is the opposite. That's funny. Okay, I I have a document. I can. 155 00:24:41.720 --> 00:24:56.129 Daniel Bluhm: And you did look over Andrew's work that he did in that. Yes, yeah. So it it wasn't so much that there was any issue with the actual format of the credential itself, or or the presentation itself. 156 00:24:56.180 --> 00:24:59.399 Daniel Bluhm: but rather how we expressed as an issuer 157 00:24:59.450 --> 00:25:05.799 Daniel Bluhm: what was to be issued using the Ldp BC. Detail attachment format. It. It was just. 158 00:25:06.370 --> 00:25:13.159 Daniel Bluhm: It was a little bit of a, a, a a contortion, I suppose, to 159 00:25:13.590 --> 00:25:14.380 Stephen Curran: yeah. 160 00:25:15.640 --> 00:25:30.880 Daniel Bluhm: And then a aside from that, I also wanted to mention that I have created a project board for some of those remaining items that were discussed in Steven's presentation. I've been going through and populating that forward with a bunch of stuff. 161 00:25:31.900 --> 00:25:39.810 Daniel Bluhm: and we'll continue to do that and add some more detail to those tasks. So that's out there and a link to it from the agenda. 162 00:25:39.940 --> 00:25:48.810 Stephen Curran: Oh, good, okay, and I'll add my presentation, renovation and all. to the agenda as well. I keep forgetting to do that when I do these presentations. So. 163 00:25:50.190 --> 00:25:52.910 Stephen Curran: okay, any other comments from anyone. 164 00:25:56.700 --> 00:26:24.600 Stephen Curran: if anyone is interested in this is a chunk of work that needs to get done. we could definitely use others. joining in and and helping out with this the reason we put it into a a a developer branch. a a branch off made was to enable multiple developers to be able to work on it. do merge requests pull requests into that 165 00:26:25.340 --> 00:26:27.809 Stephen Curran: into that new 166 00:26:27.890 --> 00:26:50.160 Stephen Curran: branch in preparation for it going into main. We do. I'm a huge fan of not having developer branches and and doing development on the main branch. So I do not like to see that active separate branch, so we could really use some help at getting that completed and and getting that work done. So 167 00:26:50.180 --> 00:26:53.310 Stephen Curran: If anyone has 168 00:26:54.080 --> 00:26:57.889 Stephen Curran: is willing to help out on that we would very much appreciate it. 169 00:27:04.840 --> 00:27:06.900 Stephen Curran: Okay, Whoa. 170 00:27:07.930 --> 00:27:10.030 Stephen Curran: Where did I go? 171 00:27:14.340 --> 00:27:24.570 Stephen Curran: I was unexpected. Oh, that's why I keep forgetting when I leave it in that mode. Okay, let me get back to the agenda. 172 00:27:28.490 --> 00:27:45.999 Stephen Curran: probably talk a bit about this tomorrow on the Areas Working group call. I'm not sure. updating Aries Mediator Service. Given the open sourcing of the Dcos socket, Doc. my plan was to put in 173 00:27:46.100 --> 00:27:53.120 Stephen Curran: some some issues into Aries mediator service. 174 00:27:53.410 --> 00:28:06.119 Stephen Curran: to talk about how in Dcos socket do which they announced last week and open source last week could be used. I think it's a huge 175 00:28:06.830 --> 00:28:15.819 Stephen Curran: improvement in how. That's gonna how a and there is a mediator can be implemented. So like to see that done. 176 00:28:15.950 --> 00:28:35.959 Stephen Curran: I'm assuming that, you know. in the in Dcos socket dot picture they just put mediator cluster. that could still be an acupy cluster, and so The goal would be to put that in place. I think we recently done work to enable 177 00:28:36.960 --> 00:28:39.800 Stephen Curran: you know the use of red as 178 00:28:39.830 --> 00:28:55.300 Stephen Curran: and cache consistency, using redis in occupy such that we can have a horizontally scalable instances in cases where there is no web sockets involved by 179 00:28:55.440 --> 00:29:05.470 Stephen Curran: taking web sockets out of the picture, putting them into socket. Doc, that means that we can have a a scalable theories occupy 180 00:29:05.530 --> 00:29:11.179 Stephen Curran: mediator client. Once we add the connection with the 181 00:29:11.250 --> 00:29:13.749 Stephen Curran: Http based. 182 00:29:14.440 --> 00:29:17.959 Stephen Curran: socket, Doc, so that. 183 00:29:18.840 --> 00:29:24.070 Stephen Curran: you know, is is going to be a key goal. So those interested in working on that. 184 00:29:24.630 --> 00:29:32.069 Stephen Curran: please, you know. Raise your hands. As I say, I think we need to get a lines and boxes. Picture of what? 185 00:29:32.120 --> 00:29:39.559 Stephen Curran: it's going to look like. But I think with socket dock in place, it's much, much easier to have areas Mediator Service implemented. 186 00:29:40.000 --> 00:30:03.409 Stephen Curran: one other thing we want to do, and I realize that there's a little bit of work to go in there. But we've had a couple of our developers that work for companies that do not allow the use of in Brock on their systems. Oh, Jamie, sorry! Go ahead. 187 00:30:04.220 --> 00:30:06.890 popkinj: you know, to sort of the reddest area like, because I'm trying 188 00:30:07.060 --> 00:30:13.549 popkinj: trying to set up a web socket and get rid of the, you know, polling feature. 189 00:30:13.710 --> 00:30:31.570 Stephen Curran: So I I would be kind of interested in in this spot. I think. yeah. Socket, Doc, in in managing web sockets is going to make a huge difference. So definitely, if you're working there, let's let's get you involved in that. 190 00:30:33.010 --> 00:30:33.810 popkinj: Thanks. 191 00:30:34.150 --> 00:30:35.910 Stephen Curran: Good 192 00:30:35.920 --> 00:30:58.250 Stephen Curran: in Brock. So we use endbroken a lot of issue in a lot of developer demos and developer setups, so that a a developer can have a local instance of occupy and expose a public interface to it a public endpoint, so that other agents like wallets and things, can talk to it. We use in Brock for that 193 00:30:58.340 --> 00:31:03.980 Stephen Curran: one interesting side issue. If anyone knows of. you know the 194 00:31:04.440 --> 00:31:17.660 Stephen Curran: people looking for a a getting started project. This would be a good one, which is to actually use acupy as a mediator client? and to have the mediator be the endpoint. 195 00:31:17.710 --> 00:31:33.100 Stephen Curran: So use the, for example, in Dco public. mediator, there is, you know, a sandbox mediator that that you can use, configure your aquapy agent to use it, and and then be able to 196 00:31:33.550 --> 00:31:40.869 basically be able to use that as as it as the endpoint for your app by agent, it would be public 197 00:31:40.930 --> 00:31:51.850 Stephen Curran: by default. All your messages would come in through the Mediator, and you would not have to use in Brock anymore. So it is something that I kind of have a goal that we would eliminate 198 00:31:51.980 --> 00:32:02.259 Stephen Curran: the need for and for that purpose. So keep that one in mind. if as we go from what I understand occupy is not 199 00:32:02.730 --> 00:32:06.369 Stephen Curran: does not have the. I believe it's the pick up 2 200 00:32:06.440 --> 00:32:13.460 Stephen Curran: algorithm, Daniel, if you could correct me on that as a mediator client, so that would have to be updated. As far as I know. 201 00:32:14.860 --> 00:32:17.959 Daniel Bluhm: that would be correct. 202 00:32:18.030 --> 00:32:34.930 Daniel Bluhm: So as a a a quick kind of follow up to the question of ingrat and using a prize mediator blind? so quite a while ago, actually, we threw together a quick project. that basically puts another mediator 203 00:32:35.090 --> 00:32:40.360 Daniel Bluhm: into the mix which sounds complex, but it it actually ended up being 204 00:32:40.480 --> 00:32:56.680 Daniel Bluhm: cleaner at at that point in time at least, for us to implement it that way as opposed to turning back into mediation client, so that that mediator would sit alongside your app by instance, within your your firewall, within your network, whatever and that component would 205 00:32:57.000 --> 00:32:59.300 Daniel Bluhm: full and receive messages from 206 00:32:59.340 --> 00:33:08.930 Daniel Bluhm: a mediator that is outside of your firewall. So a a public mediator, and then forward those messages onto the act by instance. 207 00:33:09.140 --> 00:33:18.980 Daniel Bluhm: so it it turned occupied into being able to be capable of being a mediation client without needing to implement it directly within a. And we've been using it 208 00:33:19.220 --> 00:33:20.590 Daniel Bluhm: for 209 00:33:20.650 --> 00:33:27.080 Daniel Bluhm: quite a while, and it's been pretty reliable and and useful for us. So that that's an option. I still. 210 00:33:27.620 --> 00:33:39.329 Daniel Bluhm: I I still think there's value in in act by directly supporting that capability. But I think there's also the question of whether we want to add that complexity into act by in that whole question. so yeah, I think there's 211 00:33:39.650 --> 00:33:40.770 Daniel Bluhm: reasonable 212 00:33:41.740 --> 00:33:44.560 Daniel Bluhm: debate to be had there on on what the best approaches. 213 00:33:44.890 --> 00:33:57.569 Stephen Curran: Okay, I'm I'm not sure why you would need that. Because, if you know, if you've got an external mediator, all you've got to do, as far as I know, is is configure a startup parameter, so that occupy uses that external mediator. 214 00:33:58.160 --> 00:34:13.469 Daniel Bluhm: The issue that we ran into at the time was in order for occupy to pull the web socket open to the external mediator, or to pull from messages. There is going to be a significant amount of work required in the inbound transport which? 215 00:34:14.070 --> 00:34:21.509 Daniel Bluhm: That? Yeah. Again, at the time we we determined it would be quicker for us to just side thing that took care of that for us. 216 00:34:21.980 --> 00:34:24.060 Stephen Curran: Okay? 217 00:34:25.719 --> 00:34:40.369 Stephen Curran: yeah. I mean, I I. The the issue is more in Brock and and Tim's raised that there's another dial. I/O. The problem with any of these things is basically end. Rock or or equivalence creates a hole in the firewall, and companies don't like it. When 218 00:34:40.449 --> 00:34:46.149 Stephen Curran: arbitrary holes can be punched into the firewall of their of their organization. 219 00:34:46.360 --> 00:34:48.120 Stephen Curran: so 220 00:34:48.389 --> 00:34:59.159 Stephen Curran: that's why, you know, using a mediator basically just uses Http and eliminates the need for for a web socket so 221 00:34:59.510 --> 00:35:08.259 Stephen Curran: That would be the aim for that, or sorry eliminates the need for punching the hole in the firewall. I don't know if if if how? 222 00:35:09.120 --> 00:35:12.520 Stephen Curran: how that affects things. So yeah. 223 00:35:13.200 --> 00:35:18.539 Stephen Curran: And a great again, bring your own device. That is what most of us have been doing. But 224 00:35:18.600 --> 00:35:22.379 Stephen Curran: some people on our team are not able to do that. So there you go. 225 00:35:24.270 --> 00:35:25.650 Stephen Curran: all right. 226 00:35:26.850 --> 00:35:29.810 Stephen Curran: Let me check here. 227 00:35:30.910 --> 00:35:35.889 Stephen Curran: Where is the last? Jason? Sierra talk. You are here. 228 00:35:36.090 --> 00:35:38.790 Stephen Curran: Excellent progress on deep. 229 00:35:39.040 --> 00:36:01.299 Stephen Curran: Yeah, I can. I? I don't need to share my screen. No? Well, I can just put a quick. Update. yeah. So look at that. Since then that did peer to 2, 2 to 3 specs I'm starting with, just did period 2 6 per labs has a python perioded library. That was not around the first time. Change. I looked at this. 230 00:36:01.300 --> 00:36:09.709 Jason Syrotuck: So I've been looking to integrate with that which has been a great resource to deal with some of the the number crunching and the the document construction itself. 231 00:36:10.260 --> 00:36:13.110 Jason Syrotuck: so that's a good thing for the community to be aware of. 232 00:36:13.180 --> 00:36:32.869 Jason Syrotuck: Similarly, was some conflicts between what any did could be, and it did. Here. Speck had the the the the Red X's defined by the specification, we're not compatible. so after some discussion and some updates, 233 00:36:33.170 --> 00:36:42.729 Jason Syrotuck: the root of that issue is that did period two's can have service entries which are base 64 encoded Jason. 234 00:36:43.400 --> 00:36:54.540 Jason Syrotuck: However, when you basic to chord code you may end up with some paddings. which is usually an equal sign. Well, equal sign is not a legal character. under the did spec 235 00:36:54.640 --> 00:37:00.989 Jason Syrotuck: So that was causing some confusion. However, we resolve that, and the the 236 00:37:01.130 --> 00:37:18.489 Jason Syrotuck: guidance and instructions going forward is that if you are basic C, 4, encoding something, you will need to strip equal signs off of that similar. Another similar reason to do this, and we think that and your right head at some point brought up is that if you have one, did with an equal sign, or one did without an equal sign. 237 00:37:18.640 --> 00:37:27.809 Jason Syrotuck: Those are the same. Did. We shouldn't have 2 kids that look different, but resolved to the same things. so for those 2 reasons. 238 00:37:28.080 --> 00:37:38.489 Jason Syrotuck: that's something to to be aware of as well. I don't know about any other did specs. But there they did peer to. includes the service entry as basic people encoded. 239 00:37:38.580 --> 00:38:03.260 Jason Syrotuck: so yeah. got a again. And I'm looking to build an additional did resolvers, and understand, I really didn't have. This is my first time really cracking open, occupy and understanding how connections are truly established. So I've been getting in there I've been creating, did, did, did did do to do to's now. But now I've got to figure out how to how to leverage them into into the payload and actually get 240 00:38:03.460 --> 00:38:09.189 Jason Syrotuck: them to be the the primary way that these connections are established, so still some progress to be done there. But 241 00:38:09.240 --> 00:38:16.960 Jason Syrotuck: that's kind of an update for the the community, or some things that have come to light and where we're going with 242 00:38:20.040 --> 00:38:22.620 Jason Syrotuck: any questions about that? 243 00:38:26.910 --> 00:38:30.679 Jason Syrotuck: Okay, there's an up to you. Pass back to Stephen. 244 00:38:30.750 --> 00:38:47.009 Stephen Curran: good stuff. That's super. Important as we get into. Now that 0 4 0 of a J is released. that's now going 0 4 0 is going into by fold, and therefore into various wallets. 245 00:38:47.370 --> 00:38:54.050 Stephen Curran: It is using pure dates instead of unqualified Ds for 246 00:38:54.290 --> 00:39:00.350 Stephen Curran: did calm communication to come messaging so super important to get that move forward. So that's good stuff. 247 00:39:02.010 --> 00:39:05.210 Stephen Curran: okay. 248 00:39:06.010 --> 00:39:20.659 Stephen Curran: Next was just an idea I've had this week that I wanted to share with others and see if anyone was interested in doing a quick, quick, and dirty project on this. One of the most painful parts of using occupy is the startup parameters. 249 00:39:21.270 --> 00:39:28.380 Stephen Curran: there's so many for good and bad reasons. There's lots of them 250 00:39:28.400 --> 00:39:43.290 Stephen Curran: being able to understand what parameters are available when you should use them, which ones you should use and making them easy to use, I think, would be handled nicely. rather than having the documentation we have today, which is basically. 251 00:39:43.850 --> 00:39:48.930 Stephen Curran: you know. spit out all of the options and then try to figure out which ones you need 252 00:39:48.950 --> 00:40:01.170 Stephen Curran: would be to have an actual editor, not not a Yaml editor, which you know there's lots of generic Yaml editors. But that doesn't really help with the domain 253 00:40:01.450 --> 00:40:12.160 Stephen Curran: issue we have of. Of how do you understand all the parameters, and how they relate to one another, and which ones you might or might not want to use in anyone, give that in any one scenario. So 254 00:40:12.530 --> 00:40:23.430 Stephen Curran: I actually had done a project a while ago that used survey. Js, so I was thinking that would be a way to do it. for those not familiar with survey. Js. 255 00:40:24.460 --> 00:40:34.500 Stephen Curran: it is basically a way a nice Jason and user and and Ui 256 00:40:34.660 --> 00:40:40.770 Stephen Curran: development tool for creating a library. So you can have a library like this. 257 00:40:41.070 --> 00:40:43.649 Stephen Curran: where you just add in 258 00:40:43.660 --> 00:40:52.690 Stephen Curran: questions. So it's it's basically using. It is a lot like using Google forms, you just add those in when you edit 259 00:40:52.810 --> 00:41:06.140 Stephen Curran: those, what you're really doing is creating a Json. Js, so you're basically just building up these elements so one could see that it would be really easy to take all of the. 260 00:41:06.250 --> 00:41:07.929 Stephen Curran: you know, 108 261 00:41:08.060 --> 00:41:14.259 Stephen Curran: the animal parameters, or or start up parameters that we have, and simply. 262 00:41:14.300 --> 00:41:20.540 Stephen Curran: first of all, generate them into one of these, and then go through one time to 263 00:41:20.960 --> 00:41:23.630 Stephen Curran: adjust them to 264 00:41:24.140 --> 00:41:37.729 Stephen Curran: have the help text for them. Have the your, your sorry, generate all the help text into them, generate the right data types group them provide additional details. So I think we could have a one time effort to go through 265 00:41:37.740 --> 00:41:49.660 Stephen Curran: and essentially using a Google forms and creating something like this. So we would half generate, half manually down. The the manual part would be important, because that's really providing the domain knowledge 266 00:41:50.360 --> 00:41:51.480 Stephen Curran: in there. 267 00:41:51.790 --> 00:41:57.180 Stephen Curran: once we do that that creates a nice package that 268 00:41:57.240 --> 00:42:09.939 Stephen Curran: you know the Json Js, that you saw there is is an active component, so that would be part of the tool and then have a little bit of javascript code to initialize 269 00:42:09.990 --> 00:42:14.000 Stephen Curran: or low settings. a a yaml file. 270 00:42:14.340 --> 00:42:21.040 Stephen Curran: put it into the format for the job survey Js format component, so that 271 00:42:21.160 --> 00:42:40.319 Stephen Curran: a user could use that survey Js Component actively to edit their their settings, and then a process for taking it out of the survey Js format and into it to to to save it. So I think that would be relatively light 272 00:42:40.470 --> 00:42:56.430 Stephen Curran: and then to maintain the tool over time, basically a a Github action that would monitor for changes in the startup parameters basically maintain a file within the repo. It takes the minus minus help output 273 00:42:56.650 --> 00:42:59.630 Stephen Curran: of the configuration data. 274 00:42:59.710 --> 00:43:12.769 Stephen Curran: and then a a Github action that runs a diff with that generates the latest output, diff it with the file we have, and creates an issue when the outputs differ. 275 00:43:12.970 --> 00:43:20.450 Stephen Curran: that if you would then bring her somebody to manually go in and adjust the components here. 276 00:43:21.100 --> 00:43:25.569 Stephen Curran: of the editor, and so it would be once the 277 00:43:26.370 --> 00:43:38.690 Stephen Curran: survey J as component, or whatever we use gets created, it would be maintaining it over. Time, I think, would be pretty simple as simple that these things do not change significantly 278 00:43:38.760 --> 00:43:41.949 Stephen Curran: over time. So it would be a 279 00:43:42.160 --> 00:43:53.160 Stephen Curran: periodic, you know, as we do a release. adjust and add whatever parameters were necessary to it. So an idea there! 280 00:43:54.540 --> 00:44:11.049 Stephen Curran: Hoping I triggered some interest. I would be very glad to help out if somebody else I would do this part of it, and was interested enough to do this part of it. I could definitely help out with the the the true documentation parts of this, which is 281 00:44:11.270 --> 00:44:20.160 Stephen Curran: actually generating a list and and making it a useful survey. Js Component, that we can maintain over time 282 00:44:22.340 --> 00:44:28.990 Stephen Curran: any thoughts, comments. Does anyone know of other tools like this that would be better to use 283 00:44:29.670 --> 00:44:32.929 Stephen Curran: and any experience in using these types of tools in the past. 284 00:44:37.460 --> 00:44:38.560 Stephen Curran: All right, then. 285 00:44:41.600 --> 00:44:51.409 Stephen Curran: I don't think we've only got a few prs, we really want to get 8 to done. Let me take a quick look at the Pr. As we have 286 00:45:05.470 --> 00:45:06.680 Stephen Curran: oops 287 00:45:09.050 --> 00:45:13.140 Stephen Curran: that wasn't good, and I probably shouldn't. Yeah, let me just go to there. 288 00:45:18.400 --> 00:45:29.800 Stephen Curran: would like somebody to review the read me, and every the updates that I've done pretty trivial. We've got the deaf container. We're holding that till after 289 00:45:29.890 --> 00:45:46.070 Stephen Curran: the 8 to release. this is the big one that I'm wondering if any. No progress has been made on this one. we really need somebody to that has a little bit of time to look at this one. Any comments on it. 290 00:45:47.180 --> 00:45:49.139 Stephen Curran: 3, 6, support dropping it. 291 00:45:52.240 --> 00:46:03.570 Daniel Bluhm: I left this as a as a comment already in in the er itself, but I did take some time to look through it, tried out a couple of things, still continuing to have the issue with 292 00:46:03.720 --> 00:46:05.400 Daniel Bluhm: the of action is timing up. 293 00:46:05.560 --> 00:46:13.570 Daniel Bluhm: so I don't really have much in the way of of real optics or progress here. But I was able to at least get some time to look at it. 294 00:46:14.820 --> 00:46:30.829 Jason Syrotuck: The Python Period Library that was written that I've been leveraging does not support 306, so that will those who are related. But again, I don't expect a a conflict, but just that is the means of this is a blocking change, as far as I'm considering, and probably the highest priority. Pr, we have 295 00:46:30.910 --> 00:46:45.179 Wade Barnes: do you want me to give a summary of sort of the testing that's been done so far? Okay, so basically what it is is. there's the Bdd test that get run the integration test that get run 296 00:46:45.530 --> 00:46:56.030 Wade Barnes: and what ends up happening is there's one in particular that triggers it. quite a bit. I've got links to all of the 297 00:46:56.040 --> 00:47:00.149 Wade Barnes: branches and everything that I that I've worked on as well as the the runs. 298 00:47:00.320 --> 00:47:09.849 Wade Barnes: But basically what happens is, an agent starts up, mediator starts up, and then the bob agent starts up and then it tries to start the bob mediator. 299 00:47:10.210 --> 00:47:11.590 Wade Barnes: and it just 300 00:47:11.770 --> 00:47:20.180 Wade Barnes: never does like nothing happens. And the process ends up timing out, and everything ends up either locking up or failing 301 00:47:20.650 --> 00:47:22.380 Wade Barnes: I've 302 00:47:22.820 --> 00:47:34.060 Wade Barnes: tried exactly what Daniel did. Tried extending the time out. That doesn't make a difference. So he extended it out to 10 min. so it it's not a timing issue. 303 00:47:34.210 --> 00:47:39.420 Wade Barnes: what I did do is I tried different versions of python. So 304 00:47:39.560 --> 00:47:50.919 Wade Barnes: tested in github actions and locally using 3, 6, 3, 7, 3, 8, and 3 9. The issue starts happening in Github actions at at 3 8 305 00:47:51.010 --> 00:47:57.580 Wade Barnes: where, if I run it locally. It works fine all the way up to 3 9, so I can't reproduce it locally. 306 00:47:57.650 --> 00:48:19.200 Wade Barnes: So it's very difficult to debug I created a different branch that does nothing more than starts the mediator. that can't start up with the parameters that are used by the test, and it starts up just fine. So I don't understand. I I really don't understand why it's not starting up in in 307 00:48:19.240 --> 00:48:21.410 Wade Barnes: the process of of the tests. 308 00:48:22.230 --> 00:48:36.679 Wade Barnes: funny thing is even it using python three-nine. Some of the integration tests work. So it seems to work when you have, you know, the one that runs before it is 309 00:48:36.760 --> 00:48:44.270 Wade Barnes: one meet one agent, one mediator, and a bob agent communicating together that one works fine, but as soon as you add that 310 00:48:44.470 --> 00:48:45.570 Wade Barnes: extra 311 00:48:45.950 --> 00:48:49.809 Wade Barnes: container. It seems to just not work. 312 00:48:50.980 --> 00:48:53.610 Wade Barnes: No. no idea why 313 00:48:58.100 --> 00:49:03.019 Stephen Curran: any thoughts from anyone on that you really use. Hop on this one. 314 00:49:10.490 --> 00:49:13.740 Stephen Curran: Hey? Thanks way, thanks, Dan. 315 00:49:15.620 --> 00:49:22.789 Stephen Curran: This one is held up by the 3 6, one Here it will be 316 00:49:23.560 --> 00:49:32.530 Stephen Curran: and then the rest, I think, are pretty much that we want to hold off until 317 00:49:32.910 --> 00:49:34.959 Stephen Curran: 8, 2 goes out. 318 00:49:35.120 --> 00:49:41.550 Stephen Curran: The big one we're waiting on that we had been waiting on was this one updates on this one. 319 00:49:41.840 --> 00:49:44.580 Stephen Curran: sandshot, do you have an update? 320 00:49:45.180 --> 00:49:56.850 Shaanjot Gill: So the implementation is done. So the confusion I had yesterday with according to the and you get got past that 321 00:49:56.940 --> 00:50:02.389 Shaanjot Gill: implementation of basically the test cases unit test is what I'm working on right now. 322 00:50:02.640 --> 00:50:07.790 Shaanjot Gill: and should be pretty soon, I think. Well. 323 00:50:07.820 --> 00:50:09.500 Shaanjot Gill: maybe before the 324 00:50:09.690 --> 00:50:14.119 Shaanjot Gill: that on the stand up, or maybe I can push the changes. 325 00:50:16.000 --> 00:50:24.449 Stephen Curran: is it worth pushing this into a 2 or 326 00:50:25.210 --> 00:50:35.340 Stephen Curran: Is this crucial to a 2? Or should we just put this as the next? The first one, you know, assuming it's ready very, very soon, assuming it's ready today. Do we want to? Just 327 00:50:35.480 --> 00:50:51.430 Stephen Curran: just because it is taking several iterations? it seems safer to put this into the next version. is there objections from anyone on on saying that we're not going to include this one in 8, 2, 328 00:50:51.500 --> 00:50:54.279 Stephen Curran: and we'll just put it. In the next version 329 00:50:56.440 --> 00:50:57.690 Stephen Curran: comments 330 00:50:59.400 --> 00:51:01.250 Shaanjot Gill: The only thing is the 331 00:51:01.380 --> 00:51:10.930 Shaanjot Gill: The changes are already in interaction that it depends on. this to be most time. I think that's the only dependency 332 00:51:11.310 --> 00:51:15.980 Shaanjot Gill: I can see. And regarding the iteration, I think this would be the final, because 333 00:51:16.170 --> 00:51:19.719 Shaanjot Gill: I don't see any more iterations after this. 334 00:51:20.960 --> 00:51:22.000 Stephen Curran: Okay? 335 00:51:27.680 --> 00:51:36.459 Stephen Curran: All right. I think that's all we have for today. Any other topics anyone wants to raise today. 336 00:51:43.830 --> 00:51:51.680 Stephen Curran: All right. Thanks for joining. Have a great Tuesday, or whatever is left of it, where you are. 337 00:51:51.690 --> 00:51:52.700 Jason Syrotuck: Thank you so much. 338 00:51:53.800 --> 00:51:55.160 Stephen Curran: Take care of folks, bye.