Conduit: Ein einfacher und schneller selbstgehosteter Chat-Server auf Matrix-Basis

 (conduit.rs)
3 Punkte von GN⁺ 2023-08-01 | 1 Kommentare | Auf WhatsApp teilen
  • Conduit ist ein leichtgewichtiger Open-Source-Server, der die Matrix-Spezifikation implementiert und darauf ausgerichtet ist, in wenigen Minuten einen eigenen Homeserver einzurichten
  • Das Projekt befindet sich noch in der Beta; es ist bereits nutzbar, einige kleinere Funktionen fehlen jedoch noch
  • Matrix ist ein offenes Netzwerk für sichere und dezentrale Kommunikation, in dem Benutzer verschiedener Homeserver miteinander chatten können
  • Für den Betrieb setzt es auf eine einzelne Binärdatei und eine integrierte Datenbankstruktur; als Standarddatenbank wird RocksDB verwendet
  • Es versteht sich als leichtere und einfacher zu installierende Alternative zu Synapse und ist daher einen Blick wert, wenn ein selbstgehosteter Chat-Server mit geringen Systemanforderungen benötigt wird

Die Rolle von Conduit und Matrix

  • Conduit ist ein leichtgewichtiger Open-Source-Server, der die Matrix Specification implementiert
  • Der aktuelle Status ist Beta
    • Es kann bereits verwendet werden
    • Einige kleinere Funktionen fehlen noch
  • Matrix ist ein offenes Netzwerk für sichere und dezentrale Kommunikation
    • Alle Benutzer eines Matrix-Homeservers können mit Benutzern anderer Matrix-Server chatten
    • Mit Bridges ist auch die Kommunikation mit Nutzern außerhalb von Matrix möglich, etwa in Discord-Communitys

Eigenschaften bei Installation und Betrieb

  • Ziel sind eine einfache Einrichtung und geringe Systemanforderungen, sodass sich in wenigen Minuten eine eigene Conduit-Instanz aufsetzen lässt
  • Der Server verwendet eine einzelne Binärdatei und eine integrierte Datenbankstruktur
  • Die Standarddatenbank ist RocksDB
  • In manchen Fällen kann es schneller sein als andere Server-Implementierungen

