i18nde

Nicht so nett, wenn man sich für den Artikel interessiert und der hinter eine Bezahlschranke liegt.

https://www.zlb.de/standorte/amerika-gedenkbibliothek/

Ich würde ihm ein paar Tage lang extra einen weiteren Joghurt mitbringen und ihm diesen vor allen Kollegen geben, mit der Bemerkung, wenn er doch so gern Joghurt esse und sich keinen leisten könne, dann müsse man sich ja als Kollege solidarisch zeigen, und ob man ihm noch sonst irgendwie helfen könne ...

Kostet nicht viel, schafft aber Aufmerksamkeit.

Kann ich absolut so bestätigen. Ich war sehr lange Zeit in China in einer wirklich großen Stadt, mußte dann vor 5 Jahren nach Deutschland zurück. Aus Gründen der einfacheren Wohnungssuche nach Mecklenburg, in eine sehr kleine Stadt.

Vorteile:

• Die Wohnung sehr schnell gefunden, groß genug und bezahlbar.
• Kurze Wege zur Arbeitsstätte, zum Supermarkt, Bäcker, zum Arzt und Zahnarzt (leider nicht überall der Fall).
• Alle Ämter dicht beieinander, so daß ich die Anmeldung und weitere Behördengänge innerhalb kürzester Zeit erledigen konnte. Da jeder jeden kannte, wurde mir sehr schnell geholfen.
• Größere Städte in der Nähe, insofern recht schnell Arbeit gefunden.
• Tolle Landschaft, sauberes Wasser, Wälder, sogar etwas hüglig.
• Die Menschen aufgeschlossen und nett, interessiert.
• Es gibt sogar erstaunlich oft kulturelle Veranstaltungen in der Stadt und im Umland.

Nachteile:

• So richtig warm wurde ich fast nur mit Zugewanderten, der ursprüngliche Mecklenburger ist dann doch recht reserviert, wenn man nicht seit vielen Generationen dazugehört.
• Und die Verkehrslage des öffentlichen Nahverkehrs (ich mußte davor nie Auto fahren, kann es auch nicht), ab 18.00 Uhr ist es nicht so einfach, wieder nach Hause zu kommen.
• Auf lange Sicht die Leute dann doch viel zu neugierig, alles wird beobachtet und spricht sich dann herum, war mir schließlich zu persönlich.
• Die Wichtigkeit der Beziehungen -- Bürgermeister, Bäcker, Apotheker, Parteien, Kirche ... -- je nachdem, was man möchte, können diese Verknüpfungen einen blockieren, als Fremdem nutzen sie einem selten.

Bin jetzt endlich wieder in meiner Heimatstadt Berlin gelandet und blühe wieder auf, mußte feststellen, daß eine Kleinstadt so gar nicht meins ist. ... nur meine six pence.

And again, Big Action by the FBI against Z-Lib today. Tor still works.

Haut mich jetzt nicht vom Hocker. Unter Linux gibt es jede Menge andere kleine, feine Notiz-Programme. Das Update des Programms auf Version 2.1 zog mal glatt 37 MB (ist wohl ein App-Image) - unglaublich! Da ist QOwnNotes mit 4 MB viel schlanker und vielfältiger.

Mein Favorit ist Feather Notes – klein (1,4 MB installiert), fein (übersichtlich, auch auf Deutsch, ständig zur Hand, nutzt XHTML. Ich mag zwar MarkDown lieber, arbeite am liebsten mit Obsidian und Typora, aber als Notiz-App ist Feather Notes IMHO recht gut. Hierzu gibt es noch den Editor Feather Pad, den ich auch sehr gut als einfachen, schlichten Texteditor finde.

Weitere Apps in dem Bereich: GNote, ZIM, RedNoteBook, Cherry Tree, Turtl, das gibt es auch fürs Handy … oder auch WorkFlowy

Gute Idee, um mal einen Überblick zu bekommen, was es alles so im Fediversum gibt. ;-)

Verbote GEGEN … ? Deutsche Sprache, schwere Sprache.

Teil V

