SimpleX-Chatserver auf einem VPS selbst hosten

Was ein selbst gehosteter SimpleX-Chatserver leistet

Für den Betrieb eines selbst gehosteten SimpleX-Chatservers führen Sie auf einem VPS einen Daemon aus: smp-server, das Relay für SMP (simplex messaging protocol). Es verwaltet die Nachrichtenwarteschlangen, in die Ihre Kontakte schreiben und aus denen sie lesen. Ein zweiter, optionaler Daemon namens xftp-server leitet Dateiübertragungen weiter. Beide stammen aus demselben Projekt, simplexmq, und bestehen jeweils aus einer einzelnen Binärdatei, einer Konfigurationsdatei und einem Append-only-Log.

Dieser Text richtet sich an den Betreiber, nicht an den App-Benutzer. Das Relay verwaltet keine Konten, keine Kontaktlisten und keinen Chatverlauf. Es enthält Warteschlangen, einige nicht zugestellte Chiffretexte und ein Zertifikat, das es identifiziert. Sie übernehmen die Verantwortung für Verfügbarkeit, etwas Speicherplatz und die Metadaten, die Ihren Server passieren.

Jeder Befehl, jeder Pfad, jeder Port und jedes Flag unten stammt aus der offiziellen Dokumentation des Projekts: der SMP-Server-Hosting-Seite, der XFTP-Server-Seite und dem Dokument zur Protokollsicherheit. Wenn eine Zahl relevant ist, wird die Seite, aus der sie stammt, direkt daneben genannt.

Warum ein Netzwerk ohne Benutzerkennungen weiterhin Relays benötigt

SimpleX verwendet keine Benutzernamen, keine Telefonnummern und keine Konto-IDs. Ein Kontakt ist eine unidirektionale Warteschlange: eine Adresse auf einem Relay, in die eine Seite schreibt und aus der die andere Seite liest. Zwei Ihrer Kontakte teilen keine Kennung, anhand derer ein Server sie zusammenführen könnte.

Diese Warteschlangen müssen trotzdem irgendwo gespeichert werden. Der Grund ist einfach: Zwei Telefone sind nur selten im selben Moment online. Ein System muss eine Nachricht jetzt annehmen und speichern, bis das andere Gerät sie abruft. Genau das ist die Aufgabe eines SMP-Relays. Dadurch verbinden sich die beiden Geräte auch nie direkt miteinander. Daher erfährt keines der Geräte die IP-Adresse des anderen. Das Relay übernimmt diese Offenlegung stattdessen.

Der Hostname des Relays ist Bestandteil der Adresse der Warteschlange. Er steht daher in jedem Einladungslink, den Sie über dieses Relay weitergeben. Berücksichtigen Sie das, wenn Sie weiter unten das Bedrohungsmodell lesen.

Was ein Relay sehen kann und was nicht

Das Projekt beschreibt dies in protocol/security.md als Bedrohungsmodell. Sie sollten diese Beschreibung lesen, bevor Sie etwas installieren. Nach dieser Anleitung gehört das Relay Ihnen. Ein Relay kann den Inhalt und den Nachrichtentyp nicht erfahren, auch wenn es vollständig von einem Angreifer kontrolliert wird. Es kann einzelne Nachrichten nicht unbemerkt hinzufügen, duplizieren oder beschädigen. Mit einem aktiven Angriff kann es die Ende-zu-Ende-Verschlüsselung nicht brechen.

Auf derselben Seite wird aufgeführt, was ein Relay kann. Es kann erkennen, wann ein Queue-Empfänger online ist. Es kann zählen, wie viele Nachrichten eine Queue durchlaufen. Es kann die IP-Adresse eines Empfängers erfahren. Es kann alle zukünftigen Nachrichten in einer Queue verwerfen oder den Zustand dieser Queue falsch darstellen.

Die Zuständigkeiten sind damit klar getrennt. Für die Vertraulichkeit ist der Client zuständig. Self-Hosting hat darauf keinen Einfluss. Für Metadaten und Verfügbarkeit ist der Relay-Betreiber zuständig. Durch Self-Hosting übernehmen Sie beide Aufgaben.

Was Sie vor dem Start benötigen

