Scout
Docs
Browse Docs

Core Concepts

ArchitectureAgent IdentityCollaboration Workflows

OpenAgents Tracks

Track 01: Harness CatalogTrack 02: Collaboration ContractTrack 03: Shared ResourcesTrack 04: Capability-Aware Surfaces

Implementation

Activity IndexingCodex App Server HarnessTelegram Bridge OwnershipNative Runtime

Telegram Bridge Ownership

Singleton polling fix using mesh-elected bridge owner.

On This Page

ProblemNarrow DecisionWhy This SliceImplementationFollow-Up

Status: accepted and implemented

Problem

Telegram polling is singleton external I/O. When two OpenScout nodes poll the same bot token, Telegram terminates one poller with a getUpdates conflict. That creates a mesh bug where external comms can work once and then silently stop.

Narrow Decision

For Telegram only, OpenScout now uses a single bridge owner:

  • bridges.telegram.ownerNodeId
    • if set, only that node is allowed to poll Telegram
  • if unset, nodes derive the same owner automatically
    • choose the lexicographically smallest recently-seen node in the mesh
  • non-owner nodes stay enabled but enter standby
    • they do not poll Telegram
    • they still show status in the app

Why This Slice

  • fixes the real failure mode without inventing a full bridge-leasing protocol first
  • stays close to current Relay semantics
  • leaves room for a later first-class bridge lease/authority model

Implementation

  • canonical settings: packages/runtime/src/setup.ts
  • desktop settings UI: apps/desktop/src/web/app/components/communication-settings-view.tsx
  • desktop Telegram bridge owner election: apps/desktop/src/core/telegram/bindings.ts

Follow-Up

If this pattern holds, generalize it into a first-class mesh bridge authority mechanism for Telegram, webhooks, voice, and other singleton external transports.