Die Arbeit an der P2P-Matrix macht ebenfalls gute Fortschritte - Sie können die einzelnen Updates auf https://arewep2pyet.com verfolgen. Nach langem Hin und Her zwischen Hard-State-Routing und Soft-State-Routing in Pinecone haben wir uns für Soft-State-Routing entschieden (das zwar geschwätziger ist, aber im Hinblick auf die Entschärfung von Angriffen einfacher zu erklären). Die Gesprächigkeit bedeutet jedoch, dass es sich nicht so gut skalieren lässt, wie man es sich erhofft - daher arbeiten wir jetzt an einem "abgestuften" Ansatz, bei dem separate Pinecone-Netzwerke zu einem Inter-Netzwerk zusammengeschaltet werden können, was uns Skalierbarkeit auf Kosten von etwas weniger Dezentralität bietet. Man kann mit Fug und Recht behaupten, dass die Reise hierher ziemlich frustrierend war, und leider hat sich Neil Alexander vor ein paar Monaten entschieden, weiterzuziehen. Devon ist jedoch in seine Fußstapfen als primärer Pinecone- und P2P-Kämpfer getreten und macht erstaunliche Fortschritte bei der verbleibenden Arbeit - als erstes implementiert er Store and Forward Relaying in Dendrite, so dass die heutigen Pinecone-Netzwerke Nachrichten austauschen können, selbst wenn der Empfängerknoten offline ist. Als Nächstes steht die Verbindung von P2P Matrix mit dem heutigen Matrix-Netzwerk an - und dann die Arbeit am Tiering, um die erforderliche Skalierbarkeit zu erreichen. Die Erwartung ist, dass die heutigen serverseitigen Dendrite-Instanzen effektiv zu statischen Pinecone-Peers werden, die Nachrichten im Namen von P2P-Knoten speichern und weiterleiten und Tiering zwischen den jeweiligen Pinecone-Subnetzen bereitstellen.

Hydrogen und Chatterbox

Die Entwicklung von Hydrogen, einem superleichten progressiven Web-App-Matrix-Client, ist im Laufe des Jahres ebenfalls vorangeschritten (mit einigen Abstechern zu End-to-End-Tests via Trafficlight, die sowohl Hydrogen als auch anderen Clients zugutekommen).

Die größte Veränderung war, dass Hydrogen einen separaten SDK-Layer entwickelt hat, mit dem die Engine in andere Webapps eingebettet werden kann, um nicht-invasive Matrix-Nachrichten mit einem möglichst minimalen Fußabdruck hinzuzufügen. Dies wurde im Juli mit dem Chatterbox-Angebot von Element vorgestellt, das eine Open-Source-Chatbox bereitstellt, die problemlos in bestehende Websites eingebettet werden kann, und auch das Chatrix-Wordpress-Plugin antreibt, an dem Automattic arbeitet.

Hydrogen fügte auch unabhängige Unterstützung für MSC3401 Mehrparteien-Sprach-/Videoanrufe hinzu (wenn auch auf einem Zweig), so dass wir heterogene Element Call <-> Hydrogen Gruppenanrufe präsentieren und beweisen konnten, dass MSC3401 als echte offene interoperable Anrufsignalisierung geeignet ist - und im Gegenzug treibt Hydrogen SDK, komplett mit den Mehrparteien-Sprach-/Videoanrufen, die Matrix-Engine innerhalb von Third Room an - unserer Metaverse-on-Matrix-Plattform.

Wir freuen uns darauf, dass Hydrogen im Laufe des nächsten Jahres die volle Funktionsgleichheit mit Element erreicht und an immer mehr unerwarteten Orten als jedermanns bevorzugter eingebetteter Matrix-Client auftaucht!

Dritter Raum

Schließlich ist es kaum zu glauben, dass Third Room, unsere Matrix-basierte offene Plattform für dezentrale räumliche Echtzeit-Zusammenarbeit, zu Beginn des Jahres kaum existierte. Third Room zeigt, dass Matrix weit mehr ist als nur Chat und VoIP, sondern auch die räumliche Kommunikationsebene des offenen Webs unterstützen kann. Dies hat dazu geführt, dass eine ganze Reihe neuer Funktionen für Matrix entwickelt wurden - wie z.B. native OIDC-Authentifizierung, skalierbares Mehrparteien-VoIP im Hydrogen SDK, effiziente Speicherung von Dateien im Binärformat und seit kurzem auch die Definition von erweiterbarem Verhalten für Matrix-Räume als WASM-Objekte, die im Matrix-Raum selbst gespeichert werden.