• Einen VPS mit Ubuntu 22.04 oder 24.04. Das Projekt veröffentlicht Release-Binärdateien, die genau für diese beiden Versionen in x86-64 und aarch64 erstellt wurden.
• Einen Domainnamen mit einem A-Record, der auf den VPS zeigt, sowie einen AAAA-Record, wenn Sie IPv6 verwenden. Die Dokumentation verwendet smp1.example.com als Beispiel.
• Root- oder sudo-Zugriff sowie eine zweite geöffnete SSH-Sitzung, während Sie die Firewall ändern.
• Einen Speicherort außerhalb des Servers für ein Backup, da das Konfigurationsverzeichnis die Identität des Servers enthält.

Verwenden Sie auf einer ARM-Instanz das Asset aarch64 anstelle von x86-64. Ansonsten ändert sich in dieser Anleitung nichts. Die Wahl zwischen ARM- und x86-VPS-Tarifen betrifft den Preis und die Geschwindigkeit pro Kern, nicht die Frage, ob diese Software ausgeführt werden kann.

Installieren Sie ein festgelegtes Release, nicht „latest“

Das Projekt stellt ein Installationsskript bereit, das das aktuelle Release abruft und einen simplex-servers-update-Befehl registriert. Das funktioniert. Legen Sie die Version trotzdem fest: Wenn sich die Binärdatei eines Relay-Dienstes unbemerkt ändert, lässt sich bei einem Fehler nicht mehr nachvollziehen, was passiert.

Im August 2026 ist v6.5.0 das aktuelle simplexmq-Release. Es wurde am 29 April 2026 veröffentlicht. Prüfen Sie die Release-Seite auf den gewünschten Tag und verwenden Sie diesen Tag anschließend überall weiter unten.

sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplex

useradd -m smp legt kein Passwort fest. Daher meldet sich niemand direkt als smp an. Erstellen Sie die beiden Verzeichnisse selbst, bevor Sie weitere Befehle ausführen. /etc/opt gehört root und hat den Modus 755. Dadurch kann der Benutzer smp sein eigenes Konfigurationsverzeichnis nicht erstellen.

VER=v6.5.0
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/smp-server-ubuntu-24_04-x86-64" -o /tmp/smp-server
sha256sum /tmp/smp-server

Vergleichen Sie diesen Hash mit den SHA2-256-Prüfsummen, die in den Release-Hinweisen für denselben Tag veröffentlicht wurden. Das Projekt signiert Release-Prüfsummen außerdem mit dem SimpleX-Chat-Schlüssel FB44AF81A45BDE327319797C85107E357D4A17FC. Dieser ist auf der Server-Seite dokumentiert. Dadurch können Sie die Signatur prüfen, statt der Seite zu vertrauen, von der Sie den Hash übernommen haben.

sudo install -m 755 -o root -g root /tmp/smp-server /usr/local/bin/smp-server

Installieren Sie die Datei absichtlich mit root als Eigentümer. Der Dienst läuft als smp. Dadurch kann ein kompromittierter Dienst die Binärdatei, mit der er gestartet wird, nicht überschreiben.

Server und die beiden ausgegebenen Geheimnisse initialisieren

sudo su smp -c "smp-server init --yes --store-log --daily-stats --no-password --fqdn=smp1.example.com"

• --store-log (-l) schreibt ein nur anhängbares Protokoll der Warteschlangen nach /var/opt/simplex/smp-server-store.log, damit das Relay einen Neustart übersteht. Ohne diese Option verwirft ein Neustart jede Warteschlange. Dadurch funktioniert jeder über Sie geleitete Kontakt nicht mehr.
• --daily-stats (-s) schreibt Zähler im CSV-Format nach /var/opt/simplex/smp-server-stats.daily.log.
• --fqdn fügt Ihre Domain in das generierte Zertifikat ein. Verwenden Sie stattdessen --ip, wenn Sie keine Domain haben.
• --no-password erlaubt jedem, eine Warteschlange auf Ihrem Relay anzulegen. Um es privat zu halten, setzen Sie nach der Initialisierung create_password unter [AUTH] in /etc/opt/simplex/smp-server.ini, statt hier --password zu übergeben. Eine Befehlszeile ist während der Ausführung in Ihrer Shell-Historie und in der Prozessliste sichtbar.

