The Matrix State of the Union
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 287 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung 2.0 Belgien: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/56897 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
MatrizenrechnungSoftwareSpeicherabzugStandardabweichungOffene MengeMAPEchtzeitsystemTelekommunikationInternetworkingWald <Graphentheorie>ComputersicherheitMultiplikationsoperatorPunktProjektive EbeneSoundverarbeitungAggregatzustandDiagrammTechnische ZeichnungJSONXMLUML
00:59
Reelle ZahlChatten <Kommunikation>Offene MengeTelekommunikationMatrizenrechnungRechnernetzServerClientInklusion <Mathematik>Dienst <Informatik>Element <Gruppentheorie>FraktalgeometrieHumanoider RoboterClientKeller <Informatik>Bridge <Kommunikationstechnik>ServerKartesische KoordinatenImplementierungMultiplikationsoperatorProjektive EbeneMatrizenrechnungEindringerkennungIdentitätsverwaltungTelekommunikationAdressraumZahlenbereichUmwandlungsenthalpieDienst <Informatik>SpeicherabzugGenerator <Informatik>Umsetzung <Informatik>DiagrammDokumentenserverProtokoll <Datenverarbeitungssystem>FunktionalBetafunktionStandardabweichungEinfache GenauigkeitInternetworkingPunktOffene MengeApp <Programm>EchtzeitsystemVerschlingungInstantiierungProzess <Informatik>BenutzerbeteiligungMetrisches SystemMinimumInformationsspeicherungSnake <Bildverarbeitung>DefaultKonfiguration <Informatik>ZentralisatorSchreiben <Datenverarbeitung>MereologieVollständiger Verband
03:57
AdressraumBitRechter WinkelDienst <Informatik>Total <Mathematik>GruppenoperationInverser LimesMessage-PassingMatrizenrechnungSoundverarbeitungSystem FBridge <Kommunikationstechnik>BitrateSystemplattformClientNotepad-ComputerOrdnung <Mathematik>PunktGerichteter GraphSchlussregelMusterspracheZentrische StreckungWeg <Topologie>ZahlenbereichVerkehrsinformationSoftwareProtokoll <Datenverarbeitungssystem>BitBetafunktionServerIrrfahrtsproblemStatistikGraphMultigraphMehrrechnersystemsinc-FunktionDiagramm
06:12
SynchronisierungClientMatrizenrechnungServerBaum <Mathematik>VerzeichnisdienstZählenClientZahlenbereichSynchronisierungVerzeichnisdienstServerMultiplikationsoperatorMathematikQuick-SortGruppenoperationZählenBildschirmfensterZentrische StreckungDateiverwaltungMatrizenrechnungPhysikalisches SystemMinkowski-MetrikUmsetzung <Informatik>KonstanteSpielkonsoleNichtlinearer OperatorProfil <Aerodynamik>Digitale PhotographieSpezielle unitäre GruppeMailing-ListeFormation <Mathematik>ATMComputeranimation
07:34
GEDCOMSoftwareInformationSynchronisierungElement <Gruppentheorie>MultiplikationsoperatorVerzweigendes ProgrammMomentenproblemNichtlinearer OperatorProjektive EbeneUmsetzung <Informatik>MatrizenrechnungMailing-ListeImplementierungClientGleitendes MittelZweiGeradeInformationsmanagementProgramm/Quellcode
08:45
SynchronisierungClientSpeicherabzugServerTopologieMaßerweiterungProxy ServerSyntaktische AnalyseMatrizenrechnungGeometrische FrustrationEreignishorizontMereologieMessage-PassingNormalvektorBasis <Mathematik>ÄhnlichkeitsgeometrieNummernsystemMessage-PassingAggregatzustandClientImplementierungEndliche ModelltheorieMailing-ListeApp <Programm>VideokonferenzPunktRechter WinkelDienst <Informatik>Formation <Mathematik>MatrizenrechnungMathematikExzentrizitätGerichteter GraphCASE <Informatik>SpeicherabzugSchlüsselverwaltungElektronische UnterschriftEreignishorizontMaschinenschreibenZweiNormalvektorMultiplikationsoperatorFamilie <Mathematik>MereologieMaßerweiterungMinkowski-MetrikForcingVersionsverwaltungEinfügungsdämpfungServerProjektive EbeneArithmetische FolgeBasis <Mathematik>NummernsystemInternetworkingProxy ServerZählenSoftwaretestDifferenteSynchronisierungComputersimulationEinsFigurierte ZahlComputerarchitekturChiffrierungBitURLEindringerkennungVollständiger VerbandZahlenbereichComputeranimation
14:04
Architektur <Informatik>ClientElement <Gruppentheorie>Natürliche ZahlBenutzerfreundlichkeitSummengleichungChiffrierungMetrisches SystemHierarchische StrukturProtokoll <Datenverarbeitungssystem>Matrizenrechnung
14:40
ClientThreadElement <Gruppentheorie>BetafunktionRelation <Informatik>EreignishorizontVerschlingungClientThreadEreignishorizontÄußere Algebra eines ModulsRoutingRelativitätstheorieElement <Gruppentheorie>ZeitzoneVerkehrsinformationComputeranimation
15:04
Web logChiffrierungMessage-PassingMatrizenrechnungChiffrierungRechter WinkelPunktRuhmasseMessage-PassingMultiplikationsoperatorMetrisches SystemInformationEreignishorizontAutomatische HandlungsplanungDebuggingComputeranimation
15:27
EreignishorizontComputertomographStrukturierte ProgrammierungInformationInhalt <Mathematik>SoftwareentwicklerFontGemeinsamer SpeicherEreignishorizontMessage-PassingExogene VariableMultiplikationsoperatorDatenmodellURLWellenformInformationClientChiffrierungDatenstrukturRichtungComputeranimation
16:29
MatrizenrechnungElement <Gruppentheorie>Software Development KitClientImplementierungGebäude <Mathematik>ComputersicherheitStochastische AbhängigkeitMaximalfolgeTopologieFunktion <Mathematik>NormalvektorMaßerweiterungBandmatrixServerSynchronisierungMessage-PassingEin-AusgabeEreignishorizontBefehlsprozessorROM <Informatik>Stabilitätstheorie <Logik>RechnernetzFolge <Mathematik>RoutingVisualisierungSimulationKnotenmengeVideokonferenzSystemaufrufArchitektur <Informatik>Baum <Mathematik>Einfach zusammenhängender RaumOffene MengeSingle Sign-OnLoginService providerPhysikalisches SystemÄhnlichkeitsgeometrieAuthentifikationPasswortZufallszahlenChatten <Kommunikation>BrowserElektronisches ForumCodeWhiteboardSpieltheorieInformationsspeicherungGerade ZahlBenutzerfreundlichkeitWort <Informatik>Verhandlungs-InformationssystemDienst <Informatik>Generator <Informatik>ClientImplementierungGruppenoperationKlasse <Mathematik>Metrisches SystemCASE <Informatik>EchtzeitsystemMaßerweiterungDifferenteTopologieHorizontaleMobiles EndgerätMatrizenrechnungVerschiebungsoperatorServerBenutzerbeteiligungGebäude <Mathematik>Projektive EbeneWhiteboardStandardabweichungVideokonferenzElement <Gruppentheorie>Chatten <Kommunikation>ThreadTypentheorieVerzweigendes ProgrammStochastische AbhängigkeitAutorisierungChiffrierungTeilmengePasswortPunktElektronische PublikationApp <Programm>Minkowski-MetrikKollaboration <Informatik>ComputersimulationInternettelefonieLeistung <Physik>HalbleiterspeicherDienst <Informatik>Einfach zusammenhängender RaumMultiplikationsoperatorStrömungsrichtungNummernsystemStabilitätstheorie <Logik>ComputersicherheitArithmetische FolgePeer-to-Peer-NetzSoftwaretestHook <Programmierung>VisualisierungEndliche ModelltheorieTwitter <Softwareplattform>OrtsoperatorBridge <Kommunikationstechnik>MultihomingChatbotVersionsverwaltungFolge <Mathematik>ZentralisatorAlgorithmusRatsche <Physik>TextbausteinDatentypOpen SourceSchnelltasteWort <Informatik>CodeOffene MengeHumanoider RoboterStatistikFraktalgeometrieEin-AusgabeMessage-PassingBitBandmatrixPhysikalisches SystemRandomisierungLoginExogene VariableOffice-PaketRuhmasseInstantiierungGrenzschichtablösungDualitätssatzBildverstehenAutomatische HandlungsplanungFigurierte ZahlElektronisches ForumRoutingGesetz <Physik>SpieltheorieArithmetischer AusdruckBrowserSoftwareGoogolAbstimmung <Frequenz>Eigentliche AbbildungFitnessfunktionHilfesystemIntelligentes NetzDemoszene <Programmierung>COMProgrammierparadigmaAntwortfunktionUmsetzung <Informatik>InformationsspeicherungMatchingBeobachtungsstudieFunktionalProtokoll <Datenverarbeitungssystem>Primitive <Informatik>Fundamentalsatz der AlgebraAuswahlaxiomComputeranimation
24:07
AggregatzustandEreignishorizontEndliche ModelltheoriePeer-to-Peer-NetzMetrisches SystemMetadatenWechselsprungHorizontaleUmsetzung <Informatik>MatrizenrechnungServerTelekommunikationPhysikalisches SystemDienst <Informatik>BenutzerbeteiligungWorkstation <Musikinstrument>InformationstechnikForcingMultiplikationsoperatorComputeranimationBesprechung/Interview
25:57
ClientMathematikStandardabweichungElement <Gruppentheorie>SynchronisierungHumanoider RoboterSondierungBesprechung/Interview
26:27
Message-PassingComputersicherheitPhysikalische TheorieMatrizenrechnungInternetworkingBesprechung/Interview
26:51
AchtElement <Gruppentheorie>Projektive EbeneMatrizenrechnungKreisflächeOrdnung <Mathematik>Bus <Informatik>SkalarproduktPerfekte GruppeApp <Programm>Prozess <Informatik>SpeicherabzugSpielkonsoleMomentenproblemTwitter <Softwareplattform>AusnahmebehandlungAuswahlaxiomBesprechung/Interview
28:19
ImplementierungZweiGüte der AnpassungResultanteBesprechung/Interview
28:42
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:10
Hi there and welcome to the world's first ever Matrix Dev Room at Fosdum 2022. I'm Matthew Hodgson and I'm project lead for Matrix and co-founder of the project.
00:22
And I'm here to deliver the Matrix State of the Union, also known as What Is The Core Team Up To? This is intended to be like an overture before a musical in which we tease all the best themes of the talks which are going to happen over the next eight hours. And if there is a possibility that not everyone is going to watch all eight hours, it's attempting to basically summarize and have everything,
00:45
or at least a lot of the things the core team is doing in one simple 20 minute slot so that people can get up to speed on what's happening in Matrix. So without further ado, let's get going. We should probably explain what Matrix is first, which is a open network for secure decentralized real-time communication.
01:04
It's an open standard for chat, VoIP, VR, IoT, or really any place where you have real -time data that you want to securely synchronize around the internet without any single point of failure. So the whole idea is to effectively create the missing communication layer of the real-time web.
01:23
No single party owns your conversations. They get replicated equally between the servers participating in the conversations. And so you effectively have subversive decentralization. I cannot talk to somebody on another server without going and equally sharing ownership of my conversation with them. It's very like Git, where each Git repository is equivalent, except here we're doing it with communication rather than code and snippets.
01:48
So this is a diagram of Matrix. Here we have five Matrix home servers, each with a couple of Matrix clients hanging off them, talking HTTP and JSON over the client server API by default, and then talking HTTP and JSON between the servers as well.
02:06
We then can add in application services, which go and provide additional functionality to these Matrix servers, such as bridges to other protocols or perhaps bots. We also have identity servers, which are used optionally to look up people's Matrix IDs based on their phone numbers or their email addresses.
02:26
What we can then do is to expand this out further and link existing communication silos, whether it's Slack, Discord, WhatsApp, Gitter, IRCX, and PP, into Matrix via these bridges. And thus, Matrix effectively becomes the decentralized glue to link together the various communication silos of today.
02:43
The Matrix ecosystem itself hinges around a Matrix specification and spec.matrix.org, a whole pile of documentation describing the HTTP and JSON APIs that connect together clients at the top to servers at the bottom, and indeed servers and application services.
03:02
So we provide some reference stacks from the core team for JavaScript, iOS, and Android. We also now have Hydrogen as a lightweight JavaScript SDK, very distinct from the original Matrix JS SDK, and also Matrix Rust SDK as the next generation native SDK used, for instance, by the Fractal Next community project, and hopefully more of our own projects in future.
03:28
Then on the server side, we provide a Python implementation in Synapse and a Golang implementation called Dendrite. And Dendrite is increasingly close to exiting beta as our next generation approach,
03:42
and meanwhile Synapse is getting more and more mature as time goes on. Then we have application services, such as the bridges we've already mentioned, and then many, many community projects out there for server implementations, bridges, clients, etc. Looking at Matrix and Numbers, here are some graphs. This is the total known MXIDs ever over the last five years since we've started recording it.
04:07
We've got almost 50 million total MXIDs reported back by phone home stats from Synapses so far. About half of these are native to Matrix, and half of them are bridged in from other platforms. So it's about 25 million total Matrix native users.
04:25
An interesting new graph is monthly active users, which we started tracking about a year ago now via Synapse phone home stats. It's a bit of a random walk. You can see that it has been wobbling around over the last year a bit, doubling overall from 900k in Jan 2021 up to about 1.8 million as of now.
04:49
And it varies a bit as big servers come and go, and often we see a pattern where they turn off their reporting stats on us when they get beyond a given size. If you're running a big Matrix server, please keep the phone home stats turned on so that we can keep track of how well the protocol is doing.
05:07
It helps us get funding in as well as make us feel happier about our lives. And then we have total messages per day. This is over five years going from 1 million back in 2017 up to 10 million messages a day.
05:20
For context, this is small relative to say Discord. Discord is up at about a billion messages a day. WhatsApp, I think, has got 100 billion messages a day. So there is still a long way for us to go, but the graph is pointing upwards and to the right. And we think that as we improve things, there is a real chance of the kind of network effects and snowballing further.
05:42
The Matrix continuing to expand at an even faster rate than it has been so far. So what can we do to make Matrix improve faster? Originally, our goal with Matrix was for it to work at all. And we finally got there in 2020 when we exited Beta. And then we shifted to making it work right in order to get it to Beta, to be honest.
06:06
And then since then, we've been making it work fast. And that's what the emphasis is on right now. One of the main things we've been doing is implementing an entirely new Sync API, which controls how servers synchronize data to clients, called Sliding Sync, originally called v3 Sync.
06:26
And the current approach that we have scales really badly. It scales with the number of rooms that you're in. So a big account like my one with about three and a half thousand rooms can literally take five minutes to do an initial sync, even longer if you're doing an incremental sync.
06:41
Rooms should be cheap. They should be like directories in the file system. And you wouldn't be happy if your file system read access slowed down just because it had lots of directories. And likewise, you shouldn't expect Matrix to slow down just because you're in lots of rooms, particularly as we're using more and more rooms for more exotic things like spaces, groups of rooms, profiles, fees, reputation fees, all sorts of things.
07:04
You want to be able to hop in and out of them with gay abandon. So Sliding Sync changes how the Sync API works so that it only syncs data about the rooms which your client is currently showing. So it scales with constant time of your room count. And it does this by maintaining a sliding window over the visible rooms which you're showing in your client.
07:24
And as you scroll up and down, it tells the client where to insert or delete or refresh the items in the list. It's effectively doing server-side pagination, and it looks like this. So here is Hydrogen in Sync v3 mode, and here is my room list.
07:40
And as I scroll around, you can see it's pulling in new conversations on demand. And if you look at the console, you can see the operations like deleted happening here and other operations as it goes and updates the information about what is being deleted and what is being inserted into the list of rooms that I'm in.
08:01
The really exciting thing you get on this is if I hit refresh, like so, that is an entire initial sync, not even an incremental sync of my massive account. So that would have taken about five to 10 minutes on element. And if I go to my network tab and I look at the timing of that initial sync there, that took 190 milliseconds to generate.
08:26
So that is a 1,200 times speed up over where we've been historically. Really exciting times. We've got it implemented at the moment in Hydrogen on a branch to play with, but we're going to be rolling it out as rapidly as we can over as many other matrix clients as we can over the coming year.
08:45
So you can actually play with it today if you want, using the sliding sync implementation on the matrix.org GitHub project. And it works as a proxy that converts sliding sync into legacy V2 sync.
09:00
You can check out the Hydrogen support I was just demonstrating. The core API is now focused on synchronizing room data. So all the other bits like two device messages, end-to-end encryption, presence, read receipts, ephemeral messages, account date and whatever else are now split out into extension MSCs, which is a much better architecture than it all being muddled together like it was on V2.
09:22
But there is a caveat, which is that just for a change, end-to-end encryption is a real pain and the server has to send all of the end-to-end encrypted traffic to the client just in case that traffic includes notifications, because the server obviously can't figure out your notifications for you if it can't read your traffic. So that is a slight fly in the ointment of sliding sync, but for particularly large
09:45
accounts in lots of public rooms, it is a huge, huge improvement, as you can see. Another big thing we're working on is fast joins. And this is probably our second most complained performance problem in Matrix other than startup times,
10:01
which is that when you join a room over Federation from a fresh server, it takes forever. Like in Discord, you can join a so-called server with 100,000 users in a second or two. IRC, you can probably join a big channel in a few seconds as well. On Matrix, if I try to join a room at 10,000 users from a fresh server, even if it's the fastest server in the world, it's probably going to take 10 minutes.
10:23
And it's going to keep erroring out every 90 seconds due to HTTP timeouts. So the problem is that we currently synchronize all of our room states before letting the user participate in the room, which felt quite reasonable when we first created Matrix, because if the user can't see what's happening in the room, are they actually going to be able to participate sensibly?
10:42
But the problem is, with a room with 10,000 users, you could easily have 30 megabytes of JSON that needs to be parsed, authenticated by phoning home to the server who originally created it, checking their key, checking the signature on it, verifying if it can fit into the Matrix DAG, persisting it, all this stuff, and it really, really racks up.
11:03
So what if instead we only sync the minimal state that the client needs to participate? So that means the most recent users who were speaking, the ones you need to give the room a name if it doesn't already have a name, any bands or kicks, so you know whether you've been banned or kicked, the state that you would need to authenticate those events
11:20
as being correct, and perhaps a list of servers in the room so that if you speak, you know, you know where to send the messages. And then the joining server can go and synchronize the rest of the state lazily in the background, updating the historical snapshots of the state when it's done. And so this is MSC2775 called Lazy Loading Over Federation, and very early days in the implementation, but we are at last making progress on it.
11:45
And it's giving us roughly a 3x speed up. And here is a video that VDH and Dan provided earlier. And if I try to play this, then on the left hand side, we have a lazy join of a massive room of about 4,000 users.
12:02
And it took five seconds to get into that over federation using complement our home server test jig simulator. On the right hand side, on a normal join, we were still going, and that was 16 and three quarter seconds until we got UI. Now, this hasn't yet hooked up history to be lazy loaded, so it still takes a while for history to filter in.
12:23
But it's still a 3x improvement on being able to send messages and then 30 seconds in total to join for that particular use case. We can do way better. This is literally the first cut, but it's still pretty exciting. So continuing onwards. Another thing I wanted to talk about is matrix 1.2. So historically, matrix APIs were released separately.
12:47
So you had different releases for the client server API, the server server API, etc. And we very rarely released global updates. In fact, we only ever did it once for matrix 1.0. Now we've standardized instead on versioning endpoints per endpoint.
13:02
So each different HTTP API literal URL gets its own version number. And then instead, we release the whole spec as a monolith on a quarterly basis. So there is no more slash r0 prefixes in our URLs. It's now slash v3. And so matrix 1.1 we released in November last year, and we are releasing 1
13:23
.2 on February the 2nd, which hopefully will have happened by the time you hear this. And the big news on 1.2 is that we've merged in 18 matrix spec change proposals to turn them from being de facto experimental things to actually ratified as part of the formal spec. And the big news is spaces has finally landed as part of the official spec, even though it's been out in the world for months now.
13:46
Restricted joins, letting users join a room if they're a member of a given space or room. And also, the matrix URI scheme. Thanks, huge thanks to Kitsune for pushing through this epic to formally define a proper registered matrix URL prefix given our normal IDs and not exactly valid URLs.
14:05
Then lots and lots of work happening on improving client usability. A lot of this, this is our biggest existential risk for matrix, frankly. People use element or other matrix clients and get confused by what's going on.
14:21
And we've focused too much, frankly, on the protocol and the encryption and the decentralization. And we are desperately fixing that balance now, doing things like reworking the UI of element to shuffle things around so that they make some kind of hierarchical sense and trying to go through fixing all of the other UX witnesses we have.
14:41
Another big feature we're adding is threads using Discord or Slack-style threads. This uses aggregations or relations to link events back to their room route and falls back to replies for clients who don't know about them yet. It's a simpler alternative to the threads we had in Sierra Leone, although the two can coexist, and you can try it right now in element in labs.
15:03
It should be launching real soon now. Also lots of work around improving the encryption UI. So investigating situations where you can't decrypt your messages using better debug tooling, also providing better UI when it goes wrong, and actually having the tooling this time to fix.
15:20
And crosslining is due a massive UX overhaul. We are very aware that this is probably the weakest point of matrix right now, and we are really working on it. Then extensible events, really exciting stuff. So we've always had the idea of expressing arbitrary structured information in events whilst providing fallback for compatibility.
15:41
And this could be things like a temperature setting here where you get the plain text and the HTML fallback as well as the structural data. But finally, we're starting to use this. So we shipped voice messages this year, and you can see you have a fallback that just says voice message, and then you have things like the waveform to draw the pretty little voice message. We've got location sharing where the fallback gives you a textual G-O-U-R-I, but you also have the structured data to show you where you are.
16:08
We've got polls. Really nice because we have full fallback as well as end-to-end encryption support where people who don't know about polls and their client will see this message. Is Matthew going to run out of time for his talk?
16:21
At this rate, I am. And then the response is also done as a reference with a fallback so you can say this is the way as the answer. Next generation stuff. Lots of interesting stuff happening here. I'm going to go as quick as I can. And Matrix Rust SDK is one of the big things here. New first-class citizen client SDK.
16:41
We've been working on it for almost two years now. The end-to-end encryption implementation is factored out as a separate crate called Matrix SDK Crypto, which is really exciting because we can now embed it into existing clients like Element Android. So we've put Kotlin bindings around it and put it as a new encryption engine into Element Android, and we call it Element R as a code name.
17:03
This is an experimental approach, but it seems to be working. We're getting a 7X speed up in end-to-end encryption performance, and we'll ship it as soon as it's stable. Otherwise, we're also messing around with Matrix Rust SDK on iOS and web, and as I mentioned earlier, Fractal Next is making good progress on it too. Then we have the Dozomac.
17:20
This is in massive news with rewritten libom, our end-to-end encryption implementation, in Rust. So this is now the new reference OM and MEGOM E2E implementation as of today. It's actually pronounced for Dozomat or something like that, and it links natively into Matrix Rust SDK in the near future. You get much better primitives, much better memory safety and thread safety, and much better performance.
17:46
Again, I don't have stats on how much faster it is than the C implementation, but I would expect it to be 5, 6X over what we've seen historically. Currently, we are building out bindings to let folks easily swap out libom.
18:01
And we've just finished an independent security audit from Least Authority, which we'll be publishing as soon as we can, which will be an equivalent audit to the one that we did in OM when we launched it originally. Then we also have lots of work on DMLS. This is the decentralized version of messaging layer security, the IETF proposal for group end-to-end encryption.
18:24
And this has potential to replace OM and MEGOM with instead a tree of ratchets. It's very experimental at this point, but it provides algorithmic improvements over OM, and it could also help with our undecryptable session problems. But normal MLS needs a centralized sequencing function,
18:42
and DMLS is our extension that defines how you basically have each client manage its own MLS tree and then merge them together, much as matrix works between servers. Dendrite, I mentioned earlier, our next generation Go server, lots of exciting stuff here, despite distractions with peer-to-peer matrix, low bandwidth matrix, sliding sync, and much other stuff.
19:04
So the progress does come in bursts. Lots of progress in Dendrite 0.6 that we released last week. We've switched away from Kafka to NAT, merged together lots of the microservices because frankly there were too many and the boilerplate was just irritatingly time-consuming. We've refactored the room server a lot, and lots and lots of performance and stability fixes,
19:24
and we're up to 94% federation test coverage. So we're using Dendrite both for the peer-to-peer matrix and keeping the large-scale server deployments in scope, and it's looking really exciting. Talking of which, peer-to-peer matrix and Pinecone, lots of progress as well.
19:40
Pinecone sprouted SNAC, which is a new linear routing scheme which massively stabilizes our routing performance, and we're actually at the point at last of modeling adversarial attacks on Pinecone. The Pinecone simulator is turning into a full visualization engine, and it's incredibly cool. Go watch Neil Alexander's talk later to see all the details there.
20:02
The matrix side, however, is blocked on Dendrite, so we've gone back to focusing on Dendrite. Otherwise, we just need to hook up store-and-forward multi-home accounts and improve federation, and we should be in a position to really seriously start playing with peer-to-peer network matrix and bridging to it as well.
20:21
Finally, almost, Native Voice conference is another huge thing that landed this year. So we've now got Native Voice and video conferencing in matrix, and it extends the native one-to-one calling, giving decentralized encrypted group VoIP. And we basically took our one-to-one stuff, switched it to two device messages,
20:42
and defined a meta-protocol that would allow you to glue things together, either as full mesh, or using conferencing servers, or decentralized cascade of conferencing servers. It will be launching very shortly, and we'll be using it to power Discord-style voice video rooms in Element and Future. It also provides the VoIP backbone for third room, which is the metaversal matrix and project that Robert,
21:06
who also has been doing the VoIP conferencing, has been working on. Finally, OpenID Connect. Public service announcement. We are seriously considering moving matrix over to using OIDC for auth. The current system is really reinventing the OIDC wheel,
21:22
and we don't benefit from OIDC's security improvements as time goes on. It encourages you to type your password into random clients, which you might not trust, and it makes it increasingly hard to implement auth on new clients. It also doesn't allow you to delegate access to a client to a subset of your account.
21:42
So what we're looking at doing is to have your server provide an SSO login portal, very similar to what you might be used to with Google on accounts.google.com, where no matter what bit of Google you're playing with, you're always auth in the same place. Similarly, no matter what bit of matrix you're playing with, you would still auth with your server in all circumstances.
22:00
This, again, has been implemented as a branch on hydrogen. Watch this space. And then really finally, BeyondChat. We are finally starting to really look at building apps which go way beyond chat and VoIP on matrix. So this could be decentralized file storage, and there's a great talk from here about that later. It could be collaborative editing. It could be drawing documents or Figma-style drawing using native matrix CRDTs,
22:26
so not just journaling your CRDT updates over matrix, but actually expressing your conflict-free replicated data type on matrix itself. And then we're also looking at open metaverse solutions on matrix,
22:42
the third-room project, which Robert will talk about at the end of the day. So what if matrix stored both the data being collaborated on as well as the code? I mean, we're at a point where in future matrix really could become the real-time web, and your rooms could be anything from chat or voice, forums, message boards, collaborative documents,
23:01
whiteboards, Figma, metaverse games, anything. You can basically do multiplayer with your matrix client would effectively become a browser, and the rooms which you switch between would effectively be switching between these different real-time web experiences. And that is quite a paradigm shift.
23:21
So what's next? Basically doing everything I mentioned. Also account portability and decentralized reputation at last. Finishing get a parity, particularly importing historical conversations, which is looking really exciting. Huge bridging improvements on the horizon that half-shot will talk about later. Styled messages, pinned messages, and obviously custom emoji,
23:41
because I can't believe we've got this far without standard custom emoji across the board. So we need help. Don't use proprietary services for your chat. Please don't use Discord for your open source project. Run a server, use a matrix provider, build bots and bridges and clients. Don't reinvent the wheel if you're building a new thing. Follow us on Twitter or on Mastodon and spread the word.
24:02
Thank you very much.
24:20
The first one is one of metrics issue is that servers can theoretically collect and analyze metadata. What role will metadata play in the near-matrix future? I could. We don't have much time, so I'll jump in. Yeah, sorry. Go ahead. You know the metadata question.
24:41
So first of all, you can obviously limit your metadata footprint by going and running your own server. And on rooms which don't have other people in it, they're not going to ever see your metadata. So a really common misconception is that somehow matrix has visibility globally of metadata. It's just not true. It's only the servers which are participating in a given conversation will be able to see it.
25:04
That said, we obviously want to minimize that footprint too. And one of the things we've got is encrypted state events on the horizon. There is now an MSC encrypting things like the name of a room, the topic and other stuff which historically hasn't been encrypted.
25:20
And then for actual metadata, peer-to-peer just forces us to solve this problem properly. And there's a whole lot of interesting work there. Koje points out that peer-to-peer is still sci-fi and it might be a little way off. But frankly, metadata-resistant communication is pretty sci-fi. And so we need to solve both basically at the same time. There's definitely a model where the servers end up being more of a store-and-forward system similar to Signal,
25:46
who really don't have visibility like sealed sender and Signal on who is talking to who. And all of the metadata itself stacks up client-side peer-to-peer. Alright, thank you. Second question. When can we expect to see sliding sync in the standard element clients?
26:04
So you can play with it in hydrogen right now today. If you want to have it in element proper, we're basically going to make it work completely in hydrogen first, I think, before we then go and do the very disruptive changes needed to element to make it work. That said, I know that Adam on the element Android team has been experimenting with it.
26:22
So we might see it land first in element Android. Very exciting. You mentioned a security edit. Has it been published and if not, when should we expect the publication? So we got the initial update on it last week and it kind of goes through all of the things they found.
26:42
Some of them are legit, some of them less legit, and we basically need to talk it through with them and then get a final one, which will probably happen in the next week or two. Very exciting. So what about matrix or element being able to advertise to non technical audience through ads, posters, internet, etc?
27:08
Yeah, so this is kind of tangled up with the whole how is funding of the project looking and obviously doing mainstream advertising like Dot Dot Go has been doing recently with literal bus shelter for adverts in London costs an absolute bomb.
27:22
And in order to do that, well, we don't want to just like raise money from investors and then probably spend it on bus shelters. We'd rather instead make matrix itself better and more usable for a mainstream audience. And the way we do that on the core team effectively is to try to make element the best flagship app that we can.
27:40
Obviously, everyone else is very, very welcome to do a better job and do their own apps. The one that we're trying to guarantee is out there, even if everything else goes sideways is elements. And then as element gets more usable by normal people, then hopefully we can settle enough as elements and fund enough hosting via EMS and sell it to enough governments, etc.
28:04
That we can then take that cash and spend it on bus shelter adverts. And then you get a virtuous circle of matrix taking over the world. But the minor thing that is missing there is getting it simple and glossy enough that people can migrate over from WhatsApp easily to it. Perfect. Thank you.
28:21
So back to the audit really quickly, because we've got a few seconds left. What was audited? Was it just fake implementations? No, it was literally the implementation of the dozen apps, just like we did for Le Bon back in the day. And it was a pretty good result, honestly. Thank you.
28:41
Thanks, Brendan.