Third Room selbst ist ein Hydrogen-basierter Matrix-Client, der es ermöglicht, Matrix-Räume als interaktive Multiparty-3D-Umgebungen (unter Verwendung von MSC3815) zu betrachten - mit der Welt als glTF-Blobs, die im Matrix-Raum gespeichert sind, und der Möglichkeit, jeden Aspekt dieser Welt mit Hilfe von WASM-Blobs, die in Matrix-Räumen gespeichert sind, zu skripten und anzupassen, die auf den teilnehmenden Clients ausgeführt werden, wobei eine neue Scenegraph-API namens WebSceneGraph offengelegt wird, um das glTF zu manipulieren, aus dem die Welt besteht. Wir erwarten auch, dass eine Variante der normalen Widget-API von Matrix auf diese WASM-Blobs zugreifen kann, um das Konzept der sandboxed clientseitigen Widgets, Bots oder anderer Integrationen einzuführen, so dass die Benutzer Matrix anpassen und erweitern können, ohne jemals wieder serverseitige Bots ausführen zu müssen.

Ziel ist es, eine Plattform bereitzustellen, mit der jede Art von interaktiver, räumlicher Echtzeit-Multiparty-App auf offene, standardisierte, dezentralisierte und Ende-zu-Ende-verschlüsselte Weise erstellt werden kann - sei es für Spiele, soziale oder berufliche Aktivitäten wie die Erstellung "digitaler Zwillinge" für die Fertigung, Landwirtschaft, intelligente Städte, Such- und Rettungsdienste usw. Sie können mehr über die Vision unter thirdroom.io/preview lesen, oder über die Presseberichterstattung bei TheNewStack oder Golem. Wir haben uns auch unglaublich geschmeichelt gefühlt, als wir vor ein paar Wochen eingeladen wurden, Third Room auf der SIGGRAPH Asia zu präsentieren. Die offizielle Aufzeichnung ist noch nicht erschienen, aber Sie können hier ein freches Bootleg finden.

Ende September haben wir Tech Preview 1 von Third Room veröffentlicht. Seitdem dreht sich alles um die Entwicklung von WebSceneGraph und der WASM-Skripting-Umgebung, mit der Benutzer ihre eigenen Funktionen in JS über QuickJS oder C (und in Zukunft auch in Rust oder Zig) erstellen können. Wir haben auch daran gearbeitet, die Vernetzung (über Matrix WebRTC-vermittelte Datenkanäle) robuster zu machen und zu einem "autoritativen" Simulationsmodell zu wechseln, anstatt jeden Client seine eigene Physiksimulation laufen zu lassen, um das schwierige Problem dezentraler Physiksimulationen ein wenig zu entschärfen. Außerdem fügen wir eine dringend benötigte "Entdeckungs"-Seite hinzu, die den Nutzern hilft, neue Räume zu finden und alles zu erkunden, was auf der Plattform möglich ist. Und schließlich fügen wir WebXR-Unterstützung hinzu, damit die Leute ThirdRoom mit VR- und AR-Hardware nutzen können, wenn sie es wünschen. All dies sollte in der Tech Preview 2 kulminieren, die in den kommenden Wochen erscheinen wird.

Wenn Sie eine kurze Vorschau auf die Skripting-Fähigkeiten am Horizont mit einem sehr einfachen Skript, das im Media Repository gespeichert ist, erhalten möchten, besuchen Sie https://thirdroom.io/world/#surprise:thirdroom.dev und klicken Sie auf den Fernseher ;)

Fazit

Da haben Sie es: Es war ein durchwachsenes Jahr für Matrix, aber zumindest kommt das Projekt selbst schneller voran als je zuvor, vorerst. Wenn du dir die Vorhersagen aus dem letztjährigen Weihnachts-Blogpost ansiehst, wirst du sehen, dass die meisten von ihnen sogar eingetroffen sind. In diesem Jahr werden wir die Vorhersagen einfach halten: Unsere Pläne für 2023 bestehen darin, sicherzustellen, dass die Stiftung gut finanziert ist, alle schrittweisen Verbesserungen in Bezug auf Leistung und Benutzerfreundlichkeit, die sich derzeit in der Betaphase befinden, so schnell wie möglich auszuliefern - und ein für alle Mal zu beweisen, dass sich Matrix tatsächlich mit den proprietären zentralisierten Alternativen messen kann.