Init generiert ein Zertifikat und gibt die beiden Werte aus, die Sie aufbewahren müssen. Der erste Wert ist der Fingerprint, eine Base64-Zeichenfolge, die auch nach /etc/opt/simplex/fingerprint geschrieben wird. Der zweite Wert ist die vollständige Serveradresse. Sie besteht aus dem Fingerprint und Ihrem Hostnamen. Kopieren Sie jetzt beide Werte.

Init erstellt außerdem /etc/opt/simplex/ca.key. Die Dokumentation weist Sie an, diese Datei in einen Offline-Speicher zu verschieben. Der Grund ist wichtig: Clients pinnen den Fingerprint dieser Zertifizierungsstelle. Jeder, der über ca.key verfügt, kann daher ein neues Serverzertifikat ausstellen, das Ihre Clients als Ihr Zertifikat akzeptieren. Sie benötigen die Datei erst wieder, wenn Sie das Serverzertifikat später mit smp-server cert rotieren.

Behandeln Sie Init als einmaligen Schritt. Der Fingerprint in Ihrer Adresse stammt von der erzeugten Zertifizierungsstelle. Wenn Sie diese Zertifizierungsstelle neu generieren, erhalten Sie eine andere Adresse. Die bereits verteilte Adresse ist dann nicht mehr gültig.

Führen Sie es unter systemd als nicht privilegierter Benutzer aus

Schreiben Sie /etc/systemd/system/smp-server.service genau so, wie es in der Dokumentation angegeben ist:

[Unit]
Description=SMP server systemd service

[Service]
User=smp
Group=smp
Type=simple
ExecStart=/usr/local/bin/smp-server start +RTS -N -RTS
ExecStopPost=/usr/bin/env sh -c '[ -e "/var/opt/simplex/smp-server-store.log" ] && cp "/var/opt/simplex/smp-server-store.log" "/var/opt/simplex/smp-server-store.log.bak"'
LimitNOFILE=65535
KillSignal=SIGINT
TimeoutStopSec=infinity

[Install]
WantedBy=multi-user.target

Die Upstream-Unit enthält außerdem AmbientCapabilities=CAP_NET_BIND_SERVICE. Diese Zeile ist erforderlich, weil der Prozess als smp ausgeführt wird und Ports unter 1024 für einen Nicht-root-Prozess nicht verfügbar sind. Ohne diese Zeile kann der Daemon daher nicht an 80 oder 443 binden. Fügen Sie sie hinzu, wenn Sie diese Ports bereitstellen. LimitNOFILE=65535 ist wichtig, weil jede abonnierte Client-Verbindung eine offene TCP-Verbindung hält und das Standardlimit für einen ausgelasteten Relay-Dienst deutlich zu niedrig ist. ExecStopPost kopiert das Store-Log bei jedem Stop in eine .bak-Datei. Damit erhalten Sie einen kostenlosen Rollback-Punkt.

sudo systemctl daemon-reload
sudo systemctl enable --now smp-server
sudo systemctl status smp-server
sudo journalctl -fu smp-server

Bei einem erfolgreichen Start wird die Serveradresse protokolliert. Prüfen Sie anschließend, ob die Sockets tatsächlich geöffnet sind:

sudo ss -tlnp | grep -E ':(443|5223)'

Beide Zeilen sollten smp-server nennen. Den Daemon unter einem eigenen Konto ohne sudo-Rechte auszuführen, entspricht der in dienstbezogene Konten auf einem VPS beschriebenen Vorgehensweise. Dadurch kann ein Fehler in einem Netzwerk-Daemon nicht zu einer Root-Shell werden.

Welche Ports geöffnet werden müssen und welcher geschlossen bleiben sollte

Die Dokumentation führt drei Ports auf: 5223/tcp, 443/tcp und 80/tcp. Port 5223 ist der SMP-Transport. Die mitgelieferte Konfiguration setzt port: 5223,443 unter [TRANSPORT], sodass dasselbe Protokoll auch auf 443 antwortet. Das ist wichtig, weil viele restriktive Netzwerke ausgehenden Verkehr nur über 443 zulassen. Port 80 wird nur für die optionale Informationsseite und deren Weiterleitung auf HTTPS benötigt.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5223/tcp
sudo ufw enable

