一つのグループチャット内で二つのTelegramボットを橋渡しする：HTTP上の配信セマンティクス

同じグループチャットで2つの独立したTelegramボットを接続するのは、思ったより難しい。ある開発者がr/openclawで、Telegramがグループ内で一方のボットからもう一方のボットへのメッセージを確実に配信しないため——人間は両方のメッセージを見られるにもかかわらず——ブリッジ層を構築した経験を詳しく説明している。

核心の問題

Telegramは、ボットAがグループにメッセージを送信しても、ボットBに更新を配信しない。そこでチームは、Telegramの制限を回避する小さなブリッジを構築した：

• ボットB → ボットA： ボットBはHTTPエンドポイント（テールゲート）を介して投稿し、ボットAに到達する。
• ボットA → ボットB： ボットAは、ボットBがポーリングする制御されたフィードを通じて、選択された送信メッセージを公開する。
• メッセージにはメタデータが含まれる： source、direction、chat ID、nonce、およびsafe_to_bridgeフラグ。
• ACK： ボットBは特定のメッセージにACKを返し、少なくとも1ホップが機能したことを確認できる。
• 共有フィードには、ブリッジセーフなグループコンテキストのみが含まれる——プライベートDMや無関係なトラフィックは含まれない。
• ボットBのローカルポーラーは、古いメッセージやデバッグメッセージ、プロトコルメッセージ、ステータスメッセージをフィルタリングし、イベントの重複を排除し、新しい会話のターンのみを通過させる。

最初のバージョンからの教訓

最初の実装はあまりにも緩すぎた：生のTelegramコンテキストが共有フィードに漏れ出し、「なぜあのボットがそれを知っているのか？」という混乱を招いた。修正方法は、生の共有ログから明示的なブリッジセーフイベントのみに移行することだった。

現在の状態は制御されたテストで機能している：

• リレー経由でボットB → ボットA
• フィード経由でボットA → ボットB
• ACKはリレーパスを通じて流れる
• 一方のボットに明確に宛てられたメッセージの安全な自動ミラーリング

目標のフロー

目標とする会話ループ：

1. 人間またはボットAが、ボットBに宛てたメッセージを書き込む。
2. ブリッジがそれを安全にミラーリングする。
3. ボットBがそれを一度見て、一度返信する。
4. 安全かつ関連性があれば、返信がミラーリングされる。
5. 重複、古いバックログ、プライベートDMの漏洩、デバッグエコー、ボットループがない。

アーキテクチャの方向性

著者は、ブリッジをチャットのハックではなく、小さなイベントバスのように扱うことを提案している：

• 厳格なメッセージIDとノンス
• ACK、重複排除、チェックポイント
• プライベートとグループセーフコンテキストを厳密に分離したスコープ付きフィード

難しいのは配信セマンティクス——新鮮さ、重複排除、ACK、そして無限ループを起こさずにボットが自動応答すべきタイミングの判断——である。