Building a Bridge for Two Telegram Bots in One Group Chat: Delivery Semantics Over HTTP

Connecting two independent Telegram bots in the same group chat is harder than it sounds. A developer on r/openclaw details their experience building a bridge layer because Telegram does not reliably deliver messages from one bot to another in a group — even though humans can see both messages.
The Core Problem
Telegram does not deliver updates to Bot B when Bot A sends a message to the group. So the team built a small bridge around Telegram's limitations:
- Bot B → Bot A: Bot B posts through an HTTP endpoint (tailgate) to reach Bot A.
- Bot A → Bot B: Bot A exposes selected outbound messages through a controlled feed that Bot B polls.
- Messages carry metadata:
source,direction,chat ID,nonce, and asafe_to_bridgeflag. - ACKs: Bot B can ACK a specific message, confirming at least one hop worked.
- The shared feed only contains bridge-safe group context — no private DMs or unrelated traffic.
- Bot B's local poller filters out old/debug/protocol/status messages, deduplicates events, and only lets fresh conversational turns through.
Lessons from the First Version
The initial implementation was too loose: raw Telegram context leaked into the shared feed, causing confusing "how did the other bot know that?" moments. The fix was to move from raw shared logs to explicit bridge-safe events only.
Current state works in controlled tests:
- Bot B → Bot A via relay
- Bot A → Bot B via feed
- ACKs flow through the relay path
- Safe auto-mirror for messages clearly addressed to one bot
Desired Flow
The target conversation loop:
- Human or Bot A writes something addressed to Bot B.
- Bridge mirrors it safely.
- Bot B sees it once, replies once.
- Reply is mirrored back if safe and relevant.
- No duplicates, stale backlog, private DM leak, debug echo, or bot loop.
Architecture Direction
The author suggests treating the bridge like a small event bus rather than a chat hack:
- Strict message IDs and nonces
- ACKs, deduplication, checkpointing
- Scoped feeds with hard separation between private and group-safe context
The hard part is delivery semantics — freshness, dedupe, ACKs, and deciding when a bot should auto-respond without causing infinite loops.
📖 Read the full source: r/openclaw
👀 See Also

Analysis of Claude Code's Production Engineering Patterns from Reverse-Engineered Source
A developer reverse-engineered approximately 500,000 lines of Claude Code's TypeScript source code into a 19-chapter technical handbook documenting production engineering patterns that emerge under real load, real money, and real adversaries.

Qwen3.x models fail silently in OpenClaw due to streaming output format mismatch
Qwen3.x models in streaming mode output to the 'reasoning' field instead of 'content', causing OpenClaw to silently fall through to fallback models. A proxy that translates API formats and injects 'think: false' fixes the issue, enabling full tool-call evaluation.

Claude Code LSP Setup Guide: Structural Code Understanding
A Reddit post details how to configure Claude Code to use Language Server Protocol for structural code understanding instead of text matching, reducing query times from 30-60 seconds to ~50ms with go-to-definition, find-references, and call hierarchy features.

Automating OAuth Token Refresh for Bots Using Claude Code
A Reddit user shares a method to prevent OAuth token expiration by configuring Claude Code to automatically refresh tokens every 8 hours, keeping bots running continuously without manual intervention.