Danke für den Flug mit Matrix;

Matthew, Amandine und dem gesamten Kernteam.

(Ist länger geworden als erwartet, ich hoffe, trotzdem interessant.)

Teil IV

In der Zwischenzeit gibt es viele Fortschritte bei Waterfall - dem Namen, den wir für die Pion-basierte dezentrale Selective Forwarding Unit (d.h. Konferenzfokus) gewählt haben, die Sean DuBois Anfang des Jahres beigesteuert hat, einschließlich der Hinzufügung von Simulcast-Unterstützung zur Unterstützung großer Konferenzen.

Die Sache hat nur einen Haken: Element Call befindet sich immer noch in der (sehr späten) Beta-Phase, was auf eine Handvoll schwer zu findender Fehler zurückzuführen ist, die wiederum dazu geführt haben, dass alle anderen Abhängigkeiten (eingebettetes Element Call, Videoräume usw.) ebenfalls in der Beta-Phase sind. Wir sind jedoch der Meinung, dass wir jetzt so gut wie fertig sind - ein perfektes Timing, wenn man bedenkt, wie sich Waterfall zusammensetzt, was bedeutet, dass sowohl stabile als auch skalierbare native Matrix-Konferenzen am Horizont zu sehen sind!

Und was noch besser ist: Der Plan sieht vor, dass Element X vollständig auf die Einbettung von Element Call für VoIP setzt - wir sollten also in der Lage sein, ziemlich schnell zu hervorragenden nativen Mehrparteien-VoIP- und Videoräumen auf dem Handy und im Web zu kommen. Sobald Element Call die Beta-Phase verlässt, sollte alles andere folgen. Zur Abwechslung streben wir an, dies bis Ende Januar zu schaffen - aber es gibt noch viele Unbekannte, die im Umlauf sind, also bleiben Sie dran...

IETF UND MIMI

Eine weitere große neue Initiative in diesem Jahr war der Prozess, Matrix bei der IETF als Kandidat für die Standardisierung interoperabler Instant Messaging-Anwendungen vorzuschlagen. Die MIMI-Arbeitsgruppe (More Instant Messaging Interoperability) entstand Anfang des Jahres innerhalb der IETF als Initiative, um zu definieren, wie MLS für die Interoperabilität zwischen verschiedenen Instant-Messaging-Silos verwendet werden könnte - wie es demnächst im Digital Markets Act gefordert wird.

Eines der Ziele von MIMI ist die Definition eines gemeinsamen Protokolls für die Anwendungsschicht zum Austausch von Nachrichten. Zunächst wurde CPIM vorgeschlagen (ein uraltes Nachrichtenformat, das sehr nach E-Mail aussieht) - und dann wurde ein völlig neues JSON-Nachrichtenformat vorgeschlagen, das ein wenig nach Matrix aussieht (es aber nicht ist). An diesem Punkt wurde klar, dass wir unseren Hut in den Ring werfen und MIMI ermutigen sollten, Matrix zu verwenden, anstatt es neu zu erfinden, und so machten wir uns daran, Matrix zumindest als Nachrichtenformat und Nachrichtentransportschicht des Stacks vorzuschlagen. Es ist ziemlich unwirklich zu sehen, wie Matrix als IETF-Entwurf herumfliegt!

Der nächste Schritt besteht darin, die relevanten Teile der aktuellen Matrix-Spezifikation als eigenständige IETF-Entwürfe neu zu formulieren (anstatt die aktuelle Spezifikation aus den Entwürfen zurück zu referenzieren). Die Idee ist, dass die normale Matrix-Spezifikation sich weiter entwickelt, so wie sie es schon immer getan hat, aber wir spenden der IETF einen langfristig unterstützten Dialekt davon, der dann gemäß dem IETF-Prozess weiterentwickelt und als RFCs zur Verwendung in MIMI verewigt werden kann. Wir werden diese Änderungen dann in spec.matrix.org zurückportieren, um eine Fragmentierung zu vermeiden, während wir die gleiche Fähigkeit behalten, Matrix schnell zu iterieren und mit MSCs zu erweitern. Diese Arbeit ist bereits in vollem Gange (wobei wir die Gelegenheit nutzen, von Anfang an Extensible Events zu verwenden!), und wir sollten im Laufe des Jahres 2023 eine explosionsartige Zunahme weiterer IETF-Entwürfe erleben, die von Travis ausgehen.