Öffnen Sie 5224 nicht. Das ist der Steuerport. Die Dokumentation greift vom Server selbst mit nc 127.0.0.1 5224 darauf zu. Der Port gibt den Serverstatus aus und löscht Warteschlangen. Er sollte daher auf Loopback beschränkt bleiben. Die Administrator- und Benutzerpasswörter werden unter [AUTH] gesetzt. Wenn Sie mit dem Tool noch nicht vertraut sind, erklärt die Grundlagen von ufw auf einem VPS die Reihenfolge der Regeln und wie Sie vermeiden, sich selbst auszusperren.

Eine weitere Zugriffskontrolle wird häufig übersehen. Die meisten Anbieter betreiben im Verwaltungsbereich eine Netzwerk-Firewall, die von ufw auf dem Server getrennt ist. Ein Port kann in ufw geöffnet sein und trotzdem vorher verworfen werden, bevor der Verkehr den Server erreicht.

Die Serveradresse, die Ihre Clients benötigen

smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]

Diese Zeichenfolge ist die vollständige clientseitige Konfiguration. Fügen Sie sie in den Servereinstellungen der Anwendung ein, oder lassen Sie sie von jemandem über den QR-Code scannen, den die Anwendung dafür anzeigt. Die Dokumentation weist darauf hin, dass der QR-Code das Passwort enthält. Eine Person, die ihn scannt, kann daher ebenfalls Nachrichten über Ihren Server empfangen.

Ein dokumentiertes Verhalten überrascht viele. Wenn Sie Ihren Server in der Anwendung hinzufügen, betrifft das nur Kontakte, die Sie ab diesem Zeitpunkt erstellen. Bestehende Kontakte verbleiben auf den Relays, auf denen ihre Queues erstellt wurden, und werden nicht migriert. Deshalb können Sie ein Relay auch nicht am Tag nach seinem Austausch abschalten.

Hinzufügen eines XFTP-Dateirelays

XFTP (SimpleX file transfer protocol) ist der Dateiteil des Netzwerks. Es läuft als separater Daemon mit einer eigenen Adresse. Laut der XFTP-Ankündigung des Projekts verfügen Relays über keinerlei Dateimetadaten. Sie sehen nur einzelne Chunks mit jeweils 256kb, 1mb oder 4mb, deren Zugriff durch anonyme Zugangsdaten autorisiert wird. Ein Sender kann die Chunks einer Datei auf mehrere Relays verteilen. Ihr Server enthält daher Teile, nicht die vollständigen Dateien.

sudo useradd -m xftp
sudo install -d -o xftp -g xftp -m 755 /etc/opt/simplex-xftp /var/opt/simplex-xftp /srv/xftp
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/xftp-server-ubuntu-24_04-x86-64" -o /tmp/xftp-server
sudo install -m 755 -o root -g root /tmp/xftp-server /usr/local/bin/xftp-server
sudo su xftp -c "xftp-server init -l --fqdn=xftp1.example.com -q '20gb' -p /srv/xftp/"

Die Konfiguration befindet sich in /etc/opt/simplex-xftp/, der Status in /var/opt/simplex-xftp/ und die Dateichunks in dem Pfad, den -p angibt. Die systemd-Unit hat mit User=xftp und ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS denselben Aufbau. Bei der Initialisierung wird eine xftp://-Adresse im selben Format wie die SMP-Adresse ausgegeben. Sie hat ihren eigenen Fingerprint in /etc/opt/simplex-xftp/fingerprint.

Planen Sie eine mögliche Portkollision ein. Der dokumentierte Port des XFTP-Servers ist 443, und auch die SMP-Konfiguration enthält 443. Zwei Prozesse können nicht denselben Port auf derselben Adresse binden. Auf einem VPS muss daher eine Anpassung erfolgen. Am einfachsten setzen Sie port: 5223 im Abschnitt [TRANSPORT] der SMP-Konfiguration und überlassen Port 443 dem Dateirelay. Dafür steht Clients in restriktiven Netzwerken der Fallback über Port 443 nicht mehr zur Verfügung. Alternativ können Sie eine zweite IP-Adresse auf demselben VPS oder einen zweiten VPS verwenden.

