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

OpenClaw Workspace Structure and Self-Improvement Approach from Longtime User
A longtime OpenClaw user shares their workspace structure with key markdown files like SOUL.md, AGENTS.md, and MEMORY.md, plus the critical lesson that allowing the agent to improve its own environment dramatically increases effectiveness.

Anthropic releases free official learning platform for Claude AI
Anthropic has launched a free learning platform with structured courses covering Claude basics, API integration, agent skills, and specialized tracks for different user groups.

Qwen 3.5 122B MoE at 35 t/s on a Single 3090 with ik_llama.cpp MTP
A local stack running Qwen 3.5 122B MoE on a single 3090 at 35 t/s using ik_llama.cpp's fused MoE ops for MTP. Stock llama.cpp showed only +4% improvement; ik's fork yields +20%.

Claude Code Workflow Visual: Memory Hierarchy, Skills, Hooks, and Loop
A Reddit post shares a workflow visual for Claude Code covering CLAUDE.md memory layering (global → repo → scoped), skills as reusable patterns in .claude/skills/, and a suggested workflow loop (plan → describe → accept → commit).