Relevante Links und Unterstützung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-01
Meinungen auf Hacker News

  • Ich betreibe seit einigen Jahren eine selbst gehostete Conduit-Instanz. Der Vorteil ist, dass Installation und Nutzung einfach sind; der Nachteil ist, dass es noch Beta-Software ist.
    Trotzdem war es für mich ziemlich gut, und ich habe es sowohl für stabile Chats mit ein paar Freunden als auch in einigen etwas größeren Räumen, an denen ich teilnehme, gut nutzen können.
    Der Autor arbeitet auch an einem weiteren interessanten Rust-Projekt, Veloren: https://veloren.net

    • Veloren ist ein wirklich tolles Spiel. Vor ein paar Jahren habe ich es zum Spaß mit Freunden kompiliert, und selbst auf meiner GTX 1050 Ti lief es überraschend flüssig.
      Ich ging in die Lobby und spielte etwa 30 Minuten, bis ich merkte, dass man mit dem Scrollrad immer weiter von der Figur herauszoomen kann. Das ging über das übliche Action-RPG-Niveau hinaus, bis hin zu einer Minimap-Skalierung und über die Wolken, ohne Frame-Einbrüche – das fühlte sich ziemlich psychedelisch an.
      Ich weiß nicht, wie gut das Projekt derzeit gepflegt wird, aber es scheint genug Substanz zu haben, um ein starkes RPG zu werden.
    • Ich nutze Conduit schon ziemlich lange und halte sehr viel davon.
      Lange Zeit fehlte die Spaces-Unterstützung, aber sie ist gerade in den Development-Builds gelandet und ist hervorragend. Ich habe meinen Dienst bereits aktualisiert, und es funktioniert wie erwartet gut.
    • Wirkt wie eine gute Alternative zum Betrieb des Go-Servers Dendrite. Dendrite fühlt sich an, als sei es ewig in Entwicklung, und der Python-Server frisst inzwischen zu viele Ressourcen, daher ist es erfreulich, neben dem Go-Server weitere Alternativen zu sehen.
    • Es wäre schön, wenn es einen ähnlichen Client gäbe, der den Funktionsumfang vollständig unterstützt. Das Problem bei Matrix ist, dass es so viele Funktionen hat, dass es wirkt, als seien Signal, Discord, Slack, Zoom und Teams miteinander vermischt.
      Ein Unterprotokoll nur für sichere Chats wäre wünschenswert.
    • Ich betreibe es seit 10 Monaten, und sowohl Installation als auch Nutzung waren sehr reibungslos.
      Ich bin der einzige Nutzer auf meinem Server und bin keinen sehr aktiven Räumen beigetreten, aber bislang ist die Auswirkung auf die Leistung eines kleinen VPS vernachlässigbar.

  • Hallo, ich bin Timo, der vor ein paar Jahren das Conduit-Projekt gestartet hat. Stellt gern Fragen.

    • Ich nutze Conduit seit 10 Monaten und mag es wirklich sehr. Ich habe zwei Fragen.
      Ich frage mich, ob es nach deinem Studienabschluss Bedenken hinsichtlich der Zukunft des Projekts gibt. Bisher wirkt Timo wie der mit Abstand aktivste Contributor, daher mache ich mir Sorgen, ob das Projekt weiterhin stark davon abhängt, wie viel Zeit du investieren kannst.
      Außerdem frage ich mich, womit ein Rust/Linux-Entwickler anfangen sollte, um erstmals sinnvoll zu Conduit beizutragen. Auf GitLab gibt es 155 offene Issues, und aus Nutzersicht gibt es kein Problem, das sich besonders aufdrängt, daher weiß ich nicht, wo ich beginnen soll.
      Wenn Dortmund oder Remote-Arbeit keine zwingende Voraussetzung sind, kannst du dich gern melden, und ich wünsche dir, dass du eine gute Stelle findest.
    • Ich frage mich, was du von matrix-p2p / Pinecone hältst, das für Dendrite entwickelt wird.
      Außerdem interessiert mich, ob es Pläne gibt, Conduit in naher Zukunft ebenfalls P2P-fähig zu machen.
      https://github.com/matrix-org/pinecone
      https://archive.fosdem.org/2022/schedule/event/matrix_p2p_pi...
    • Mich würde interessieren, was dich am Design von Matrix als Protokoll am meisten frustriert.
      Ich habe dazu auch eigene Eindrücke aus dem Schreiben von Bots, aber besonders interessiert mich die Perspektive eines Maintainers einer Homeserver-Implementierung.
    • Gibt es ein Dokument, das zusammenfasst, wie Conduit funktional im Vergleich zu Synapse oder zur Matrix-Spezifikation dasteht?
      Mir ist nicht klar, ob das Ziel ein voll funktionsfähiger Matrix-Server ist oder ob ein bestimmtes Subset in Bezug auf Skalierung oder Funktionen angestrebt wird.
    • Mich interessiert, ob du Conduit selbst täglich nutzt. Ich möchte wissen, ob es für den Alltagsgebrauch stabil ist.

  • Was mir an Matrix nicht gefallen hat: Ich betrieb einen Server mit 3–4 Nutzern, und nach ein paar Monaten war die Datenbank auf etwa 80 GB angewachsen.
    Von Nutzern hochgeladene Inhalte und Texte zusammen machten vielleicht 2–3 GB aus. Ich frage mich, ob es eine Möglichkeit gibt, gecachte Daten von alten Servern etwa ab einem Alter von zwei Wochen zu löschen und sie bei Bedarf erneut abzurufen.

    • Es gibt eine Admin-API, mit der man alte lokale/entfernte Bilder löschen kann. In dieser Situation ist das vermutlich die passende API.
      https://matrix-org.github.io/synapse/v1.85/admin_api/media_a...
      Mein Server ist nicht föderiert, aber ziemlich aktiv, und ich behandle ihn wie einen temporären Raum. Ich habe ihn so konfiguriert, dass sowohl Text als auch Medien, die älter als ein bis zwei Wochen sind, automatisch bereinigt werden.
    • Was Platz belegt, sind die Zustandsdaten der Räume/Unterhaltungen, und die lassen sich komprimieren.
      https://levans.fr/shrink-synapse-database.html
      https://github.com/matrix-org/rust-synapse-compress-state
    • Wegen solcher Dinge schätze ich XMPP höher ein. Es gibt nicht die Erwartung, den gesamten Verlauf eines Chatraums replizieren zu müssen.
      Bei vielen MUCs sind standardmäßig die letzten 20 Nachrichten eingestellt, was normalerweise reicht, um den Gesprächsverlauf zu verstehen und einzusteigen. Auch die Betriebskosten meines Servers waren ziemlich niedrig.

  • Ich frage mich, ob es eine Möglichkeit zur Migration von Synapse zu Conduit gibt. Es ist schwer zu rechtfertigen, sechs Jahre Chatverlauf wegzuwerfen.

    • Noch nicht. Es gibt Pläne für ein Migrationstool von Synapse zu Dendrite, aber Unterstützung für Conduit müsste separat hinzukommen.
      So oder so ist unklar, wie lange das dauern wird.
      Ich habe nur den Tracking-Issue zur Migration von Synapse -> Dendrite gefunden.
      https://github.com/matrix-org/dendrite/issues/1705

  • Verwandter Beitrag: Conduit Beta – Matrix chat server - https://news.ycombinator.com/item?id=28385840 - September 2021, 69 Kommentare

  • Kann jemand erklären, warum man Matrix nutzen sollte, wenn es doch XMPP gibt?

    • Mein erster Gedanke war eher, dass die Frage umgekehrt sein sollte. Ich weiß nicht, warum man XMPP nutzen sollte, daher nenne ich mal die guten Seiten von Matrix.
      Es ist eine moderne Chat-Lösung mit den Funktionen, die Leute von Slack und Discord erwarten, und es gibt viele Bridges, sodass man nicht mehrere Chat-Clients für verschiedene Protokolle verwenden muss.
      Es gibt viele großartige Communities, Voice-Chat ist ziemlich gut, es ist Open Source und kann selbst gehostet werden. Mich würde interessieren, was an XMPP gut ist.
    • Matrix ist eher wie Chatten mit Git, nutzt eine verteilte Datenbank und hat stärker den Charakter eines Team-Messengers wie Mattermost oder Zulip.
      XMPP ist strukturell eher wie E-Mail, mit Optionen wie Online-Status, „tippt gerade“ und letzter Verbindung; auch große Messenger-Dienste wie WhatsApp nutzen oft eigene Abwandlungen davon.
      XMPP ist das einzige System, das man überall dort nutzen kann und darf, wo E-Mail genutzt wird. Es ist genauso modern wie Matrix, denkt nur anders über Datenspeicherung und Verteilung.
      Vergleich: https://www.freie-messenger.de/en/systemvergleich/xmpp-matri...
    • Diese Zusammenfassung trifft auch heute noch zu: https://news.ycombinator.com/item?id=8998290
      XMPP ist für den Zweck, für den es entworfen wurde, großartig, passt aber nicht gut zu Mobile, hoher Paketverlustrate und Verbindungen mit hoher Latenz. Es ist gesprächig und verbraucht viel Bandbreite, was in Umgebungen mit begrenztem Datenvolumen und Akku ungünstig ist; außerdem wurde die Realität, dass eine Person mehrere Geräte nutzt, ursprünglich nicht berücksichtigt.
      Dateiübertragung war lange ebenfalls nicht gut, und je nach Client und Netzwerkform gab es einen Mix inkompatibler Ansätze.
      Auch die zu große Zahl an XEPs hilft dem Ökosystem nicht. Wenn es zu viele optionale Erweiterungen gibt, leidet die Interoperabilität. Die Funktionen, die man heute von Chat erwartet, gehen über den ursprünglichen Designrahmen von XMPP hinaus; XEPs haben versucht, das zu flicken, aber die Ergebnisse waren gemischt.
      Zur Entwurfszeit war es eine natürliche technische Wahl, aber heute gibt es viele bessere Alternativen. Entwickler wählen nun einmal Technologien, die ihnen die Arbeit angenehmer machen, deshalb passiert auf neueren Plattformen mehr. Zum Beispiel ging es heute in einem anderen HN-Beitrag ebenfalls darum, dass ein normaler XML-Parser nicht ausreichen könnte und ein sehr fortgeschrittener XML-Parser nötig ist: https://news.ycombinator.com/item?id=36930196
    • XMPP hat einen kleinsten gemeinsamen Nenner, und ein großer Teil der Kernfunktionen liegt unter optionalen XEPs. Deshalb schwankt die Nutzererfahrung je nach Client und Server sehr stark.
      Matrix hat einen klarer definierten Satz wichtiger Funktionen, sodass man bei einem kompatiblen Client erwarten kann, dass sie einheitlich und ohne Überraschungen implementiert sind.
    • Matrix ist weniger eine Art, Nachrichten zu senden, sondern eher ein Dienst zur Zustandssynchronisierung.
      Wenn man einem Raum auf einem anderen Matrix-Server beitritt, beginnt der eigene Server, eine Kopie davon zu halten, und man kann sie so nutzen, wie man möchte. Wenn ich meinen Server einen Tag lang ausschalte und wieder einschalte, synchronisiert er sich erneut.
      Ich weiß nicht, ob XMPP so funktioniert, aber ich habe es mir immer eher wie E-Mail vorgestellt: Nachrichten senden und ein wenig erneut versuchen. Wie zwischen Servern aktueller Zustand, Lesebestätigungen, Tippbenachrichtigungen und ähnliche flüchtige Informationen funktionieren, weiß ich ebenfalls nicht genau.

  • Conduit ist ein sehr schönes Projekt, aber es scheint schwierig zu sein, den Status und Fortschritt zu verfolgen, ohne alle Commits und Issues zu lesen.
    Die jüngsten Fortschritte bei der eingebauten Sliding-Sync-Funktion sind vielversprechend, weil dadurch die Bereitstellung deutlich einfacher wird.

  • Weiß jemand, warum bei Matrix manchmal die letzte Nachricht erst entschlüsselt wird, wenn eine neue letzte Nachricht gesendet wird, oder warum umliegende Nachrichten funktionieren, aber eine einzelne Nachricht nicht entschlüsselt werden kann?

    • Ich verstehe es noch nicht vollständig, aber nicht alle Nachrichten werden mit demselben Schlüssel verschlüsselt.
      Wenn nicht alle meine Clients gleichzeitig verbunden sind und das Gleiche für den Absender gilt, können sie untereinander keine Schlüssel austauschen. Dann kann jeder Client nur den Teil der Nachrichten entschlüsseln, für den er Schlüssel besitzt. Außerdem tauschen Clients Schlüssel nur mit anderen verifizierten Clients aus.
      Wenn man sich in der JSON-Rohfassung einer Nachricht die Eigenschaft session_id ansieht, sieht man, dass alle Nachrichten einer bestimmten Session – also während der Absender auf einem Client eingeloggt war – entweder alle entschlüsselt werden können oder gar nicht. Ersteres bedeutet, dass man den Schlüssel für diese Session hat, Letzteres, dass man ihn noch nicht erhalten hat.

  • Vielleicht habe ich etwas übersehen, aber die Seite wirkt sehr schlicht und scheint vorauszusetzen, dass man bereits weiß, was Matrix ist und wie man es benutzt
    Für die verschiedenen Installationsarten wird viel Zeit aufgewendet, aber zur eigentlichen Nutzung des Servers, etwa mit Clients, sehe ich nichts

    • Der erste Link auf der Seite führt zu matrix.org, und auf matrix.org gibt es einen Link zu den Clients: https://matrix.org/ecosystem/clients/
      Vermutlich nimmt man einfach Element
      Ich finde, die Conduit-Seite macht es richtig. Sie setzt nicht so sehr voraus, dass man weiß, was Matrix ist, sondern eher, dass man genug Verständnis hat, um auf den Link zu klicken, wenn man es nicht weiß
    • Wenn man mit Matrix.org vertraut ist, ist die Landingpage ziemlich gut. Sie scheint auf Matrix-Entwickler ausgerichtet zu sein
      Persönlich fand ich sie gut, weil sie kurz ist, das zu lösende Problem knapp erkennbar macht und der eigentliche Call-to-Action, der Link zum Git-Repository, schnell kommt
      Es kann natürlich sein, dass die Landingpage selbst seit dem ursprünglichen Beitrag mit neuen Inhalten aktualisiert wurde
    • Hat sich der Link geändert?
      Matrix ist ein offenes Netzwerk für sichere und dezentralisierte Kommunikation. Nutzer jedes Matrix-Homeservers können mit Nutzern jedes anderen Matrix-Servers chatten. Über Bridges können sie auch mit Nutzern außerhalb von Matrix kommunizieren, etwa in Discord-Communitys
      Und Installationsinformationen sehe ich nicht
    • Matrix ist ein Chat-Protokoll. Es funktioniert ein bisschen wie Chatten mit Git und nutzt eine verteilte Datenbank; es ist eher mit Team-Messengern wie Mattermost oder Zulip vergleichbar
      Conduit ist Server-Software, keine App für Endnutzer
      Weitere Informationen zu Matrix: https://www.freie-messenger.de/en/matrix

  • Ich frage mich, in welchem Verhältnis Conduit zu Synapse steht
    Dendrite wird mit https://github.com/matrix-org/sytest getestet, und es gibt auch Issues wie „Ist das noch Synapse?“, aber bei Conduit konnte ich keine entsprechende Diskussion finden. Nicht einmal eine Diskussion darüber, warum man nicht wie Synapse werden will

    • Conduit ist eine Third-Party-Implementierung der Matrix-Server-Spezifikation in Rust. Synapse und Dendrite sind beide offizielle Implementierungen, und Dendrite wurde ursprünglich mit dem Ziel gestartet, Synapse zu ersetzen
      Als Vorteile werden Leichtgewichtigkeit und einfache Installation angeführt, was impliziert, dass Synapse das nicht ist. Wichtiger noch: Conduit wurde zu einem Validierungsfall für die Matrix-Server-Spezifikation und hat über Jahre hinweg einiges dazu beigetragen, unklare Stellen zu präzisieren
    • SyTest ist hauptsächlich auf die Nutzung mit Synapse zugeschnitten, und bei Dendrite scheint man Wrapper-Arbeit zu leisten, um es in die eigene Continuous Integration einzubinden
      Conduit könnte vermutlich Teile dieser Arbeit wiederverwenden, aber soweit ich mich erinnere, nutzt Conduit GitLab und Dendrite GitHub Actions
      Unabhängig davon scheint Conduit derzeit kein Drop-in-Ersatz für Synapse sein zu wollen. Als ich zuletzt in den Matrix-Räumen geschaut habe, gab es noch mehrere auffällige Funktionslücken