this post was submitted on 31 Dec 2022
5 points (72.7% liked)

Matrix

3288 readers
2 users here now

An open network for secure, decentralized communication

founded 4 years ago
MODERATORS
k_o_t@lemmy.ml
5
Das Jahr 2022 war für Matrix ein wahres Wechselbad der Gefühle (matrix.org)
submitted 2 years ago* (last edited 2 years ago) by i18nde@feddit.de to c/matrix@lemmy.ml
1 comments fedilink hide all child comments
 

Ich habe mir mal gestattet, den Text ins Deutsche zu übersetzen:

Teil I

Hallo zusammen,

das Jahr 2022 war für Matrix ein wahres Wechselbad der Gefühle.

Einerseits hat sich die Größe des Netzwerks verdoppelt (44,1 Millionen auf 80,3 Millionen sichtbare Matrix-IDs). Dank der Situation bei Twitter erlebt die Welt ein großes Erwachen in Bezug auf die Bedeutung der Dezentralisierung. Wir haben eine erstaunliche Anzahl von neuen Akteuren gesehen, die dem Matrix-Ökosystem beigetreten sind: Reddit scheint neue Chat-Funktionen unter Verwendung von Matrix zu entwickeln; TeamSpeak kündigte einen Matrix-basierten Chat in TS5 an; Discourse arbeitet daran, Matrix-Unterstützung hinzuzufügen; Thunderbird hat Matrix-Unterstützung eingeführt; Regierungen von Luxemburg bis zur Ukraine haben ihre eigene Matrix-basierte Chat-Infrastruktur eingeführt; und Hunderte von anderen Organisationen, von Start-ups bis zu großen privaten und öffentlichen Einrichtungen, setzen auf das Protokoll. Das Europäische Parlament hat Matrix als Beweis für die Realisierbarkeit der Interoperabilität der Kommunikation zwischen Gatekeepern im Gesetz über digitale Märkte verwendet. Die FOSDEM 2022 wurde mit über 23 000 Teilnehmern reibungslos über Matrix abgewickelt und war damit die größte Open-Source-Konferenz der Welt (wobei 70 % der Teilnehmer ihre eigenen Server verwendeten!). Schweden hat Fallstudien über die Vorteile von Matrix für die Interoperabilität des Nachrichtenverkehrs veröffentlicht. In der Zwischenzeit haben bestehende Akteure wie die BWI in Deutschland ihren Anwendungsbereich erweitert und bieten nun Matrix-Messaging für den gesamten deutschen Staat an; Automattic ist mit der Entwicklung von Matrix-Plugins für Wordpress beschäftigt; Rocket.Chat hat die Föderation über Matrix eingeführt, Gematik hat seine TI Messenger-Initiative für interoperables Messaging im deutschen Gesundheitswesen vorangetrieben und Tchap in Frankreich expandiert weiter.

Andererseits haben nur eine Handvoll dieser Initiativen dazu geführt, dass das Matrix-Kernteam Mittel erhalten hat. Dies gefährdet unmittelbar die Kernentwicklung von Matrix. Wir sind Zeugen einer klassischen Tragödie der Allmende. Wir haben den gesamten grundlegenden Code von Matrix als freizügig lizenzierten Open-Source-Code veröffentlicht und ihn so weit entwickelt, dass jeder ihn selbst erfolgreich in großem Maßstab einsetzen kann. Das Netzwerk expandiert exponentiell. Im Gegenzug zeigt sich jedoch, dass die große Mehrheit dieser kommerziellen Implementierungen keinen finanziellen Beitrag zur Matrix Foundation leistet - sei es durch direkte Spenden oder indirekte Unterstützung durch die Zusammenarbeit mit Element, die heute den größten Teil der Kernentwicklung von Matrix finanzieren.

Kurz gesagt: Die Leute lieben die fantastische dezentralisierte, verschlüsselte Kommunikationsutopie von Matrix. Aber Organisationen lieben es auch, dass sie es nutzen können, ohne jemanden für die Entwicklung oder Wartung bezahlen zu müssen. Das ist völlig untragbar, und Element ist jetzt buchstäblich nicht mehr in der Lage, die gesamte Matrix Foundation für alle anderen zu finanzieren - und musste deshalb einige Mitarbeiter des Kernteams entlassen.

Die einzige praktikable Lösung besteht darin, dass Organisationen, die auf Matrix aufbauen, sich an den Kosten für die Aufrechterhaltung der Kernprojekte von Matrix beteiligen. Wir haben vor ein paar Wochen einen Vorschlag zur Lösung dieses Problems gemacht, den wir im neuen Jahr weiter ausarbeiten werden, um einen Ansatz zu finden, der sowohl die Gemeinschaft stärkt als auch Organisationen zur Teilnahme ermutigt. Wenn Sie in der Zwischenzeit eine Organisation sind, die auf Matrix aufbaut, und wollen, dass das Projekt weiter gedeiht, schreiben Sie bitte eine E-Mail an funding@matrix.org, um zu besprechen, wie Sie die Grundlagen, auf die Sie angewiesen sind, unterstützen können.

