Skip to content

tg-agent-cli as a projection store for call-baxter

tg-agent-cli can stay a standalone browse/index tool even when call-baxter is the component that receives Telegram updates.

That means:

  • call-baxter
  • webhook ingress
  • getUpdates poller
  • generic rule matching
  • generic action execution
  • tg-agent-cli
  • projection database schema
  • update normalization into chats/messages/callbacks/media/reactions
  • browse-first CLI over that projection

Interop seam

The seam is intentionally small and library-shaped:

  • tg_agent_cli.cb_bridge.build_cb_events(update)
  • tg_agent_cli.cb_bridge.persist_update_to_projection(...)
  • tg_agent_cli.cb_bridge.projection_max_update_id(...)

So the Telegram plugin inside call-baxter can:

  1. normalize raw updates into call-baxter events
  2. persist selected updates into the Telegram projection DB
  3. derive incremental poll offsets from the Telegram projection DB

without needing a Telegram-specific daemon to be resident.

Practical flow

Telegram webhook -> call-baxter ingress -> normalized telegram.* events
                       -> rule telegram.persist_update -> tg projection db

tg --database-url ./tg-state.db messages list --chat-ref chat:-100...

Why this split is useful

  • operator browsing stays Telegram-specific and rich
  • callback/runtime orchestration stays generic
  • the Telegram projection DB can grow independently of the generic call-baxter event log
  • call-baxter only pays the projection cost when a rule chooses to persist the update