Vertrauen und Sicherheit

2022 gab es einen echten Anstieg von Spam und Missbrauch in der gesamten Matrix, und es gab im Laufe des Jahres einige tapfere Versuche, unsere Moderationswerkzeuge zu verbessern. Leider ging es nicht so schnell, wie wir gehofft hatten, und wir mussten mit ansehen, wie mehrere große Gemeinschaften Matrix aufgaben und zu Discord zurückkehrten, auch weil sie bessere Mechanismen gegen Missbrauch benötigten.

Im Jahr 2023 werden wir unsere Arbeit im Bereich Vertrauen und Sicherheit neu ausrichten, wobei Mjolnir Dev zu seinem ursprünglichen Entwicklungsteam zurückkehren wird, und wir werden so taktisch wie möglich arbeiten, um sicherzustellen, dass alle Communitys auf Matrix Missbrauch mit den von ihnen benötigten Mechanismen einfach blockieren können.

P2P und Dendrite

In der Zwischenzeit wurde die Entwicklung von Dendrite (unserer Homeserver-Implementierung der zweiten Generation) im Laufe des Jahres weiter vorangetrieben. Laut Sytest sind wir jetzt bei 93% Client-Server-API-Konformität mit 577 von 620 Tests, und die Server-Server-API-Konformität liegt bei 97% mit 111 von 114 Tests! Keiner der fehlenden Tests ist ein Showstopper, so dass man mit Fug und Recht sagen kann, dass Dendrite schon fast bereit für die Primetime ist.

Interessant ist, dass sich die Entwicklung von Dendrite zunehmend auf eingebettete Matrixserver konzentriert - insbesondere für Peer-to-Peer-Matrix, bei der Clients einen eingebetteten Server benötigen. Während sich Synapse also zunehmend auf groß angelegte Implementierungen konzentriert hat, hat sich Dendrite auf kleinere Instanzen konzentriert (was ironisch ist, da es ursprünglich genau umgekehrt sein sollte).

Teil III

Drittens haben wir die Implementierung von Decentralised MLS als Verschlüsselungsprotokoll der nächsten Generation für Matrix vorangetrieben, um möglicherweise Olm und Megolm zu ersetzen. Diese Arbeit wurde durch die RHUL-Abschwächung stark beeinträchtigt, aber wir machen wieder gute Fortschritte - Sie können alle Details unter https://arewemlsyet.com verfolgen. Matrix über DMLS befindet sich derzeit in der Alphaphase, aber das Ziel ist es, 2023 mit dem Betatest von Decentralised MLS zu beginnen.

Schließlich haben wir hart daran gearbeitet, die gesamte UX zu überarbeiten, wie E2EE in Matrix-Clients funktionieren soll - insbesondere, indem wir von den Nutzern verlangen, dass sie ihre Geräte cross-signieren, um E2EE zu nutzen, und so in einer Welt mit viel mehr Vertrauen landen (neben Trust On First Use). Wir können es kaum erwarten, die E2EE UX endlich zu vereinfachen!

Alle neuen Funktionen

In diesem Jahr wurde nicht nur an der Leistung und Stabilität gearbeitet, sondern auch an einigen großen Bereichen der Funktionalität.

Eines der sichtbarsten Projekte war Threads, das im April in die Beta-Phase eintrat und in der Folgezeit stark überarbeitet wurde, um die Leistung, die Semantik der Benachrichtigungen, das Verhalten bei ungelesenen Nachrichten und die threadfähigen Lesebestätigungen zu verbessern. Das Endergebnis kann sich sehen lassen, und Threads verließ die Beta-Phase von Element Mobile am 20. Dezember. Web hat das Zeitfenster knapp verpasst, da ein letzter Fehler in der Benachrichtigung aufgetreten ist, der noch nicht behoben ist, aber kurz danach wird Threads die Beta-Phase verlassen!

