winada-dsh-telegram-bridge

Readme

# winada-dsh-telegram-bridge

A [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) profile bundle that ships a Telegram ↔ DSH bridge as a one-call install tool. Once the bundle is mounted, the model gains an `install_telegram_bridge` tool that registers and starts the bridge in the current session.

## What the bridge does

- Long-polls the Telegram Bot API and routes incoming chat messages to a DSH sub-agent.
- Sends the agent's reply back to the originating chat.
- Adds a live status indicator (typing action + editable "⏳ Processing…" message with elapsed time).
- Adds a `/model` command with an interactive inline-keyboard provider/model picker (callback_query-driven).
- Adds `/new` (fresh conversation), `/reset` (clear context), `/status` (bridge health), and registers the lot with Telegram via `setMyCommands` so the client shows them in the `/` suggestion menu.
- Persists a diagnostics file at `.tg-bridge-diag.json` in the host's writable cwd so you can inspect cycles, errors, and the resolved sandbox policy from outside the process.

## Install

```sh
# from inside the DSH profile you want to use:
dsh plugin add github:winada/dsh-telegram-bridge
```

(`pnpm add github:winada/dsh-telegram-bridge` from the profile directory also works.) After the install completes and the host is restarted (or the bundle is picked up by reload), the `install_telegram_bridge` tool is registered.

## Configure

You need a Telegram bot token from [@BotFather](https://t.me/BotFather) and at least one allowed chat id (your own Telegram chat id, which you can find with [@userinfobot](https://t.me/userinfobot)).

In any DSH session, ask the model:

> Install the Telegram bridge. My bot token is `<digits>:<secret>` and my chat id is `5805491987`.

The model will call `install_telegram_bridge { bot_token, allowed_chat_ids: [5805491987] }`. The tool returns the new Plugin id (`tgram-<n>`) and Package id, and the bridge starts polling immediately.

To re-install with a new token or different allowlist, ask the model to run `install_telegram_bridge` again — it appends a fresh Package and switches the active version via `cordis_run update`.

## Requirements

The bridge uses `pwsh Invoke-WebRequest` as its HTTPS transport and routes every subprocess call through `ctx.sandboxPolicy.resolve({ session })`. The deployment default sandbox policy is `workspace-write`, which **blocks TLS to `api.telegram.org`** (the subprocess fails with "The SSL connection could not be established ... inner=Authentication failed"). The bridge therefore requires the resolved session policy to be `danger-full-access` (or equivalent) for its subprocesses.

The install tool does not check this — it succeeds under any mode. If polling times out, check `/status` (the bot's bridge status reply) and your profile's `cordis.patch.yml` for the relevant `sandbox-policy` row.

## Known limitations

- The transport uses one `pwsh` process per Telegram HTTP call; the cadence is about one cycle every 3-6 seconds plus occasional stalls up to 30 seconds on poor networks. Acceptable for personal bots, not for high-throughput fan-out.
- The dynamic Plugin lives in process memory — it disappears when DSH restarts. After a restart, ask the model to call `install_telegram_bridge` again, or extend your profile boot to call it automatically.
- Per-chat model overrides are kept in process memory only.
- The bot's conversation history per chat is capped at 12 turns.

## License

MIT.