Zur Erinnerung: Die Arbeit, die die Stiftung heute zum Nutzen der Matrix leistet, umfasst

  • die Veröffentlichung der Matrix-Spezifikation
  • Organisation des Matrix Spec Core Teams, das für die Überprüfung und Weiterentwicklung des Protokolls verantwortlich ist.
  • Schreiben von etwa der Hälfte der Matrix Spec Change Vorschläge.
  • Entwicklung von Synapse, der Python-Implementierung des Matrix-Homeservers
  • Entwicklung von Dendrite, der Go-Homeserver-Implementierung
  • Entwicklung von Client-SDKs für Web (matrix-js-sdk, matrix-react-sdk), iOS (matrix-ios-sdk), Android (matrix-android-sdk2) und Python (matrix-nio)
  • Entwicklung unserer Client-SDKs der nächsten Generation (matrix-rust-sdk)
  • Entwicklung unserer End-to-End-Verschlüsselungsimplementierungen (libolm in C/C++ und vodozemac in Rust)
  • Entwicklung von Ende-zu-Ende-Verschlüsselungsimplementierungen der nächsten Generation (MLS)
  • Entwicklung und Weiterentwicklung zusätzlicher Kernfunktionalitäten in Matrix, darunter:
    • Übertragbarkeit von Konten
    • Schnelleres Verbinden von Räumen über Föderation
    • Sliding Sync für sofortige Client-Synchronisation
    • Threads
    • Rich Text Composer-Komponenten
    • Räume
  • Entwicklung von Open-Source-Integrationen in andere Produkte (GitLab, GitHub, JIRA...)
  • Entwicklung von Open-Source-Brücken zu anderen Plattformen (IRC, XMPP, Slack, Discord, Telegram, bifrost...)
  • Entwicklung von Peer-to-Peer-Matrix-Implementierungen, die den Bedarf an Servern (und die damit verbundene Anhäufung von Daten/Metadaten) vollständig ausschließen
  • Entwicklung von Matrix-Transporten mit geringer Bandbreite
  • Entwicklung und Hosting von statischen Matrix-Raumarchiven für das gesamte Netz (matrix-static und matrix-public-archive)
  • Entwicklung und Hosting des matrix.to Link Redirect Service
  • Entwicklung von Open-Source-Authentifizierungsmechanismen und Integrationen für Matrix (OIDC)
  • Entwicklung von dezentralen Video/VoIP-Konferenzservern auf Matrix (Wasserfall)
  • Entwicklung dezentraler Video/VoIP-Client-Komponenten für Matrix (matrixRTC)
  • Entwicklung von Vorzeige-Implementierungen von Matrix "jenseits des Chats" wie Third Room
  • Entwicklung von Moderationswerkzeugen und deren Anwendung auf matrix.org (mjolnir und vieles mehr)
  • Veröffentlichung von Reputationslisten für die Moderation zum Nutzen der gesamten Gemeinschaft
  • Entwicklung von Integrationstestsuiten für Matrix-Kompatibilitätstests (sytest, complement, trafficlight)
  • Entwicklung eines Referenz-Push-Benachrichtigungsservers (sygnal)
  • Entwicklung eines Referenzservers für Identitätsverzeichnisse (sydent)
  • Beschaffung und Veröffentlichung unabhängiger öffentlicher Audits der Verschlüsselung und des weiteren Stacks von Matrix
  • Veröffentlichung der Website matrix.org und des Blogs
  • Veröffentlichung des wöchentlichen "Matrix Live"-Video-Podcasts
  • Veröffentlichung des wöchentlichen Newsletters "This Week In Matrix".
  • Organisation regelmäßiger Treffen (z. B. "Open Tech Will Save Us")
  • Förderung von Matrix auf Open-Source-Konferenzen
  • Betrieb des Homeservers von matrix.org
  • Moderation der Projekträume von matrix.org
  • Betrieb von kostenlosen öffentlichen Brücken zu Netzwerken wie IRC-Netzwerken und XMPP.

Diese Liste ist nicht im Entferntesten vollständig (wie sich herausstellt, gibt es über 240 Projekte in der matrix.org GitHub org!), aber sie dient dazu, das schiere Ausmaß der Arbeit zu veranschaulichen, die die Stiftung heute leistet. Für den langfristigen Erfolg von Matrix ist es von entscheidender Bedeutung, dass das Kernteam weiterhin finanziert wird, um an Matrix zu arbeiten. Wir hoffen daher sehr, dass Organisationen, die auf Matrix angewiesen sind (oder Philanthropen, die den Wert von Matrix zu schätzen wissen), eine Nachricht an funding@matrix.org senden und uns dabei helfen, den Betrieb aufrechtzuerhalten.

top 1 comments
sorted by: hot top controversial new old
[–] i18nde@feddit.de 1 points 2 years ago* (last edited 2 years ago)

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.