Ein weiteres großes Projekt im Jahr 2022 war die Entwicklung eines universellen Rich-Text-Editors, der den Matrix-Kunden die Erstellung von WYSIWYG-Nachrichten (What You See Is What You Get) ermöglicht. Dies war ein sehr ehrgeiziges Projekt, bei dem die gesamte Kernsemantik für die Bearbeitung in einer gemeinsam genutzten Rust-Bibliothek definiert wurde, mit plattformspezifischen Bindungen, um sie mit der auf Web, iOS und Android verfügbaren Bearbeitungsoberfläche zu verbinden. Das Endergebnis ist unter https://github.com/matrix-org/matrix-rich-text-editor zu finden - und Sie können damit spielen, indem Sie es in den Labs auf Element Web/iOS/Android aktivieren oder mit der Live-Demo experimentieren. Das Kernverhalten fühlt sich ausgezeichnet an, auch wenn einige der feinen Details vorhersehbar sehr knifflig zu erreichen sind. Es ist jedoch fast fertig, und dank des eingebauten Generators für Rust-Tests (!) sind wir zuversichtlich, dass wir alle Randfälle abfangen und kontrollieren werden, und dies sollte eine unglaublich starke Plattform für alle zukünftigen Rich-Text-Bearbeitungsanforderungen in Matrix (und darüber hinaus!) bilden. Diese Arbeit wurde freundlicherweise von einem der Kunden aus dem öffentlichen Sektor gesponsert, um Element auf Augenhöhe mit Teams zu bringen - vielen Dank dafür!

Die Standortfreigabe war eine weitere Funktion, die 2022 eingeführt wurde - angetrieben von MSC3488 und MSC3489 und implementiert in matrix-{js,ios,android}-sdk in Element Web/iOS/Android, so dass Benutzer statische und Live-Standorte freigeben und auf einem OpenStreetMap-kompatiblen Tileserver ihrer Wahl anzeigen können. Die Live-Standortfreigabe ist insofern umstritten, als sie Standortdaten in der Raumhistorie speichert (und als solche hinter einem Labs-Flag auf Element versteckt ist), sollte aber schließlich durch MSC3672 ersetzt werden, um Standorte stattdessen über benutzerdefinierte ephemere Ereignisse freizugeben (sobald benutzerdefinierte EDUs landen) in der Spezifikation. Etwa zur gleichen Zeit wurden auch Umfragen dank MSC3381 eingeführt - es ist erwähnenswert, dass sowohl die Standortfreigabe als auch die Umfragen hervorragende Beispiele für "erweiterbare Ereignisse" in der freien Wildbahn sind: Sie stellen sicher, dass Clients, die den benutzerdefinierten Ereignistyp verstehen, sie entsprechend darstellen, lassen aber andere Clients darauf zurückgreifen, sie als einfache Zeitleistenereignisse anzuzeigen.

Open ID Connect

Die Umstellung auf die Verwendung von Open ID Connect für die Matrix-Authentifizierung ist im Laufe des Jahres 2022 stetig vorangeschritten - mit Third Room als erstem OIDC-nativen Matrix-Client, dicht gefolgt von Element X. matrix-authentication-service existiert nun als grundlegender OIDC-Identitätsprovider, der sich für die Verknüpfung mit Synapse eignet, und inzwischen demonstriert Third Room, wie man Keycloak als Drittanbieter-IDP integrieren kann (komplett mit reCAPTCHA und Gastzugang!). Das Team machte auch einen sehr spannenden Abstecher, um herauszufinden, wie man Login und E2EE-Einrichtung in einem einzigen Vorgang durch Scannen eines QR-Codes (MSC3906) durchführen kann, und wie dies in Zukunft in OIDC integriert werden könnte.

Element X dürfte in Zukunft das Vorzeigeprojekt für natives OIDC in einem typischen Matrix-Client sein. Warten Sie also ab, wie es sich anfühlt!

Sie können den unaufhaltsamen Übergang zu OIDC unter https://areweoidcyet.com verfolgen.

VoIP

2022 war das Jahr, in dem Matrix endlich natives Mehrparteien-VoIP erhielt. Nach dem Start von Element Call Beta 1 im März, gefolgt von Beta 2 im Juni, waren wir damit beschäftigt, Element Call als "Matrjoschka"-Widget in Element Web einzubetten und es als Ersatz für Jitsi zum Betreiben von Videoräumen und Videoanrufen zu verwenden. Sie können alles darüber im Detail in unserem Sommer-Blogbeitrag lesen.

Teil II

Turbolader für Matrix