Legen Sie das Kontingent realistisch fest. -q '20gb' ist eine Zusage über den verfügbaren Speicherplatz. Das Dateirelay verbraucht Speicherplatz und Bandbreite. Das Nachrichtenrelay beansprucht beides kaum.

Was auf der Festplatte liegt und was ein Backup wiederherstellt

Zwei Verzeichnisse sind wichtig. /etc/opt/simplex/ ist die Identität: smp-server.ini, das Serverzertifikat und der Schlüssel, ca.key sowie fingerprint. /var/opt/simplex/ enthält den Zustand: smp-server-store.log enthält die Warteschlangen und, wenn restore_messages: on, die nicht zugestellten Nachrichten sowie die tägliche Statistikdatei.

sudo systemctl stop smp-server
sudo tar czf /root/simplex-backup.tgz -C / etc/opt/simplex var/opt/simplex
sudo chmod 600 /root/simplex-backup.tgz
sudo systemctl start smp-server

Machen Sie sich klar, was dieses Archiv enthält. Es ist kein Nachrichtenarchiv: Die Elemente in der Warteschlange sind Chiffretext für Schlüssel, die das Relay nie besaß, und die mitgelieferte Konfiguration [STORE_LOG] löscht Nachrichten ohnehin nach 21 Tagen. Das Archiv ist eine Kopie der Serveridentität einschließlich ca.key. Wer die Datei erhält, kann sich gegenüber Ihren Kontakten als Ihr Relay ausgeben. Verschlüsseln Sie die Datei und bewahren Sie sie außerhalb des Servers auf.

Der Vorteil zeigt sich bei der Wiederherstellung. Stellen Sie /etc/opt/simplex auf einem neuen VPS wieder her und verweisen Sie denselben DNS-Namen darauf. Der Fingerprint bleibt unverändert. Dadurch funktionieren alle von Ihnen ausgegebenen Adressen weiterhin. Wenn Sie dieses Verzeichnis verlieren, gibt es keine Wiederherstellung: Eine neue Installation erzeugt einen neuen Fingerprint. Das bedeutet eine neue Adresse und damit den Verlust jedes Kontakts, der über Ihr Relay weitergeleitet wurde.

TLS: zwei Zertifikate für unterschiedliche Aufgaben

Der SMP-Transport verwendet keine öffentliche Zertifizierungsstelle. init erzeugt eine private Zertifizierungsstelle und ein Serverzertifikat. Der Fingerabdruck dieser Zertifizierungsstelle ist in der Serveradresse enthalten. Der Client vergleicht die Serverantwort mit diesem fest hinterlegten Fingerabdruck. Dadurch wird die Verbindung zwischen Client und Server laut Projektbeschreibung gegen Man-in-the-Middle-Angriffe geschützt. Auf diesem Port muss kein ACME-Client (automatic certificate management environment) ausgeführt werden. Die Erneuerung erfolgt manuell mit dem Lauf smp-server cert und gesetztem SMP_SERVER_CFG_PATH.

Die optionale Informationsseite verwendet das andere Zertifikat. In ihrem Abschnitt [WEB] werden static_path, https: 443, cert: /etc/opt/simplex/web.crt und key: /etc/opt/simplex/web.key angegeben. Ein Browser kennt Ihre private Zertifizierungsstelle nicht. Daher ist dies die Stelle, an der ein öffentlich vertrauenswürdiges Zertifikat verwendet wird. Der Docker-Schnellstart der Dokumentation setzt Caddy genau dafür vor den Server und stellt das Zertifikat automatisch aus.

Über das Tor-Netzwerk den Relay erreichen

Die Dokumentation enthält einen Tor-Abschnitt. Darin wird Tor aus dem Repository des Tor Project installiert und ein Onion-Service in /etc/tor/torrc eingerichtet:

SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:443

