We are not going to talk about trust and safety, we are going to talk about matrix.
Cool.
Do we need intro?
Hopefully most of you know us with the co-founders of matrix, Matthew is a tech lead.
I'm doing a lot of the managing director of the foundation and the world needs matrix
more than ever.
I suspect I don't have to tell people about these digital sororities everywhere and luckily
the public sector has realized it, I spent three days in non-tech events, I didn't have
to explain what matrix is once.
It's becoming the way public sector communicates across Europe, across the world and if
you move forward, even the European Commission actually recommends it.
So that's where we get to.
So if you want to be the fund of what is public sector up to you can check the conference
talks on the public sector tracks, there is really, really fun stuff happening.
So a few examples of deployments there, most of you probably know chat in France, which
be deployed everywhere, in Germany they have BWM, down 4C, Bundesmessenger, but also open
their switch and bed elements, a lot of ministries in Sweden use element but also rocket
chat because they've been pushing matrix as the standard to federate all the apps, maybe
pretty soon, Mattermost and Luxembourg also have different flavors of their clients for
looks chat for citizens, looks chat for gov, et cetera, et cetera.
So this is what's happening and if you press one more, hopefully pretty soon we'll start
seeing actual federations across all of these deployments and actively working on it.
And as of Friday this is the report from the Swedish government saying hey this is really
officially what we recommend if we want to actually be sovereign in our communications.
So meanwhile the ecosystem itself is also continuing to grow.
We have many, many matrix vendors and builders, there are a few on the slide, if you're
a vendor you're not on the slide, become a member of the foundation and next year
you will be on the slide as well.
So you can see the diversification, it's coming and it's really fun to see everyone
going around and providing really cool matrix services and products.
And in terms of the more ticky side of things.
So I apologize that people who saw the matrix conference keynote will be familiar with me
trying to spell out just the breadth of the matrix ecosystem from a client perspective these
days.
Typically we have many different stacks going on, we've got ghost stacks, we've got the
rest SDK, we've got loads of clients on the rest SDK, we've got the dark stack from
famously, we've got the Kotley Multi Platform in the Tricks and T stack from Connect to X.
We've tammy which got its 2.0 really CES today, which now switches to the Dozmaats for
end-to-end encryption and talk to native IDC, then you've got all of the C++ stacks,
you've got Neko, they're with MTX clients and you've got Neo chat, we've lived quotient,
using cute, and then you've got the good old web stacks, using TSSDK element web and
then C2, all of these are mature clients, these aren't just random projects we found
on GitHub and I find it really exciting that you know pick a client environment there.
I mean I'm a bit sad we don't have any sort of IBM mainframe native clients yet but
that's clearly the next to Z series and Opportunity, but we also since I gave you the
did that diagram back in my October, they're already newcomers, now these aren't mature yet,
but it's really fun to see entirely new clients coming up, we've got Nexus from Henry there,
and again if you look at the stack here, this is another combination, this is Flutter on Go,
using the Go Max and the Mountflurks back end, which is really cool, not entirely sure
that the Flutter guys have got in mind when they wrote Flutter, but hey, we'll take it,
then a very recent new one is Sheldy Chat, the revenge, it's not entirely clear what Sheldy
Chat is taking revenge on, but this is actually really, really cool, it's again using Flutter,
is it using Flutter, have I got this wrong? Yeah, probably sorry, my diagram's wrong,
imagine that this is Kotlin composed, as it will be in a second, this is just me having a
spatial scrub, but using Rust SDK onto the hood, and then we've got Element X-Web,
called Aurora, this isn't that much of a newcomer, and I started a couple of years ago,
but it starts to get more and more momentum, there will be a talk about that later, from Dave and
Florian, sitting on top of the Rust SDK, and then there's also another client, called Majors,
anybody heard of Majors? Yeah, I just found this, most researching the tool, it looks really cool,
built on Kotlin Multiplatform on top of Rust SDK, except I can get it to build, so
I'm sure it's really cool, so I didn't talk about home servers, and so
have anybody brought it, is there anyone familiar with this website, so Patrick Cloak's on the
spec called team, and I don't know quite how he does this, and he hasn't told me how he's done this,
but he's trying to build a family tree of every matrix or the ever, and here's the lineage,
you can see synapse, the original going along the top, and then it gets split into what we
call synapse today, when it shifted to HEPL, you got synapse pros, pro, fork, or variant of synapse
up at the top, and then the list goes on, and I'm not going to go through that entire list,
and there are ones there, which I couldn't find evidence of on the internet, like what is a
worry, what? I don't know where he's got this from, I don't think he's making it up,
he has matrix workers from CloudFlare, everybody's favorite matrix server, so I mean,
it's definitely keeping it up today, but it's fascinating to see, particularly in the conduits,
if you've been trying to figure out what the difference is between a conduit, from a continuity,
a conduit and with a rest of it, who would tell an elf of that matter, then that shows the
kind of family tree there. Now, a better way of visualizing it, perhaps, is how many servers
really are there? Is this good news or not? And looking at the red graph, which is the
ones actively being developed, so you can see, it comes and goes a bit, and obviously,
started just with synapse back, naturally in my May 2014, but we released it in September,
but since then, it's been going on further, and it's, I found it really interesting,
in the last couple of years, it's really started to expand, obviously, they're a bunch of
dead ones too, it's open source, everybody writes their favorite project, and then it
pizzas out eventually. So, on the text side, the elephant in the room is maybe Matrix 2.0,
where there are still four main MSCs, one of which has gone all the way through the process, and
indeed got released, and Matrix 1.15, I had a 2.0, which has open ID, connect for next generation
off. Slighting sync is still going through the FCP process, we are still finding edge cases
and polishing it and trying to simplify it. Matrix RTC has had loads of work, and
Travis, I saw, marked it, labeled it as proposed for FCP readiness, which means that it's not
actually formally being queried to enter the final process, but we think it's ready, which is
pretty cool, but it does have dependencies on two-ever MSCs there, and then finally,
invisible crypto, which is basically excluding unverified devices from conversations as
past FCP, but we actually need to wait for the ecosystem to capture up on doing this, which
is meant to be a group, but this rate is going to slip a bit. This is going slower than we hoped,
sorry, but just wanted to give an update on where things were there. However, a lot of work has
been going into a parallel project, which is project Hydra. So Hydra is the whole mission to
try to basically fix the state resolution, semantics, and matrix, and make it as robust,
and basically, formally, verifiably robust to any sort of attacks. We set phase one of this
last year, which fixed most of the common sort of worst classes of attacks, although some do
remain, and then we also did a bunch of other changes, which I won't bore you with going through,
because everybody here probably sat for it. Then we got phase two, which is additional robustness
to right now, early 2026. First of all, I'm searching to state dags, and I explain what that
is in a minute, and we ship the MSC for that last night, so this is brand new for phosem, and then
separately, there is searching to account keys for user IDs, MSC443. Then finally, phase three,
is finality, which we were assuming would happen probably late 2026, but we're actually trying
to make that happen sooner, if you can imagine, essentially being ahead on schedule for something
for once, and I'll talk about finality in a minute too. Now, please note, phase two and free,
I'll completely up in the air. What I'm about to say is not a greed, formally approved, it doesn't
represent consensus of anybody, frankly, of the me and key again, and possibly a dinosaur and
the security team at the foundation, so it hasn't gone through an MSC process, but this is what
it currently looks like. So your state dags, as I said, we shipped it yesterday, the whole idea here
is that you make sure that all of the state events in a room are replicated across all of the
servers, because a lot of the nasty edge cases that cool state resets happen, if for whatever reason,
a server ends up with a slightly different set of view of the state of the room to someone else.
And originally, we'd try to design matrix to allow for that, because, you know, be a bit more robust
to partial views of the world, perhaps it would use less bandwidth, we wouldn't have to synchronise
all the state events around. All it does is to make it really hard to reason about, in a formal way,
and there are holes in it. So the idea here is rather than having all events to justify how your
events get sent into the room, instead you calculate the off events by looking at all of the
state events and the dotted lines here are the state dags of the room. It does mean that you have
to synchronise more state when you join a room, and our initial implementation is of like Friday,
it was about four times slower than what we have today, so obviously that isn't going to work,
because joining is already horribly slow. However, with combination of faster room joins,
I basically trust the state until you verify it and then you back out if it turns out to be in
a lie, or use the righteases keys, we hope that we can make this at least as fast, if not a lot
faster than the current implementation. Then the other part of it is user IDs, so we've already
turned three IDs into being hashes and we've already turned event IDs into being hashes,
why don't we turn user IDs into not quite being hashes, but at least ugly public keys.
Now this is under the hood, the whole idea is that user IDs right now are basically not GDPR
compliant. They could contain direct personal information, like your name, Matthew, for instance,
and if I then want to GDPR erase myself, I can't, because my matrix ID is all over the internet,
we'll go over these dags, I can't retrospectively say Matthew was never here,
instead here as a pseudonymous identifier that leaves behind. Also, they can obviously be abusive.
So for what we've done is to try to propose the minimum viable solution that will be compatible
with today's matrix, and it's MSC443, basically every account gets an account keeper, which is stored
on the server, and it basically shows where your account lives, events now signed by the private key
of that account key rather than the server signing key. And then the user IDs on the wire,
on Federation, and persistent, the dags become a really ugly curve 2, 5, 4, 9 public key.
But from the CSAP, nothing changes. It just comes back to you, a mapped back to a human readable
sender. So implementation is underway, it could speed things up all loads, because you don't need
to check the server signing key anymore, because the events are effectively so verifiable,
because they are, well, they include the public key at the sender there.
Then, finally, funality. So the final problem that we have to solve is how do you stop users
backdating events in a room? How do you, if you create a room, I don't know, somebody gives you
admin in a room, and then you get to motive later on, what stops you going back in time to day one
when you wear an admin and saying, wow, actually, I'm going to kick everyone. No, that sort of
nasty baddating attack is unfortunately a thing. So what if we could seal room history,
once you all of the servers have called up to give them a point in the dags, and you have
typically finalized what we're calling an epoch of that dag. And I'm afraid we don't have an MSC
for that yet, but we do have a paper. Now, I should make it clear that I'm entirely stealing all
of Kegens work on this and passing it off his mind. Sorry, I'm not really his all-kigens work.
And what he's done is to try to write up a formal paper, which is submitted to a conference
on CRDTs, to try to formalize what the concept of finale is, and explore the entire space
of how you can solve it in different ways. The URL is there, but the TLDR is that rooms basically
could have a finale server, which is probably the owners server, and it sends our epoch events
which finalize the dag up to that point. And it looks like this sort of thing that you'd
have a bunch of events on a room, then the most senior server says, right, everyone that's the
end of that epoch, and you consider everything up to that point sealed, then you have an
every epoch and an everyone exception. And the whole idea is basically people then can't go back
and try to mess around with previous epochs if they do that, they effectively create a new epoch,
and it also means that everyone can discard the state and the data and any optimizations for
the previous epochs. This could be huge in terms of fixing disk space, because you do not need
state stamp shots for old stuff anymore. Then Rust SDK just lots of polish really, I won't
bore you by reading through the list, read the change lock, it's good. Trust and safety, I'm not going
to talk about trust and safety, because we've already had like free talks about trust and safety,
except there's one thing that I think that we didn't say, which is that without a step change,
decentralization will fail. I would even go as far as to say that the entire internet will fail.
It will become the biggest propaganda and disinformation weapon all time,
and frankly we're seeing it happen right now in front of us, and I find that really depressing.
Like this could be how the human species fails, and it's because we failed to actually
build safety tooling into the fabric of the internet or the web in a way that stopped the
humans tearing it shove it to shreds. So my take on that personally is that we have to build
a privacy preserving, morally relative reputation system that allows us to distinguish the
slot from the humans, the spam from the ham, the abusers from the allies. I think the
risk work is really, really, really cool. I'm a bit terrified that it does require, effectively,
being able to see everything that's going on, which may be fine if you're a public thing,
like blue sky or discolored. It's not so great necessarily our matrix. We don't want to build
the world's biggest surveillance system. I've actually been working on this as my pet project
for the last couple of months. If anybody wants to geek out with me about symmetric multipel
to your compensation and zero knowledge, privacy preserving relative systems so that you can tell
whether it's a block or accept an invite based on a trust graph come and talk to me.
Then crypto, UTDs hopefully are still decreasing, loads of work on history sharing, lots of
work on excluding unverified devices. We've been thinking a lot about recovery key management
and things like PRFs and pastkeys or UB keys or FIDO tokens, etc. And then huge amounts of
work going on on MLS. We've got three different approaches still flying around. Does MLS manage the
room membership rather than matrixed? Does matrix manage it with each sender of maintaining an
an MLS tree? I think he but's got a tool come this late today and does matrix manage the membership
and then do decentralize everything. Finally, lots of planning and trying to get funding for post
quantum resilient matrix. Finally, almost on the text. So, PIPP matrix is progressing again
as of November. Huge thanks to the Dutch Ministry of Defence for funding element to work on it
as open source software. So, our approach here is to basically ignore overlays and figure this
out regardless of the overlay that users on the network. Use matrix overs as they sit today for
store and forward. Trying to keep it really simple and stupid. I think previously we're trying
to boil the ocean and do the most complex and comprehensive thing possible. Strip down the
features that enormously to really simple client-side implementation and critically not yet
replaced today's matrix but instead have something that just works over Laura and MeshNet works
and things. What's next? Well, basically finishing all the things. I just talked about.
Finally to you. Right, supporting matrix. Just a quick work on the foundation itself.
We have formation of the foundation. We need to make sure that matrix stays kind of a
canonical standard and fragmented standard. We need to make lots of noise about it so that we have
more users on a bigger network and it becomes the communication layer of the web that is
aims to be. Make sure that all the players are seen and heard and can grow and make sure we have a safe
network. Basically, it's tech, it's governance, it's marketing, it's trust and safety. That's the
fourth thing we do and they are important if we want matrix to move forward. So how we work,
structure, the gardens are here like Matthew myself and Ross and John as independence.
Spec core team, mostly volunteers, foundation staff, not that big. We have fun about
for full-time employees, some of the writers to help, part-time contractors, a lot of them,
but a lot of us in coordination and the governing board who are all volunteers and elected
from all the stakeholders in the community so they represent the spec core team. The members,
the paid members, the ecosystem members, people building on matrix etc etc. So these are the people
who keep an eye on what's going on there. And these are the people who handle the different
committees who actually do the work. So not the committees are doing the work, but the working
groups within the communities are doing the work. And basically how it looks, the gardens are here
to control, but the governing board is here to advise, but everyone else is actually the one doing
stuff. And these are where we need help. For example, the matrix conference, excellent example
of the events working group doing its thing. We had 200, almost 300 attendees, but 40 volunteers
to actually keep the thing running. So thank you. And that's what the community is about.
Lots of everything is recorded, etc. etc. So really cool to see the ecosystem coming together.
Next year, it's announced. It will happen in Sweden, Malme, October 2026, any looking for sponsors
need to find a venue, need to find the specific date, but the call for proposal is open. So
is there anything cool you want to talk about in October and Malme, please please please start
to submit your stuff here. It'd be really cool. Next, of course, a bit of funding. Thank you
to all the member funding members of the foundation here with double the numbers of members in
2025, not the amount. We really need more of the larger sponsors to support the work we're doing here.
This is the link. If you want to keep the foundation going, that's where you need to go.
We've also set up something new, which are premium accounts on matrix.org, only for
red newly registered users for now. It's mostly because basically the matrix.org server is one of
the biggest cost center for the foundation, but it's also essential. Anyone moving to matrix needs
somewhere until we have peer to peer. We need somewhere for them to create an account. So we need
matrix.org and hopefully then they can go and go some other servers when they've tried and played with
it. So this is going to help. We set it more relevant than ever. We really need secure and so
rain communications for everyone, not just the government, all of us. The growth of matrix is
really starting to go through the roof. It's even went to space. That was a really cool project
for medical care over matrix in a simulated moonwalk. Honestly, I have a matrix client on the moon.
But yes, we need to use it. Get your friends to install any of the really cool clients. We have
out there and start using it. Continue to build cool stuff on matrix because there is so much
stuff happening. It's really amazing. Become a matrix vendor, post it, do some integrations,
resell whatever, but let's grow the ecosystem. Let's go the open source economy.
During the working groups, there is a lot of things that you can do to help us get stuff down there.
Of course, John the Foundation as a paying member, even better. And if you buy matrix solutions,
please make sure that they actually support the upstream or support the Foundation at least.
Thank you.
We have two minutes for questions.
No questions. Excellent. I hope it's the next one.
I'm just walking around. Oh, I don't know.
Yeah, we need to update our VP to be. I guess it is reflecting the previous incarnation of the project.
And given as you heard, we've changed the goalposts a lot to try to make it more bite-sized and manageable.
We need to have something to release first and so far the work has been
basically remembering how it all works and getting the previous stuff to work again and then trying to decide
how it works for going forwards. Hopefully that work will begin properly again next month in February.
Well, this month I guess now. And yep, we will update that and use it as the single source of truth.
Oh, there's a question.
Uh, choosing a closest to your record server in the U.S. language. We're on board.
Can you make your code about doing something similar to not having a lot of information or
but to put it up and not to all of that kind of ones use your word?
I can take that if you want.
Um, yeah, I think there is certainly the last governing board discussion. This came up explicitly
as to whether there should be a dedicated working group for figuring out how to read people to
different servers. Um, the concern is, uh, I guess the experience of the onboarding
user because at least if they're using metrics that will, they know that they have a whole
fleet of, taking a nest tooling these days, hopefully to try to end up protecting them
et cetera. Whereas if you just pick a totally random geographically nearest server,
it was done by somebody who isn't particularly invested and isn't moderating it very well,
that could end up being that negative.
But I guess it's part of the work of the, this working group. I can't remember. I don't think
it's officially set up, but I should have listed it. Um, and how do you figure it out so that, yes,
you can get people to register in other servers in a nice way so that it's usable and not
carry for people who are coming from proprietary services.
Yeah, at least we need a better page like one that masters on them have of listing options
if servers have that as a first-class thing. Where, out of time. Okay. Thank you. We'll take
question in the, in a more if needed.