Abgesehen von den Albträumen bei der Finanzierung von Open-Source-Software war das Jahr 2022 vor allem ein Jahr des Aufbaus - mit dem Schwerpunkt, die Leistung und Benutzerfreundlichkeit von Matrix weiter zu verbessern und sicherzustellen, dass sich das Protokoll mit zentralisierten proprietären Alternativen messen kann (und mehr!). Schließlich müssen die Matrix-Clients mindestens so gut sein wie die zentralisierten Alternativen, um eine breite Akzeptanz zu finden.

Diese Arbeit hat viele Formen angenommen: Auf der Serverseite hat Synapse Rust-Unterstützung entwickelt, um seine heißen Pfade zu beschleunigen, angefangen bei der Auswertung von Push-Regeln. Es ist sehr aufregend zu sehen, wie die Leistung von Synapse in eine neue Ära eintritt, aufbauend auf dem Fundament einer mittlerweile sehr ausgereiften und stabilen Homeserver-Implementierung.

In der Zwischenzeit ist die Arbeit an "Faster Joins" in den letzten Zügen, die es Servern endlich ermöglicht, Räumen über Federation schnell beizutreten, indem sie nur die minimale Teilmenge des Zustands synchronisieren, die für den Beitritt benötigt wird, anstatt proaktiv den gesamten aktuellen Zustand des Raums zu synchronisieren. Schnellere Joins sind seit Oktober in Synapse zum Testen verfügbar, und seither hat das Team daran gearbeitet, Worker zu unterstützen und die verschiedenen Randfälle und Fehler zu beheben, die während der Tests aufgetaucht sind. Die derzeitige Join-Performance liegt bei etwa 25-facher Beschleunigung in großen Räumen, aber wir sind zuversichtlich, dass wir dies noch weiter verbessern können, und wir streben an, dies rechtzeitig zur FOSDEM Anfang Februar zu erreichen.

Auf der Client-Seite konzentrierte sich die Arbeit zur Verbesserung der Leistung des Matrix-Clients auf "Sliding Sync" - unsere völlig neue API für die Synchronisierung der minimalen Daten mit einem Client, die für das Rendern der Benutzeroberfläche erforderlich sind, so dass Anmeldung, Start und Synchronisierung sofort erfolgen können. Sliding Sync (ursprünglich "sync v3" genannt) hat lange auf sich warten lassen; die API hat unzählige Iterationen durchlaufen, während wir das ganze Jahr 2022 hindurch daran gearbeitet haben, sie in realen Clients zu implementieren und alle Erweiterungen (MSC3884, MSC3885) hinzuzufügen, die nötig waren, um mit sync v2 gleichzuziehen. Das Warten hat sich jedoch gelohnt: Die Unterstützung in Element Web befindet sich in der Endphase der Entwicklung - und darüber hinaus werden die mobilen Clients der nächsten Generation von Element X nur Sliding Sync sprechen.

Element X selbst entwickelt sich zu einem Vorzeigeprojekt dafür, wie schnell und performant Matrix sein kann: Es basiert auf matrix-rust-sdk und nutzt die native Swift UI auf iOS/macOS und Jetpack Compose auf Android, um die bestmögliche plattformspezifische Benutzererfahrung mit der ultimativen SDK-Implementierung in nativem Code zu verbinden, die durch Sliding Sync unterstützt wird. Das Ziel ist es, mindestens so schnell wie Telegram, iMessage oder WhatsApp zu sein (wir haben die Frames in Bildschirmaufnahmen gezählt, um Dinge wie die Zeit bis zum Start und die Zeit bis zum Zurückblättern zu vergleichen). Element X befindet sich derzeit in der späten Alpha-Phase für iOS und soll rechtzeitig zur FOSDEM in die öffentliche Beta-Phase gehen. Hier können Sie einen ersten Blick auf das iPad-ähnliche Layout werfen (unter macOS)!

Element X

Was schließlich die Benutzerfreundlichkeit betrifft, so hat sich bei Matrix einiges getan - vor allem die mobile Benutzeroberfläche von Element wurde im September vom Designteam komplett überarbeitet, um das endgültige Design von Element X vorzubereiten. Alle verbleibenden UX-Macken sollten mit Element X beseitigt werden, aber die Optik ist schon jetzt ein klarer Schritt in Richtung einer hervorragenden Alternative zu den zentralisierten Anbietern.

Verschlüsselung