Lesen Sie die beiden Moduszeilen sorgfältig. Single Hop und non-anonymous bedeuten, dass der Standort des Relays selbst nicht verborgen ist. Die Onion-Adresse ist schnell und bietet Clients einen Zugang, über den Ihre IP-Adresse niemals an Sie übermittelt wird. Der Server bleibt jedoch unter seiner öffentlichen IP-Adresse auffindbar. Der Onion-Hostname aus /var/lib/tor/simplex-smp/hostname wird nach einem Komma an das Ende der Serveradresse gesetzt. Wenn auch der Standort des Servers verborgen werden soll, ist eine andere Konfiguration erforderlich. Der Betrieb eines echten Onion-Service auf einem VPS erläutert die damit verbundenen Abwägungen. Der Unterschied zwischen den Informationen, die die einzelnen Tools verbergen, wird unter Tor im Vergleich zu einem VPN behandelt und gilt hier unmittelbar.

Bedrohungsmodell: Was Self-Hosting ändert

Was es Ihnen bringt. Die Metadaten (welche Queues existieren, wann sie gelesen werden und welche Adressen Verbindungen herstellen) liegen auf einer von Ihnen kontrollierten Maschine. Sie legen fest, wie lange diese Daten gespeichert werden. Außerdem gehören Sie nicht zu einem großen Pool, dessen Daten gesammelt angefordert werden können.

Was es ausdrücklich nicht bringt:

• Die Verschlüsselung bleibt unverändert. Nachrichten waren bereits Ende-zu-Ende-verschlüsselt, bevor Sie diesen Dienst selbst betrieben haben, und sind es danach weiterhin. Self-Hosting ist eine Metadatenentscheidung, keine Entscheidung über die Kryptografie.
• Ihr VPS-Provider sieht den Netzwerkverkehr zu Ihrer IP-Adresse und speichert Ihre Abrechnungsdaten. Sie verlagern das Vertrauen vom Messaging-Betreiber zum Hosting-Betreiber. Sie schaffen es nicht ab.
• Ihr Relay bildet eine kleine Gruppe. Wenn es nur einen Haushalt bedient, identifiziert die Verbindung zu ihm diesen Haushalt. Außerdem steht sein Hostname in jedem Einladungslink, den Sie darüber versenden. Ein stark ausgelastetes öffentliches Relay schützt Sie in dieser Hinsicht besser. Das ist der eigentliche Kompromiss.
• Die Verfügbarkeit liegt jetzt in Ihrer Verantwortung. Ein volles Dateisystem oder ein ausgefallener Rechner verhindert die Zustellung von Nachrichten. Ihre Kontakte können Sie nicht umgehen.

Dieselbe Überlegung gilt für jeden privaten Dienst, den Sie auf einem eigenen Rechner betreiben, unabhängig davon, ob es sich um dieses Relay oder um ein WireGuard-VPN auf Ihrem eigenen VPS handelt. Sie entscheiden, welche Partei die Metadaten sieht. Sie lassen sie nicht verschwinden.

Wenn es nicht funktioniert

Der Dienst startet und beendet sich sofort wieder. Lesen Sie sudo journalctl -u smp-server -n 50. Ein Bind-Fehler nennt den Port, den der Dienst nicht übernehmen konnte. Führen Sie anschließend sudo ss -tlnp | grep :443 aus, um zu sehen, welcher Prozess ihn bereits verwendet. Auf einem frisch eingerichteten System ist das meist nginx, Caddy oder der XFTP-Server, den Sie vor einer Stunde installiert haben.

Init kann seine Konfiguration nicht schreiben. Wenn Sie smp-server init als Benutzer smp ausführen, bevor /etc/opt/simplex existiert, wird ein Berechtigungsfehler ausgegeben, weil /etc/opt root gehört. Erstellen Sie zuerst das Verzeichnis mit dem richtigen Eigentümer. Führen Sie init anschließend erneut aus.

Clients können das Relay nicht erreichen. Prüfen Sie mit dig +short smp1.example.com, ob der Name zur richtigen Adresse aufgelöst wird. Testen Sie den Port anschließend von Ihrem Laptop und nicht vom Server aus: nc -vz smp1.example.com 5223. Wenn die Verbindung von außen fehlschlägt, während ss den geöffneten Socket auf dem System anzeigt, liegt die Ursache in der Netzwerk-Firewall des Providers. Diese ist von ufw getrennt.

