Zwei Telegram-Bots in einer Gruppe verbinden: Zustellungssemantik über HTTP

Zwei unabhängige Telegram-Bots im selben Gruppenchat zu verbinden, ist schwieriger, als es klingt. Ein Entwickler auf r/openclaw berichtet von seinen Erfahrungen beim Bau einer Brückenschicht, weil Telegram Nachrichten von einem Bot an einen anderen in einer Gruppe nicht zuverlässig zustellt – obwohl Menschen beide Nachrichten sehen können.

Das Kernproblem

Telegram liefert Bot B keine Updates, wenn Bot A eine Nachricht an die Gruppe sendet. Daher baute das Team eine kleine Brücke um die Einschränkungen von Telegram herum:

• Bot B → Bot A: Bot B postet über einen HTTP-Endpunkt (Tailgate), um Bot A zu erreichen.
• Bot A → Bot B: Bot A stellt ausgewählte ausgehende Nachrichten über einen kontrollierten Feed bereit, den Bot B abfragt.
• Nachrichten enthalten Metadaten: source, direction, chat ID, nonce und ein safe_to_bridge-Flag.
• ACKs: Bot B kann eine bestimmte Nachricht quittieren und bestätigen, dass mindestens ein Hop funktioniert hat.
• Der gemeinsame Feed enthält nur brückensicheren Gruppenkontext – keine privaten DMs oder irrelevanten Datenverkehr.
• Der lokale Poller von Bot B filtert alte/Debug/Protokoll/Status-Nachrichten heraus, dedupliziert Ereignisse und lässt nur frische Gesprächsbeiträge durch.

Lehren aus der ersten Version

Die erste Implementierung war zu locker: Roher Telegram-Kontext gelangte in den gemeinsamen Feed, was zu verwirrenden „Woher weiß der andere Bot das?“-Momenten führte. Die Lösung bestand darin, von rohen gemeinsamen Logs zu expliziten, nur brückensicheren Ereignissen überzugehen.

Der aktuelle Zustand funktioniert in kontrollierten Tests:

• Bot B → Bot A per Relay
• Bot A → Bot B per Feed
• ACKs fließen über den Relay-Pfad
• Sicheres automatisches Spiegeln für Nachrichten, die eindeutig an einen Bot gerichtet sind

Gewünschter Ablauf

Die angestrebte Gesprächsschleife:

1. Ein Mensch oder Bot A schreibt etwas, das an Bot B gerichtet ist.
2. Die Brücke spiegelt es sicher.
3. Bot B sieht es einmal und antwortet einmal.
4. Die Antwort wird zurückgespiegelt, wenn sie sicher und relevant ist.
5. Keine Duplikate, veraltete Rückstände, undichte private DMs, Debug-Echos oder Bot-Schleifen.

Architekturrichtung

Der Autor schlägt vor, die Brücke eher wie einen kleinen Ereignisbus zu behandeln, nicht wie einen Chat-Hack:

• Strenge Nachrichten-IDs und Nonces
• ACKs, Deduplizierung, Checkpointing
• Begrenzte Feeds mit harter Trennung von privatem und gruppensicherem Kontext

Das Schwierige sind die Zustellungssemantiken – Aktualität, Deduplizierung, ACKs und die Entscheidung, wann ein Bot automatisch antworten soll, ohne Endlosschleifen zu verursachen.