Wir hatten große Pläne für E2EE in Matrix in diesem Jahr; zunächst wurde vodozemac in großer Eile fertiggestellt und als unsere glänzende neue Native-Rust-Implementierung von Olm/Megolm auditiert. Der Plan war dann, vodozemac in die Krypto-Kiste von matrix-rust-sdk zu integrieren und dann die verschiedenen alten, fragmentierten E2EE-Implementierungen in matrix-js-sdk, matrix-ios-sdk, matrix-android-sdk2 und matrix-rust-sdk selbst durch eine echte, geprüfte Implementierung zu ersetzen - mit Audits, die bei Least Authority gebucht wurden, um weitere Sicherheit für matrix-rust-sdk-crypto, matrix-rust-sdk selbst und schließlich den gesamten Stack (Element X + Synapse) zu erhalten.

Leider gerieten die Dinge aus den Fugen, als sich Sicherheitsforscher der Royal Holloway University London und anderer Institute meldeten und erklärten, dass sie in der ehrwürdigen matrix-js-sdk-Implementierung einige unangenehme Schwachstellen gefunden hätten. So blieb uns nichts anderes übrig, als "Element R" - das Projekt zur Konvergenz von matrix-{js,ios,android}-sdk auf matrix-rust-sdk-crypto - zu pausieren und stattdessen mit der Analyse und Behebung der Probleme in allen derzeit ausgelieferten Matrix-Clients zu beginnen, um sie so schnell wie möglich zu beheben. Ironischerweise stellte sich am Ende heraus, dass nur matrix-{js,ios,android}-sdk betroffen war - alle anderen unabhängigen Implementierungen, einschließlich matrix-rust-sdk, waren in Ordnung. Die Arbeit an Element R hätte uns also vor diesen Schwachstellen geschützt, wenn sie schon fertig gewesen wäre, und hätte es uns ermöglicht, sie an einer einzigen Stelle zu lösen. Stattdessen wurde die Arbeit an Element R um Monate verschoben, während wir die verschiedenen Probleme in den Legacy-SDKs in dreifacher Ausführung bearbeiteten und gleichzeitig alle anderen Client-Implementierungen überprüften, die wir finden konnten, und uns mit zusätzlichen Problemen befassten, die die RHUL-Forscher entdeckten, als sie tiefer bohrten. Schließlich beendeten wir die Analyse und vereinbarten eine koordinierte Offenlegung Ende September. (EDIT: Um das klarzustellen: Wir sind den Sicherheitsforschern sehr dankbar dafür, dass sie die Schwachstellen entdeckt und uns gegenüber verantwortungsbewusst offengelegt haben. Die Frustration rührt von der Ironie her, dass wir die schwerwiegenden Sicherheitslücken entschärft hätten, wenn wir die Überarbeitung von matrix-rust-sdk-crypto einige Monate früher abgeschlossen hätten - stattdessen wurde die Überarbeitung noch weiter nach hinten verschoben. Das ist aber natürlich unsere Schuld, nicht die der Forscher).

Seitdem wurde die Arbeit auf drei Arten aufgeteilt: Erstens wurde die Arbeit an Element R wieder aufgenommen - und tatsächlich ist Element R auf iOS seit heute so gut wie einsatzbereit, abgesehen von einigen Arbeiten zur Unterstützung von E2EE-Push-Benachrichtigungen (die auch für Element X benötigt werden). Element R auf Android ist ebenfalls sehr nah dran, und inzwischen hat Element R auf Web sein erstes Ereignis am 19. Dezember entschlüsselt! Wir hoffen, dass wir Element R bis Februar auf allen Plattformen in Produktion bringen können.

Zweitens haben wir uns mit anderen Punkten befasst, die von den RHUL-Forschern angesprochen wurden, um sicherzustellen, dass böswillige Server keine böswilligen Geräte oder Benutzer zu Konversationen hinzufügen können, anstatt wie bisher zu warnen. Dies ist kein triviales Problem, aber wir machen Fortschritte durch MSC3917 (Cryptographically Constrained Room Membership) und MSC3834 (Opportunistic user key pinning (TOFU)). Diese Arbeit wird jedoch zunächst durch die Landung von Element R blockiert, da es keine Möglichkeit gibt, dieses Problem in dreifacher Ausführung mit den alten SDKs zu lösen.