WEBVTT 00:00.000 --> 00:13.160 We are not going to talk about trust and safety, we are going to talk about matrix. 00:13.160 --> 00:14.160 Cool. 00:14.160 --> 00:15.160 Do we need intro? 00:15.160 --> 00:19.800 Hopefully most of you know us with the co-founders of matrix, Matthew is a tech lead. 00:19.800 --> 00:27.240 I'm doing a lot of the managing director of the foundation and the world needs matrix 00:27.240 --> 00:28.240 more than ever. 00:28.240 --> 00:33.880 I suspect I don't have to tell people about these digital sororities everywhere and luckily 00:33.880 --> 00:38.160 the public sector has realized it, I spent three days in non-tech events, I didn't have 00:38.160 --> 00:40.720 to explain what matrix is once. 00:40.720 --> 00:48.240 It's becoming the way public sector communicates across Europe, across the world and if 00:48.240 --> 00:52.840 you move forward, even the European Commission actually recommends it. 00:52.840 --> 00:54.080 So that's where we get to. 00:54.080 --> 00:59.560 So if you want to be the fund of what is public sector up to you can check the conference 00:59.560 --> 01:04.760 talks on the public sector tracks, there is really, really fun stuff happening. 01:04.760 --> 01:09.800 So a few examples of deployments there, most of you probably know chat in France, which 01:09.800 --> 01:16.720 be deployed everywhere, in Germany they have BWM, down 4C, Bundesmessenger, but also open 01:16.720 --> 01:22.360 their switch and bed elements, a lot of ministries in Sweden use element but also rocket 01:22.360 --> 01:29.280 chat because they've been pushing matrix as the standard to federate all the apps, maybe 01:29.280 --> 01:35.560 pretty soon, Mattermost and Luxembourg also have different flavors of their clients for 01:35.560 --> 01:39.520 looks chat for citizens, looks chat for gov, et cetera, et cetera. 01:39.520 --> 01:44.120 So this is what's happening and if you press one more, hopefully pretty soon we'll start 01:44.120 --> 01:50.960 seeing actual federations across all of these deployments and actively working on it. 01:50.960 --> 01:56.800 And as of Friday this is the report from the Swedish government saying hey this is really 01:56.800 --> 02:04.680 officially what we recommend if we want to actually be sovereign in our communications. 02:04.680 --> 02:09.480 So meanwhile the ecosystem itself is also continuing to grow. 02:09.480 --> 02:15.400 We have many, many matrix vendors and builders, there are a few on the slide, if you're 02:15.400 --> 02:18.920 a vendor you're not on the slide, become a member of the foundation and next year 02:18.920 --> 02:20.920 you will be on the slide as well. 02:20.920 --> 02:26.000 So you can see the diversification, it's coming and it's really fun to see everyone 02:26.000 --> 02:31.640 going around and providing really cool matrix services and products. 02:31.640 --> 02:34.520 And in terms of the more ticky side of things. 02:34.520 --> 02:41.520 So I apologize that people who saw the matrix conference keynote will be familiar with me 02:41.520 --> 02:46.000 trying to spell out just the breadth of the matrix ecosystem from a client perspective these 02:46.000 --> 02:47.000 days. 02:47.000 --> 02:50.920 Typically we have many different stacks going on, we've got ghost stacks, we've got the 02:50.920 --> 02:56.200 rest SDK, we've got loads of clients on the rest SDK, we've got the dark stack from 02:56.200 --> 03:02.120 famously, we've got the Kotley Multi Platform in the Tricks and T stack from Connect to X. 03:02.120 --> 03:07.840 We've tammy which got its 2.0 really CES today, which now switches to the Dozmaats for 03:07.840 --> 03:13.680 end-to-end encryption and talk to native IDC, then you've got all of the C++ stacks, 03:13.720 --> 03:19.040 you've got Neko, they're with MTX clients and you've got Neo chat, we've lived quotient, 03:19.040 --> 03:24.840 using cute, and then you've got the good old web stacks, using TSSDK element web and 03:24.840 --> 03:30.200 then C2, all of these are mature clients, these aren't just random projects we found 03:30.200 --> 03:36.800 on GitHub and I find it really exciting that you know pick a client environment there. 03:36.800 --> 03:41.160 I mean I'm a bit sad we don't have any sort of IBM mainframe native clients yet but 03:41.160 --> 03:47.640 that's clearly the next to Z series and Opportunity, but we also since I gave you the 03:47.640 --> 03:52.680 did that diagram back in my October, they're already newcomers, now these aren't mature yet, 03:52.680 --> 03:58.920 but it's really fun to see entirely new clients coming up, we've got Nexus from Henry there, 03:58.920 --> 04:03.560 and again if you look at the stack here, this is another combination, this is Flutter on Go, 04:05.400 --> 04:10.200 using the Go Max and the Mountflurks back end, which is really cool, not entirely sure 04:10.280 --> 04:13.640 that the Flutter guys have got in mind when they wrote Flutter, but hey, we'll take it, 04:15.000 --> 04:20.840 then a very recent new one is Sheldy Chat, the revenge, it's not entirely clear what Sheldy 04:20.840 --> 04:27.480 Chat is taking revenge on, but this is actually really, really cool, it's again using Flutter, 04:28.040 --> 04:33.080 is it using Flutter, have I got this wrong? Yeah, probably sorry, my diagram's wrong, 04:33.080 --> 04:38.200 imagine that this is Kotlin composed, as it will be in a second, this is just me having a 04:38.280 --> 04:45.560 spatial scrub, but using Rust SDK onto the hood, and then we've got Element X-Web, 04:45.560 --> 04:49.880 called Aurora, this isn't that much of a newcomer, and I started a couple of years ago, 04:49.880 --> 04:54.360 but it starts to get more and more momentum, there will be a talk about that later, from Dave and 04:54.360 --> 05:00.200 Florian, sitting on top of the Rust SDK, and then there's also another client, called Majors, 05:00.200 --> 05:06.840 anybody heard of Majors? Yeah, I just found this, most researching the tool, it looks really cool, 05:07.000 --> 05:13.160 built on Kotlin Multiplatform on top of Rust SDK, except I can get it to build, so 05:13.960 --> 05:19.240 I'm sure it's really cool, so I didn't talk about home servers, and so 05:20.600 --> 05:24.520 have anybody brought it, is there anyone familiar with this website, so Patrick Cloak's on the 05:24.520 --> 05:29.320 spec called team, and I don't know quite how he does this, and he hasn't told me how he's done this, 05:29.320 --> 05:33.960 but he's trying to build a family tree of every matrix or the ever, and here's the lineage, 05:34.600 --> 05:39.240 you can see synapse, the original going along the top, and then it gets split into what we 05:39.240 --> 05:47.000 call synapse today, when it shifted to HEPL, you got synapse pros, pro, fork, or variant of synapse 05:47.000 --> 05:51.480 up at the top, and then the list goes on, and I'm not going to go through that entire list, 05:51.480 --> 05:55.080 and there are ones there, which I couldn't find evidence of on the internet, like what is a 05:55.080 --> 05:59.720 worry, what? I don't know where he's got this from, I don't think he's making it up, 05:59.800 --> 06:05.000 he has matrix workers from CloudFlare, everybody's favorite matrix server, so I mean, 06:05.000 --> 06:10.200 it's definitely keeping it up today, but it's fascinating to see, particularly in the conduits, 06:10.200 --> 06:14.760 if you've been trying to figure out what the difference is between a conduit, from a continuity, 06:15.400 --> 06:18.840 a conduit and with a rest of it, who would tell an elf of that matter, then that shows the 06:18.840 --> 06:25.240 kind of family tree there. Now, a better way of visualizing it, perhaps, is how many servers 06:25.320 --> 06:31.240 really are there? Is this good news or not? And looking at the red graph, which is the 06:31.240 --> 06:35.480 ones actively being developed, so you can see, it comes and goes a bit, and obviously, 06:35.480 --> 06:41.080 started just with synapse back, naturally in my May 2014, but we released it in September, 06:41.080 --> 06:44.440 but since then, it's been going on further, and it's, I found it really interesting, 06:44.440 --> 06:48.840 in the last couple of years, it's really started to expand, obviously, they're a bunch of 06:48.840 --> 06:52.920 dead ones too, it's open source, everybody writes their favorite project, and then it 06:52.920 --> 07:00.920 pizzas out eventually. So, on the text side, the elephant in the room is maybe Matrix 2.0, 07:00.920 --> 07:05.960 where there are still four main MSCs, one of which has gone all the way through the process, and 07:05.960 --> 07:12.680 indeed got released, and Matrix 1.15, I had a 2.0, which has open ID, connect for next generation 07:12.680 --> 07:19.800 off. Slighting sync is still going through the FCP process, we are still finding edge cases 07:19.800 --> 07:25.800 and polishing it and trying to simplify it. Matrix RTC has had loads of work, and 07:25.800 --> 07:31.480 Travis, I saw, marked it, labeled it as proposed for FCP readiness, which means that it's not 07:31.480 --> 07:37.240 actually formally being queried to enter the final process, but we think it's ready, which is 07:37.240 --> 07:41.240 pretty cool, but it does have dependencies on two-ever MSCs there, and then finally, 07:41.240 --> 07:46.200 invisible crypto, which is basically excluding unverified devices from conversations as 07:46.200 --> 07:51.080 past FCP, but we actually need to wait for the ecosystem to capture up on doing this, which 07:51.080 --> 07:56.280 is meant to be a group, but this rate is going to slip a bit. This is going slower than we hoped, 07:56.280 --> 08:02.280 sorry, but just wanted to give an update on where things were there. However, a lot of work has 08:02.280 --> 08:08.120 been going into a parallel project, which is project Hydra. So Hydra is the whole mission to 08:08.120 --> 08:13.640 try to basically fix the state resolution, semantics, and matrix, and make it as robust, 08:13.640 --> 08:21.320 and basically, formally, verifiably robust to any sort of attacks. We set phase one of this 08:21.320 --> 08:27.240 last year, which fixed most of the common sort of worst classes of attacks, although some do 08:27.240 --> 08:33.320 remain, and then we also did a bunch of other changes, which I won't bore you with going through, 08:33.320 --> 08:39.240 because everybody here probably sat for it. Then we got phase two, which is additional robustness 08:39.320 --> 08:45.320 to right now, early 2026. First of all, I'm searching to state dags, and I explain what that 08:45.320 --> 08:51.080 is in a minute, and we ship the MSC for that last night, so this is brand new for phosem, and then 08:51.080 --> 08:58.360 separately, there is searching to account keys for user IDs, MSC443. Then finally, phase three, 08:58.360 --> 09:03.960 is finality, which we were assuming would happen probably late 2026, but we're actually trying 09:03.960 --> 09:09.640 to make that happen sooner, if you can imagine, essentially being ahead on schedule for something 09:09.640 --> 09:14.440 for once, and I'll talk about finality in a minute too. Now, please note, phase two and free, 09:14.440 --> 09:21.560 I'll completely up in the air. What I'm about to say is not a greed, formally approved, it doesn't 09:21.560 --> 09:26.600 represent consensus of anybody, frankly, of the me and key again, and possibly a dinosaur and 09:26.600 --> 09:32.520 the security team at the foundation, so it hasn't gone through an MSC process, but this is what 09:32.600 --> 09:39.160 it currently looks like. So your state dags, as I said, we shipped it yesterday, the whole idea here 09:39.160 --> 09:45.080 is that you make sure that all of the state events in a room are replicated across all of the 09:45.080 --> 09:51.160 servers, because a lot of the nasty edge cases that cool state resets happen, if for whatever reason, 09:51.160 --> 09:55.880 a server ends up with a slightly different set of view of the state of the room to someone else. 09:55.880 --> 10:01.000 And originally, we'd try to design matrix to allow for that, because, you know, be a bit more robust 10:01.000 --> 10:07.960 to partial views of the world, perhaps it would use less bandwidth, we wouldn't have to synchronise 10:07.960 --> 10:13.320 all the state events around. All it does is to make it really hard to reason about, in a formal way, 10:13.320 --> 10:19.080 and there are holes in it. So the idea here is rather than having all events to justify how your 10:19.080 --> 10:24.200 events get sent into the room, instead you calculate the off events by looking at all of the 10:24.200 --> 10:30.040 state events and the dotted lines here are the state dags of the room. It does mean that you have 10:30.040 --> 10:35.160 to synchronise more state when you join a room, and our initial implementation is of like Friday, 10:35.160 --> 10:39.000 it was about four times slower than what we have today, so obviously that isn't going to work, 10:39.000 --> 10:44.120 because joining is already horribly slow. However, with combination of faster room joins, 10:44.120 --> 10:49.320 I basically trust the state until you verify it and then you back out if it turns out to be in 10:49.320 --> 10:54.920 a lie, or use the righteases keys, we hope that we can make this at least as fast, if not a lot 10:54.920 --> 11:01.800 faster than the current implementation. Then the other part of it is user IDs, so we've already 11:01.800 --> 11:08.280 turned three IDs into being hashes and we've already turned event IDs into being hashes, 11:08.280 --> 11:13.560 why don't we turn user IDs into not quite being hashes, but at least ugly public keys. 11:13.560 --> 11:18.840 Now this is under the hood, the whole idea is that user IDs right now are basically not GDPR 11:18.840 --> 11:24.840 compliant. They could contain direct personal information, like your name, Matthew, for instance, 11:24.840 --> 11:29.960 and if I then want to GDPR erase myself, I can't, because my matrix ID is all over the internet, 11:29.960 --> 11:34.200 we'll go over these dags, I can't retrospectively say Matthew was never here, 11:34.200 --> 11:39.320 instead here as a pseudonymous identifier that leaves behind. Also, they can obviously be abusive. 11:39.880 --> 11:44.840 So for what we've done is to try to propose the minimum viable solution that will be compatible 11:44.840 --> 11:51.560 with today's matrix, and it's MSC443, basically every account gets an account keeper, which is stored 11:51.560 --> 11:57.000 on the server, and it basically shows where your account lives, events now signed by the private key 11:57.000 --> 12:02.520 of that account key rather than the server signing key. And then the user IDs on the wire, 12:02.520 --> 12:08.440 on Federation, and persistent, the dags become a really ugly curve 2, 5, 4, 9 public key. 12:09.080 --> 12:14.600 But from the CSAP, nothing changes. It just comes back to you, a mapped back to a human readable 12:14.600 --> 12:20.200 sender. So implementation is underway, it could speed things up all loads, because you don't need 12:20.200 --> 12:24.440 to check the server signing key anymore, because the events are effectively so verifiable, 12:24.440 --> 12:30.440 because they are, well, they include the public key at the sender there. 12:30.840 --> 12:38.920 Then, finally, funality. So the final problem that we have to solve is how do you stop users 12:38.920 --> 12:44.200 backdating events in a room? How do you, if you create a room, I don't know, somebody gives you 12:44.200 --> 12:51.480 admin in a room, and then you get to motive later on, what stops you going back in time to day one 12:51.480 --> 12:55.800 when you wear an admin and saying, wow, actually, I'm going to kick everyone. No, that sort of 12:55.800 --> 13:02.760 nasty baddating attack is unfortunately a thing. So what if we could seal room history, 13:02.760 --> 13:06.680 once you all of the servers have called up to give them a point in the dags, and you have 13:06.680 --> 13:11.080 typically finalized what we're calling an epoch of that dag. And I'm afraid we don't have an MSC 13:11.080 --> 13:18.520 for that yet, but we do have a paper. Now, I should make it clear that I'm entirely stealing all 13:18.520 --> 13:23.000 of Kegens work on this and passing it off his mind. Sorry, I'm not really his all-kigens work. 13:23.960 --> 13:29.800 And what he's done is to try to write up a formal paper, which is submitted to a conference 13:29.800 --> 13:37.640 on CRDTs, to try to formalize what the concept of finale is, and explore the entire space 13:37.640 --> 13:43.000 of how you can solve it in different ways. The URL is there, but the TLDR is that rooms basically 13:43.000 --> 13:47.960 could have a finale server, which is probably the owners server, and it sends our epoch events 13:48.040 --> 13:53.080 which finalize the dag up to that point. And it looks like this sort of thing that you'd 13:53.080 --> 13:58.600 have a bunch of events on a room, then the most senior server says, right, everyone that's the 13:58.600 --> 14:03.320 end of that epoch, and you consider everything up to that point sealed, then you have an 14:03.320 --> 14:09.720 every epoch and an everyone exception. And the whole idea is basically people then can't go back 14:09.720 --> 14:14.520 and try to mess around with previous epochs if they do that, they effectively create a new epoch, 14:14.520 --> 14:20.840 and it also means that everyone can discard the state and the data and any optimizations for 14:20.840 --> 14:26.600 the previous epochs. This could be huge in terms of fixing disk space, because you do not need 14:26.600 --> 14:34.680 state stamp shots for old stuff anymore. Then Rust SDK just lots of polish really, I won't 14:34.680 --> 14:39.560 bore you by reading through the list, read the change lock, it's good. Trust and safety, I'm not going 14:39.560 --> 14:44.120 to talk about trust and safety, because we've already had like free talks about trust and safety, 14:44.120 --> 14:50.600 except there's one thing that I think that we didn't say, which is that without a step change, 14:50.600 --> 14:57.640 decentralization will fail. I would even go as far as to say that the entire internet will fail. 14:57.640 --> 15:01.320 It will become the biggest propaganda and disinformation weapon all time, 15:01.320 --> 15:06.760 and frankly we're seeing it happen right now in front of us, and I find that really depressing. 15:06.840 --> 15:11.800 Like this could be how the human species fails, and it's because we failed to actually 15:11.800 --> 15:17.240 build safety tooling into the fabric of the internet or the web in a way that stopped the 15:17.240 --> 15:22.600 humans tearing it shove it to shreds. So my take on that personally is that we have to build 15:22.600 --> 15:27.560 a privacy preserving, morally relative reputation system that allows us to distinguish the 15:27.560 --> 15:31.880 slot from the humans, the spam from the ham, the abusers from the allies. I think the 15:31.880 --> 15:37.560 risk work is really, really, really cool. I'm a bit terrified that it does require, effectively, 15:37.560 --> 15:41.560 being able to see everything that's going on, which may be fine if you're a public thing, 15:41.560 --> 15:45.960 like blue sky or discolored. It's not so great necessarily our matrix. We don't want to build 15:45.960 --> 15:50.440 the world's biggest surveillance system. I've actually been working on this as my pet project 15:50.440 --> 15:54.760 for the last couple of months. If anybody wants to geek out with me about symmetric multipel 15:54.760 --> 16:00.440 to your compensation and zero knowledge, privacy preserving relative systems so that you can tell 16:00.440 --> 16:05.880 whether it's a block or accept an invite based on a trust graph come and talk to me. 16:07.160 --> 16:13.080 Then crypto, UTDs hopefully are still decreasing, loads of work on history sharing, lots of 16:13.080 --> 16:18.120 work on excluding unverified devices. We've been thinking a lot about recovery key management 16:18.120 --> 16:25.880 and things like PRFs and pastkeys or UB keys or FIDO tokens, etc. And then huge amounts of 16:25.880 --> 16:30.920 work going on on MLS. We've got three different approaches still flying around. Does MLS manage the 16:30.920 --> 16:35.640 room membership rather than matrixed? Does matrix manage it with each sender of maintaining an 16:35.640 --> 16:41.240 an MLS tree? I think he but's got a tool come this late today and does matrix manage the membership 16:41.240 --> 16:46.120 and then do decentralize everything. Finally, lots of planning and trying to get funding for post 16:46.120 --> 16:52.440 quantum resilient matrix. Finally, almost on the text. So, PIPP matrix is progressing again 16:52.520 --> 16:56.520 as of November. Huge thanks to the Dutch Ministry of Defence for funding element to work on it 16:56.520 --> 17:03.560 as open source software. So, our approach here is to basically ignore overlays and figure this 17:03.560 --> 17:09.320 out regardless of the overlay that users on the network. Use matrix overs as they sit today for 17:09.320 --> 17:13.400 store and forward. Trying to keep it really simple and stupid. I think previously we're trying 17:13.400 --> 17:18.600 to boil the ocean and do the most complex and comprehensive thing possible. Strip down the 17:18.600 --> 17:23.640 features that enormously to really simple client-side implementation and critically not yet 17:23.640 --> 17:29.320 replaced today's matrix but instead have something that just works over Laura and MeshNet works 17:29.320 --> 17:33.880 and things. What's next? Well, basically finishing all the things. I just talked about. 17:35.000 --> 17:43.320 Finally to you. Right, supporting matrix. Just a quick work on the foundation itself. 17:44.280 --> 17:49.880 We have formation of the foundation. We need to make sure that matrix stays kind of a 17:49.880 --> 17:55.080 canonical standard and fragmented standard. We need to make lots of noise about it so that we have 17:55.080 --> 17:59.960 more users on a bigger network and it becomes the communication layer of the web that is 17:59.960 --> 18:06.280 aims to be. Make sure that all the players are seen and heard and can grow and make sure we have a safe 18:06.280 --> 18:11.320 network. Basically, it's tech, it's governance, it's marketing, it's trust and safety. That's the 18:11.320 --> 18:16.520 fourth thing we do and they are important if we want matrix to move forward. So how we work, 18:16.520 --> 18:23.480 structure, the gardens are here like Matthew myself and Ross and John as independence. 18:23.480 --> 18:29.000 Spec core team, mostly volunteers, foundation staff, not that big. We have fun about 18:29.000 --> 18:34.200 for full-time employees, some of the writers to help, part-time contractors, a lot of them, 18:35.160 --> 18:41.320 but a lot of us in coordination and the governing board who are all volunteers and elected 18:41.320 --> 18:48.280 from all the stakeholders in the community so they represent the spec core team. The members, 18:48.280 --> 18:54.200 the paid members, the ecosystem members, people building on matrix etc etc. So these are the people 18:54.200 --> 18:59.720 who keep an eye on what's going on there. And these are the people who handle the different 18:59.800 --> 19:04.120 committees who actually do the work. So not the committees are doing the work, but the working 19:04.120 --> 19:09.640 groups within the communities are doing the work. And basically how it looks, the gardens are here 19:09.640 --> 19:16.040 to control, but the governing board is here to advise, but everyone else is actually the one doing 19:16.040 --> 19:23.640 stuff. And these are where we need help. For example, the matrix conference, excellent example 19:23.640 --> 19:32.840 of the events working group doing its thing. We had 200, almost 300 attendees, but 40 volunteers 19:32.840 --> 19:37.160 to actually keep the thing running. So thank you. And that's what the community is about. 19:38.520 --> 19:45.560 Lots of everything is recorded, etc. etc. So really cool to see the ecosystem coming together. 19:45.560 --> 19:52.840 Next year, it's announced. It will happen in Sweden, Malme, October 2026, any looking for sponsors 19:52.920 --> 19:58.120 need to find a venue, need to find the specific date, but the call for proposal is open. So 19:58.120 --> 20:02.840 is there anything cool you want to talk about in October and Malme, please please please start 20:02.840 --> 20:11.320 to submit your stuff here. It'd be really cool. Next, of course, a bit of funding. Thank you 20:11.320 --> 20:16.680 to all the member funding members of the foundation here with double the numbers of members in 20:16.680 --> 20:24.360 2025, not the amount. We really need more of the larger sponsors to support the work we're doing here. 20:26.280 --> 20:31.160 This is the link. If you want to keep the foundation going, that's where you need to go. 20:32.040 --> 20:36.280 We've also set up something new, which are premium accounts on matrix.org, only for 20:36.280 --> 20:41.880 red newly registered users for now. It's mostly because basically the matrix.org server is one of 20:41.960 --> 20:47.160 the biggest cost center for the foundation, but it's also essential. Anyone moving to matrix needs 20:47.160 --> 20:51.880 somewhere until we have peer to peer. We need somewhere for them to create an account. So we need 20:51.880 --> 20:58.280 matrix.org and hopefully then they can go and go some other servers when they've tried and played with 20:58.280 --> 21:04.600 it. So this is going to help. We set it more relevant than ever. We really need secure and so 21:04.600 --> 21:10.440 rain communications for everyone, not just the government, all of us. The growth of matrix is 21:10.520 --> 21:16.360 really starting to go through the roof. It's even went to space. That was a really cool project 21:17.240 --> 21:25.320 for medical care over matrix in a simulated moonwalk. Honestly, I have a matrix client on the moon. 21:27.320 --> 21:33.400 But yes, we need to use it. Get your friends to install any of the really cool clients. We have 21:33.400 --> 21:40.040 out there and start using it. Continue to build cool stuff on matrix because there is so much 21:40.040 --> 21:45.640 stuff happening. It's really amazing. Become a matrix vendor, post it, do some integrations, 21:45.640 --> 21:50.200 resell whatever, but let's grow the ecosystem. Let's go the open source economy. 21:50.920 --> 21:57.160 During the working groups, there is a lot of things that you can do to help us get stuff down there. 21:57.160 --> 22:02.280 Of course, John the Foundation as a paying member, even better. And if you buy matrix solutions, 22:02.280 --> 22:05.960 please make sure that they actually support the upstream or support the Foundation at least. 22:07.320 --> 22:09.000 Thank you. 22:13.000 --> 22:14.360 We have two minutes for questions. 22:20.040 --> 22:22.360 No questions. Excellent. I hope it's the next one. 22:22.600 --> 22:25.720 I'm just walking around. Oh, I don't know. 22:29.720 --> 22:36.120 Yeah, we need to update our VP to be. I guess it is reflecting the previous incarnation of the project. 22:36.120 --> 22:41.320 And given as you heard, we've changed the goalposts a lot to try to make it more bite-sized and manageable. 22:42.840 --> 22:48.520 We need to have something to release first and so far the work has been 22:49.480 --> 22:54.200 basically remembering how it all works and getting the previous stuff to work again and then trying to decide 22:54.200 --> 22:59.880 how it works for going forwards. Hopefully that work will begin properly again next month in February. 22:59.880 --> 23:04.840 Well, this month I guess now. And yep, we will update that and use it as the single source of truth. 23:09.240 --> 23:10.200 Oh, there's a question. 23:18.600 --> 23:24.680 Uh, choosing a closest to your record server in the U.S. language. We're on board. 23:25.480 --> 23:29.240 Can you make your code about doing something similar to not having a lot of information or 23:29.240 --> 23:33.240 but to put it up and not to all of that kind of ones use your word? 23:34.280 --> 23:35.640 I can take that if you want. 23:35.640 --> 23:42.200 Um, yeah, I think there is certainly the last governing board discussion. This came up explicitly 23:42.200 --> 23:46.520 as to whether there should be a dedicated working group for figuring out how to read people to 23:46.520 --> 23:54.280 different servers. Um, the concern is, uh, I guess the experience of the onboarding 23:54.280 --> 23:58.040 user because at least if they're using metrics that will, they know that they have a whole 23:58.040 --> 24:03.160 fleet of, taking a nest tooling these days, hopefully to try to end up protecting them 24:03.160 --> 24:06.760 et cetera. Whereas if you just pick a totally random geographically nearest server, 24:06.760 --> 24:10.600 it was done by somebody who isn't particularly invested and isn't moderating it very well, 24:10.600 --> 24:12.200 that could end up being that negative. 24:12.840 --> 24:16.600 But I guess it's part of the work of the, this working group. I can't remember. I don't think 24:16.600 --> 24:22.600 it's officially set up, but I should have listed it. Um, and how do you figure it out so that, yes, 24:22.600 --> 24:27.160 you can get people to register in other servers in a nice way so that it's usable and not 24:27.160 --> 24:30.200 carry for people who are coming from proprietary services. 24:30.200 --> 24:35.560 Yeah, at least we need a better page like one that masters on them have of listing options 24:35.560 --> 24:42.360 if servers have that as a first-class thing. Where, out of time. Okay. Thank you. We'll take 24:42.360 --> 24:46.360 question in the, in a more if needed.