Построение моста между двумя Telegram-ботами в одном групповом чате: семантика доставки по HTTP

Соединить двух независимых Telegram-ботов в одном групповом чате сложнее, чем кажется. Разработчик на r/openclaw рассказывает о своем опыте создания промежуточного слоя, поскольку Telegram не гарантирует доставку сообщений от одного бота другому в группе — хотя люди видят оба сообщения.

Основная проблема

Telegram не передает обновления Боту B, когда Бот A отправляет сообщение в группу. Поэтому команда построила небольшой мост, обходящий ограничения Telegram:

• Бот B → Бот A: Бот B отправляет сообщение через HTTP-точку (шлюз) для связи с Ботом A.
• Бот A → Бот B: Бот A предоставляет выбранные исходящие сообщения через контролируемую ленту, которую опрашивает Бот B.
• Сообщения содержат метаданные: source, direction, chat ID, nonce и флаг safe_to_bridge.
• Подтверждения: Бот B может подтвердить получение конкретного сообщения, гарантируя, что хотя бы один переход сработал.
• Общая лента содержит только контекст группы, безопасный для моста — никаких личных сообщений или постороннего трафика.
• Локальный опросчик Бота B отсеивает старые, отладочные, протокольные и служебные сообщения, дедуплицирует события и пропускает только свежие реплики диалога.

Уроки первой версии

Первая реализация была слишком нестрогой: сырой контекст Telegram просачивался в общую ленту, вызывая недоумение: «Откуда другой бот это знает?» Исправление заключалось в переходе от сырых общих логов к явным событиям, безопасным для моста.

Текущее состояние работает в контролируемых тестах:

• Бот B → Бот A через ретранслятор
• Бот A → Бот B через ленту
• Подтверждения проходят через путь ретранслятора
• Безопасное автоматическое зеркалирование для сообщений, явно адресованных одному боту

Желаемый поток

Целевой цикл общения:

1. Человек или Бот A пишет сообщение, адресованное Боту B.
2. Мост безопасно зеркалирует его.
3. Бот B видит его один раз, отвечает один раз.
4. Ответ зеркалируется обратно, если это безопасно и уместно.
5. Без дубликатов, устаревших сообщений, утечек личных сообщений, отладочного эха или бесконечных циклов бота.

Направление архитектуры

Автор предлагает рассматривать мост как небольшую шину событий, а не как хак для чата:

• Строгие идентификаторы сообщений и nonce
• Подтверждения, дедупликация, контрольные точки
• Ограниченные ленты с жестким разделением между личным и общегрупповым контекстом

Самое сложное — семантика доставки: свежесть, дедупликация, подтверждения и решение, когда бот должен автоматически отвечать, чтобы не вызвать бесконечных циклов.