Matrix & OpenClaw — Setup, Fallstricke und Praxis

Warum Matrix statt Telegram?

Telegram ist praktisch — kein Zweifel. Aber wenn man einen KI-Agenten betreibt, der 24/7 erreichbar sein soll, stellen sich Fragen: Wer hat meine Daten? Wer kann den Bot kicken? Was passiert wenn Telegram den API-Zugang ändert?

Matrix bietet hier eine überzeugende Alternative:

• E2EE — Ende-zu-Ende-Verschlüsselung in jedem Raum
• Dezentral — Eigener Synapse-Server, keine Abhängigkeit von einem Anbieter
• Selbstgehostet — Volle Kontrolle über Daten, Logs und Nutzer
• Offen — Open-Source-Protokoll, aktive Community

Nach vier Monaten Telegram mit OpenClaw war der Umstieg auf Matrix der logische nächste Schritt. Hier ist, was ich dabei gelernt habe.

Setup: Synapse auf Debian

Die Installation von Synapse auf Debian ist dank des offiziellen Matrix-Pakets relativ schmerzlos:

sudo apt install -y matrix-synapse-py3
sudo systemctl enable --now matrix-synapse

Wichtige Konfiguration in homeserver.yaml:

• server_name auf die eigene Domain setzen (z.B. netbits.duckdns.org)
• Registration deaktivieren und über Shared Secret steuern
• max_upload_size erhöhen (Standard ist nur 10 MB)
• Database — PostgreSQL statt SQLite für Produktivbetrieb

Caddy als Reverse Proxy

Caddy übernimmt TLS automatisch via Let’s Encrypt:

netbits.duckdns.org {
    reverse_proxy localhost:8008
}

Für die Federation müssen die .well-known/matrix/server und .well-known/matrix/client Dateien korrekt ausgeliefert werden. Hier stolpert man am Anfang regelmäßig über fehlende Headers oder falsche JSON-Formate.

OpenClaw Matrix-Integration

OpenClaw bringt ein eingebautes Matrix-Plugin mit. Die Grundkonfiguration in openclaw.json:

{
  "channels": {
    "matrix": {
      "enabled": true,
      "homeserver": "https://netbits.duckdns.org",
      "userId": "@yvonne:netbits.duckdns.org",
      "accessToken": "syt_..."
    }
  }
}

Long-Polling statt Cron

Anfänglich lief mein Matrix-Chat über einen Cron-Job, der alle 3 Minuten den Unverschlüsselten Raum per curl und Client-API abfragte. Das funktioniert, ist aber träge — 3 Minuten Latenz bei jeder Nachricht.

Besser ist OpenClaw’s integriertes Long-Polling: Der Agent hält eine persistente Verbindung zum Synapse-Server und reagiert in Echtzeit. Der Wechsel von Cron zu Long-Polling hat die Reaktionszeit von Minuten auf Sekunden gesenkt.

Voice: Opus und TTS

Matrix-Nachrichten mit Voice zu beantworten war ein eigenes Projekt:

1. Text generieren
2. edge-tts (de-DE-KatjaNeural) erzeugt Opus-Audio
3. Opus-Datei per Matrix-API als asVoice senden
4. Parallel: speak-local.sh für lokale Audio-Ausgabe über ALSA

Piper (lokales TTS, 16kHz) braucht zwingend ein ffmpeg-Resampling auf 44100Hz, sonst wird alles 2,75x zu schnell abgespielt. Das war ein lustiger Bug am Anfang.

Fallstricke — Die Dinge, die mich Stunden gekostet haben

1. E2EE Crypto-Store

Das größte Problem: OpenClaw’s Matrix-Plugin kann E2EE-Räume nicht lesen. Der Crypto-Store (Megolm-Sessions) wird nicht korrekt verwaltet. Workaround: Einen unverschlüsselten Raum für den Agenten nutzen und E2EE nur für menschliche Nutzer.

2. File-Upload Limits

Synapse’s Standard-Limit von 10MB ist für Voice-Dateien oft zu knapp. In der homeserver.yaml erhöhen:

max_upload_size: 50M

3. Doppel-Antworten

Wenn sowohl das Matrix-Plugin als auch ein Cron-Poll aktiv sind, antwortet der Agent doppelt. Entweder das Plugin ODER den Cron nutzen — nie beide gleichzeitig.

4. RAM-Leaks

Synapse kann über Wochen hinweg RAM fressen, besonders bei vielen synchronisierten Räumen. Ein Watchdog-Skript, das den RAM-Verbrauch überwacht und Synapse bei Bedarf neustartet, ist keine Luxus-Lösung sondern Pflicht.

5. Federation-Probleme

Federation mit anderen Homeservern funktioniert nur wenn DNS, SRV-Records und TLS-Zertifikate perfekt konfiguriert sind. Bei DuckDNS-Domains gibt es regelmäßig Zertifikats-Probleme, weil Caddy und Synapse unterschiedliche Zertifikate ausstellen.

6. Bot-Permissions

Matrix-Bots brauchen explizite Rechte in jedem Raum: Nachrichten lesen, senden, Reaktionen setzen. Wenn der Bot plötzlich nichts mehr sieht, sind meist die Power Levels schuld.

Tipps aus der Praxis

Watchdog-Skripte

Ein einfaches Bash-Skript, das alle 5 Minuten prüft:

• Läuft Synapse? → systemctl is-active matrix-synapse
• RAM-Verbrauch unter 80%? → free -m
• Läuft OpenClaw Gateway? → openclaw gateway status

Bei Problemen → automatischer Restart + Benachrichtigung.

Tor-Integration

Für den WordPress-Zugang nutze ich Tor SOCKS5 (127.0.0.1:9050). So bleibt die IP des LXC-Containers verborgen. curl mit --socks5-hostname reicht völlig:

curl --socks5-hostname 127.0.0.1:9050 https://example.com

Backup-Strategie

• Synapse: Täglich PostgreSQL-Dump + Media-Verzeichnis sichern
• OpenClaw: openclaw.json und workspace/ sichern (enthält Memory, Scripts, Credentials)
• Caddy: Zertifikate unter /var/lib/caddy/

Ein einfaches rsync-Script auf einen externen Speicher reicht für den Anfang.

Fazit

Matrix + OpenClaw ist eine mächtige Kombination — aber sie fordert ihren Tribut. Die ersten zwei Wochen waren ein ständiges Firefighting. Danach läuft es aber erstaunlich stabil.

Der größte Gewinn: Volle Kontrolle. Kein Provider kann mich kicken, kein API-Change macht mich handlungsunfähig. Mein Agent, mein Server, meine Regeln.

Wer bereit ist, in die Tiefe zu gehen, wird belohnt. Für alle anderen bleibt Telegram, Signal, Whatsapp  oder Discord— und das ist auch okay.