Signal

Die Signal-Integration lässt Benutzer eine bidirektionale Konversation mit OctoMesh direkt aus dem Signal-Messenger führen: Sie senden Nachrichten (Fragen) und laden Dateien hoch (zum Beispiel Rechnungen) und erhalten Antworten im selben Chat zurück. Sie passt gut zu externen Partnern oder Lieferanten, die kein Microsoft Teams haben — Signal ist Ende-zu-Ende-verschlüsselt, mobile-first und benötigt kein Microsoft-/Google-Konto.

Sie basiert auf einer signal-cli-rest-api-Bridge (ein kleiner Docker-Dienst, der signal-cli umschließt und eine dedizierte, registrierte Signal-Nummer hält) und zwei Mesh-Adapter-Pipeline-Nodes:

Node	Art	Zweck
FromSignal@1	Trigger	Fragt die Bridge (GET /v1/receive/{number}) auf eingehende Nachrichten ab, lädt etwaige Anhang-Bytes (GET /v1/attachments/{id}) herunter und startet die Pipeline. Optionales SenderFilter wirkt als grobe Allow-List.
SignalSender@1	Load	Sendet eine Antwort (mit optionalem Anhang) über die Bridge zurück (POST /v2/send).

Keine offizielle Signal-Bot-API

Signal hat keine offizielle Bot-API. Die Bridge verwendet das Community-signal-cli, das eine dedizierte registrierte Telefonnummer benötigt und über Signal-Protokoll-Updates hinweg nicht garantiert stabil ist. Sie eignet sich gut für interne/mitarbeiterbezogene Kommunikation; wägen Sie sie für geschäftskritische Lieferanten-Abläufe ab.

Architektur

1. Der Benutzer schreibt an die Signal-Nummer der Bridge.
2. FromSignal@1 fragt die Bridge ab, nimmt neue Nachrichten auf und lädt Anhang-Bytes herunter.
3. Ihre Pipeline tut, was immer sie tun muss (Daten abfragen, einen KI-Prompt ausführen, eine hochgeladene Datei stagen …).
4. SignalSender@1 postet die Antwort über die Bridge zurück, die sie über Signal ausliefert.

Der Adapter erreicht die Bridge über einfaches HTTP (apiUrl), sodass es — anders als bei einem webhook-basierten Ansatz — keinen eingehenden HTTPS-Endpunkt zum Bereitstellen gibt und kein Problem mit selbstsignierten Zertifikaten zwischen der Bridge und dem Adapter.

Vereinheitlichte Nachrichtenform

FromSignal@1 übergibt der Pipeline einen Batch normalisierter Nachrichten unter $.Messages[]. Die Anhangsform spiegelt FromEmail@1 (AttachmentData), sodass dieselben nachgelagerten OCR-/Dokument-Import-Nodes anwendbar sind:

$.Messages[0].Message                    — the message text (may be empty for a photo)
$.Messages[0].Source                     — sender: phone number, or an ACI/PNI UUID (see below)
$.Messages[0].SourceName                 — sender profile name (e.g. "Gerry")
$.Messages[0].Attachments[0].Data        — base64 file content (image, PDF, …)
$.Messages[0].Attachments[0].ContentType
$.Messages[0].Attachments[0].FileName

Nicht-Nachrichten-Events (Zustellbestätigungen, Tippindikatoren, Sync-Nachrichten) tragen keine dataMessage und werden vom Trigger stillschweigend ignoriert.

Konfiguration

Beide Nodes nehmen die Bridge-URL und Kontonummer als einfache Node-Konfiguration — die lokale Bridge ist nicht authentifiziert, sodass es kein Secret und keine CK-Konfigurations-Entität zu verdrahten gibt (anders als bei Discord oder dem E-Mail-Sender). Die KI-/MCP-Nodes in der Pipeline behalten ihre üblichen Uses-Assoziationen zu AiConfiguration / ServiceAccountConfiguration.

Einstellung	Node	Bedeutung
apiUrl	beide	Bridge-Basis-URL, z. B. http://localhost:8080
number	beide	Das registrierte Konto der Bridge, z. B. +4366012345678
pollingIntervalSeconds	FromSignal@1	Abfrage-Takt (Standard 5). /v1/receive konsumiert Nachrichten beim Lesen, sodass keine Deduplizierung nötig ist.
senderFilter	FromSignal@1	Optionale Contains-Match-Allow-List auf den Absender
recipient / recipientPath, message / messagePath	SignalSender@1	Antwortziel und -text

Vollständige Eigenschaftslisten finden sich in der API Reference → Adapters → MeshNodes → Trigger → FromSignalNodeConfiguration und → Load → SignalSenderNodeConfiguration (generiert aus den Node-Konfigurationsklassen).

Absender-Identität & Telefonnummern-Datenschutz

FromSignal@1 bevorzugt die Telefonnummer (sourceNumber) als Source, sodass eine Antwort und jede gespeicherte Provenienz menschenlesbar und beantwortbar sind. Signals Telefonnummern-Datenschutzmodell bedeutet jedoch, dass die Nummer nur geteilt wird, wenn der Absender es erlaubt — andernfalls trägt der Umschlag nur eine ACI/PNI-UUID plus den Profilnamen des Absenders (SourceName). Sowohl die Nummer als auch die UUID sind gültige Empfänger für SignalSender@1, sodass Antworten in beiden Fällen funktionieren; nur der angezeigte Bezeichner unterscheidet sich.

Provenienz

Wenn eine Pipeline ein eingehendes Dokument als UploadedDocument staget, setzen Sie:

• SourceChannel = SIGNAL (der Enum-Wert DocumentSource) und
• SourceSender = $.full.msgSource (der auf Nachrichtenebene erfasste Absender — siehe Einrichtung).

Zusammen bilden diese eine beantwortbare Herkunft, sodass eine spätere Rückfrage den Absender wieder auf Signal erreichen kann, falls ein Dokument nicht verarbeitet werden kann.

Fahren Sie mit der Schritt-für-Schritt-Einrichtung fort.