Ein Kontakt kann sich nicht über Ihr Relay verbinden. Der Fingerabdruck in der von Ihnen weitergegebenen Adresse muss mit dem aktuellen Inhalt von /etc/opt/simplex/fingerprint übereinstimmen. Wenn Sie create_password unter [AUTH] festgelegt haben, muss die Adresse dieses Passwort ebenfalls enthalten. Andernfalls darf der Client keine Warteschlange erstellen.

Nachdem Sie den Server in der Anwendung hinzugefügt haben, wurden keine Daten übertragen. Das ist beabsichtigt. Nur neue Kontakte verwenden das neu hinzugefügte Relay. Bestehende Kontakte behalten die Warteschlangen, die sie bereits haben.

FAQ

Macht Self-Hosting eines SimpleX-Servers meine Nachrichten sicherer?

Nein. Das ist beabsichtigt. SimpleX verschlüsselt Nachrichten Ende zu Ende zwischen den Geräten. Der Relay-Server besitzt daher niemals die kryptografischen Schlüssel, unabhängig davon, wer ihn betreibt. Self-Hosting ändert, wer die Metadaten dieser Nachrichten beobachtet: welche Queues vorhanden sind, wann sie gelesen werden und welche IP-Adressen eine Verbindung herstellen. Das ist eine Entscheidung über Metadaten. Wenn eine stärkere Verschlüsselung der Grund für Self-Hosting ist, war diese Verschlüsselung bereits vorhanden.

Was kann der Betreiber eines SimpleX-Relays tatsächlich sehen?

Das protocol/security.md des Projekts beschreibt dies. Ein Relay kann Nachrichteninhalte oder Nachrichtentypen nicht lesen. Es kann einzelne Nachrichten nicht unbemerkt verändern und die Ende-zu-Ende-Verschlüsselung nicht durch einen aktiven Angriff brechen. Es kann sehen, wann der Empfänger einer Queue online ist, die über eine Queue übertragenen Nachrichten zählen, die IP-Adresse eines Empfängers ermitteln, zukünftige Nachrichten in einer Queue verwerfen oder den Status dieser Queue falsch darstellen. Über diese Möglichkeiten verfügen Sie, sobald das Relay Ihnen gehört.

Benötige ich einen Domainnamen und ein TLS-Zertifikat?

Für eine nutzbare Konfiguration benötigen Sie eine Domain. smp-server init akzeptiert jedoch --ip, wenn Sie tatsächlich keine Domain haben. Für den Messaging-Port benötigen Sie kein Zertifikat einer öffentlichen Zertifizierungsstelle: init erzeugt eine eigene Zertifizierungsstelle, und der Client pinnt den Fingerabdruck, der in Ihrer smp://-Adresse erscheint. Ein öffentlich vertrauenswürdiges Zertifikat ist nur für die optionale Webinformationsseite erforderlich. Sie wird als cert und key im Abschnitt [WEB] von smp-server.ini konfiguriert.

Was passiert, wenn ich /etc/opt/simplex verliere?

Jede von Ihnen vergebene Adresse funktioniert dann nicht mehr. Dieses Verzeichnis enthält die Zertifizierungsstelle, deren Fingerabdruck in Ihrer Serveradresse eingebettet ist. Ein Neuaufbau erzeugt daher einen anderen Fingerabdruck und damit einen anderen Server. Kontakte, deren Queues auf diesem Relay liegen, können nicht clientseitig repariert werden. Sichern Sie das Verzeichnis verschlüsselt und außerhalb des Servers. Speichern Sie außerdem ca.key offline, wie es die Dokumentation vorgibt, denn jeder, der darüber verfügt, kann Ihr Relay imitieren.

Kann ich das SMP-Relay und das XFTP-Dateirelay auf demselben VPS betreiben?

Ja, allerdings muss ein Konflikt behoben werden. Der dokumentierte Port des XFTP-Servers ist 443, und die Standardkonfiguration von SMP enthält port: 5223,443. Beide benötigen daher denselben Socket. Weisen Sie Port 443 einem der beiden Dienste zu: Setzen Sie port: 5223 für den SMP-Server, oder verschieben Sie das Dateirelay auf eine zweite IP-Adresse oder einen zweiten VPS. Passen Sie außerdem das Speicherkontingent an den tatsächlich verfügbaren Speicherplatz an, denn das Dateirelay verbraucht Speicherplatz und Bandbreite.