Construyendo un puente para dos bots de Telegram en un grupo de chat: Semántica de entrega sobre HTTP

Conectar dos bots independientes de Telegram en el mismo chat grupal es más difícil de lo que parece. Un desarrollador en r/openclaw detalla su experiencia construyendo una capa de puente porque Telegram no entrega de manera confiable los mensajes de un bot a otro en un grupo, aunque los humanos puedan ver ambos mensajes.

El problema central

Telegram no envía actualizaciones al Bot B cuando el Bot A envía un mensaje al grupo. Por lo tanto, el equipo construyó un pequeño puente alrededor de las limitaciones de Telegram:

• Bot B → Bot A: El Bot B publica a través de un endpoint HTTP (tailgate) para llegar al Bot A.
• Bot A → Bot B: El Bot A expone mensajes salientes seleccionados a través de un feed controlado que el Bot B consulta periódicamente.
• Los mensajes llevan metadatos: source, direction, chat ID, nonce y una bandera safe_to_bridge.
• ACKs: El Bot B puede confirmar un mensaje específico, asegurando que al menos un salto funcionó.
• El feed compartido solo contiene contexto de grupo seguro para el puente, sin DMs privados ni tráfico no relacionado.
• El poller local del Bot B filtra mensajes antiguos, de depuración, de protocolo o de estado, deduplica eventos y solo deja pasar los turnos conversacionales frescos.

Lecciones de la primera versión

La implementación inicial era demasiado permisiva: el contexto sin procesar de Telegram se filtraba al feed compartido, causando momentos confusos de "¿cómo supo el otro bot eso?". La solución fue pasar de registros compartidos sin procesar a eventos explícitos y seguros para el puente.

El estado actual funciona en pruebas controladas:

• Bot B → Bot A mediante retransmisión
• Bot A → Bot B mediante feed
• Los ACKs fluyen a través de la ruta de retransmisión
• Auto-mirror seguro para mensajes claramente dirigidos a un bot

Flujo deseado

El bucle de conversación objetivo:

1. Un humano o el Bot A escribe algo dirigido al Bot B.
2. El puente lo refleja de manera segura.
3. El Bot B lo ve una vez, responde una vez.
4. La respuesta se refleja de vuelta si es segura y relevante.
5. Sin duplicados, acumulación obsoleta, fuga de DMs privados, eco de depuración o bucle de bots.

Dirección de arquitectura

El autor sugiere tratar el puente como un pequeño bus de eventos en lugar de un hack de chat:

• IDs de mensaje estrictos y nonces
• ACKs, deduplicación, puntos de control
• Feeds con alcance delimitado y separación estricta entre contexto privado y seguro para el grupo

La parte difícil son las semánticas de entrega: frescura, deduplicación, ACKs y decidir cuándo un bot debe responder automáticamente sin causar bucles infinitos.