2026 OpenClaw MeshMac in der Praxis: Matrix-Webhook auf Remote-Mac — minimal reproduzierbare Schritte für gemeinsamen Build-Status-Broadcast

Gateway-Installation und Token

Betreiben Sie das OpenClaw-Gateway auf einem Host mit stabiler Erreichbarkeit aus Richtung Homeserver und CI-Egress — nicht auf jedem einzelnen Build-Worker. Setzen Sie OPENCLAW_CONFIG_ROOT (oder Ihr Projekt-Äquivalent), mounten Sie Konfiguration nach Möglichkeit read-only und lagern Sie Matrix-Geheimnisse außerhalb von Git. Legen Sie einen dedizierten Bot-Benutzer an, treten Sie einmalig dem Team-Raum bei und speichern Sie das Zugriffstoken als Datei mit Rechten 0440 für den Gateway-Prozess; die Mac-Runner in der Queue bleiben tokenfrei und senden nur normierte Events an den Ingress. Nach jeder Rotation Gateway neu starten oder Konfiguration hot-reloaden, damit alle Knoten denselben Benachrichtigungs-Endpunkt verwenden und Beobachter keine widersprüchlichen Zeitstempel sehen.

• Homeserver-URL muss zum verifizierten TLS-Zertifikat passen; bei Self-Hosting Fingerabdruck oder Pinning dokumentieren.
• Raum-ID vollständig notieren (!xyz:domain), nicht nur den Alias.
• Korrelations-ID von CI über das Gateway in den Matrix-Text übernehmen, um Logs auf dem jeweiligen MeshMac-Knoten zuzuordnen.

Konfigurationsschritte: Matrix-Webhook und Anwendungsdienst (Appservice)

Für den schnellen Start genügt oft eine Bridge oder ein Webhook-Modul, das HTTP-POST in m.room.message übersetzt. Sobald Sie Ghost-User, mehrere Räume oder eingehende Synapse-Transaktionen brauchen, lohnt sich eine registrierte Appservice-yaml mit eindeutiger id, öffentlicher url Ihres Empfängers sowie den Paaren as_token und hs_token. Tragen Sie die Datei in app_service_config_files ein, laden Sie Synapse neu und testen Sie mit einem signierten Beispiel-POST. Halten Sie Staging und Produktion strikt getrennt (eigene URLs, eigene Tokens), damit Mehrknoten-Pools nicht aus Versehen denselben Raum mit Testdaten fluten.

1. HTTPS-Endpunkt z. B. /hooks/matrix/build-status hinter Reverse-Proxy und TLS veröffentlichen.
2. Registrierung im Integrationsmanager oder in der Homeserver-Konfiguration verweisen.
3. Namespaces und sender_localpart so wählen, dass Build-Bots klar erkennbar bleiben.
4. Synapse neu laden, mit curl vom Server aus den Empfänger prüfen, bis m.room.message im Raum erscheint.
5. Runbook: Im Thema oder Pin festhalten, dass jede Benachrichtigung mesh_node_id enthält — essenziell für Mehrknoten-Kollaboration.

Nachrichtensignatur oder Mindestrechte-Prüfung

Jeder ungeprüfte POST ist ein Einladungsbrief für gefälschte „grüne“ Builds. Bevorzugen Sie HMAC-SHA256 über die Roh-Bytes des Bodys mit gemeinsamem Geheimnis und konstantzeitigem Vergleich. Ergänzen Sie eine Zeitfenster-Prüfung (z. B. älter als fünf Minuten verwerfen), um Replays zu begrenzen. Wenn Ihr CI-Anbieter keine Signatur anbietet, kombinieren Sie ein langlebiges Bearer-Geheimnis mit einer Allowlist bekannter Egress-IPs — und dokumentieren Sie die Ausnahme im Threat-Model. Das Matrix-Token selbst sollte nur senden im einen Status-Raum dürfen, keine Einladungen oder Admin-Aktionen. Verifizierung und Geheimnisvergleich passieren ausschließlich auf dem Gateway, nicht auf jedem Mac im Pool; so bleibt die Angriffsfläche klein, während alle Knoten denselben validierten Pfad nutzen.

Mapping-Tabelle: CI-Statusfelder

Normalisieren Sie Provider-JSON einmal im Gateway, bevor Sie Markdown oder Klartext für Matrix rendern. Die Tabelle hilft, übergreifend dieselbe Lesart zu erzwingen — unabhängig davon, ob der Job auf Knoten A oder B gelaufen ist. Wenn ein Runner ausfällt und ein zweiter MeshMac die Pipeline übernimmt, bleibt die Semantik der Meldung identisch; nur mesh_node_id und ggf. die Run-URL ändern sich. So können sich Teams in Matrix auf „eine Wahrheit“ einigen, ohne Log-Aggregation oder externes Dashboard zu duplizieren. Achten Sie darauf, Zwischenzustände (z. B. „queued“) nur zu senden, wenn sie für Menschen wirklich Entscheidungswert haben — sonst wird der Raum laut, obwohl das Gateway technisch korrekt arbeitet.

FAQ: Keine Nachrichten — Fehlersuche

Gehen Sie diese Punkte durch, wenn die CI „grün“ meldet, der Raum aber still bleibt — besonders nach dem Hinzufügen eines zweiten MeshMac-Knotens. Prüfen Sie zuerst vom Homeserver aus (nicht nur vom Laptop), ob TLS und DNS zum Ingress stimmen; viele Pools blockieren ausgehenden Traffic von Synapse anders als von Entwickler-Workstations. Dokumentieren Sie für jede Eskalation Run-ID, mesh_node_id und Gateway-Revision, damit Postmortems zwischen Plattform- und Matrix-Teams nicht an fehlenden Korrelationen scheitern.

Weitere OpenClaw-Themen im OpenClaw-Themenhub.