OpenClaw: configure production Telegram group, bot, webhook, and room policy

[mfethe1]

Parent

#10

Type

HITL - Telegram bot/group creation and Railway secrets require operator-controlled credentials.

What to build

Configure the production Telegram intake path for the Railway controller: create the private Telegram supergroup, add the bot, set Railway controller secrets, run the bootstrap utility against the controller messaging DB, and register the Telegram webhook with the secret header.

Acceptance criteria

• A private Telegram supergroup exists for OpenClaw operators. Use a supergroup, not a broadcast channel, because command promotion depends on Telegram sender identity.
• The Telegram bot is added to the group with permissions sufficient to receive messages.
• Railway openclaw-controller has OPENCLAW_TELEGRAM_BOT_TOKEN configured without leaking the value.
• Railway openclaw-controller has OPENCLAW_TELEGRAM_SECRET_TOKEN configured without leaking the value.
• The Telegram bootstrap utility has been run against $RAILWAY_VOLUME_MOUNT_PATH/openclaw/messaging.db with the controller signing secret.
• Telegram setWebhook points to https://openclaw-controller-production.up.railway.app/adapters/telegram/webhook and uses the configured secret token.
• Invalid webhook secret requests are rejected.
• A synthetic valid webhook request creates or returns a canonical OpenClaw message without duplicating records.
• Controller /ready remains true after Telegram configuration.

Blocked by

• OpenClaw: secure canonical Railway NATS broker for Telegram control plane #11
• OpenClaw: cut Rosie and Lenny over to canonical broker and prove Railway fleet visibility #12
• OpenClaw: add idempotent Telegram controller bootstrap utility #13

Sandcastle notes

Do not run secret configuration through Sandcastle. If any code/docs gaps appear while doing this, create a separate AFK issue and run that in Sandcastle.

[mfethe1]

Current production status after Railway/host cutover:

Ready:

• openclaw-controller is deployed and /ready is healthy.
• OPENCLAW_TELEGRAM_SECRET_TOKEN is staged on the controller.
• POST /adapters/telegram/webhook rejects requests without the Telegram secret header with HTTP 403.
• /fleet shows both lenny and rosie healthy on the authenticated Railway broker.
• scripts/bootstrap_openclaw_telegram.py exists and can bootstrap the controller-side Telegram adapter, room mapping, route policy, and trusted operator identity once the Telegram IDs are available.

Still blocked on human/operator inputs:

• OPENCLAW_TELEGRAM_BOT_TOKEN is not set on openclaw-controller.
• Need the private Telegram supergroup chat ID.
• Need each trusted operator Telegram user ID and the intended OpenClaw identity ID/display name.
• Need the bot added to the private supergroup before webhook registration.

Once those are available, run the bootstrap against /data/openclaw/messaging.db, set the bot token on Railway, call Telegram setWebhook for https://openclaw-controller-production.up.railway.app/adapters/telegram/webhook using the staged secret token, then run the live routing checks from #15.

[mfethe1]

Progress update:

• OPENCLAW_TELEGRAM_BOT_TOKEN is now staged on openclaw-controller and the controller was redeployed successfully.
• Telegram getMe validates the bot as JimFetheBot.
• OPENCLAW_TELEGRAM_SECRET_TOKEN is already staged.
• Webhook is intentionally not registered yet because the controller has no Telegram room mapping or trusted operator identity rows. Registering before bootstrap would cause incoming Telegram updates to fail with no mapped OpenClaw room.
• Telegram reports can_read_all_group_messages = false, so BotFather privacy is still enabled. That must be disabled for unmentioned shared-channel work.

Next operator action:

1. In BotFather, run /setprivacy, choose JimFetheBot, and select Disable.
2. Add @JimFetheBot to the private operator supergroup.
3. Send one normal message in the group from each operator who should be trusted.

After that, we can use getUpdates to discover the private supergroup chat ID and operator Telegram user IDs, run scripts/bootstrap_openclaw_telegram.py, then register the webhook.

[mfethe1]

Live Telegram verification after forum/thread enablement:

• Telegram webhook is configured to the Railway controller and reports 0 pending updates with no current webhook error.
• Controller persisted the latest operator message as a Telegram chat message with body content present.
• The message is marked as pending Claimable Work.
• The latest persisted update did not include a Telegram thread/topic id, so this specific message appears to have arrived in the main chat rather than a topic thread.
• No command ref or delivery rows were created for the normal unmentioned message. Current deployed behavior still requires either an explicit routed command/alias or a host-side Task Claim caller.
• Outbound Telegram replies are still not complete in the deployed runtime: render_outbound payload shaping exists, but there is no controller sender worker/API route that drains Telegram adapter delivery rows and sends Bot API messages.

Conclusion: inbound Telegram visibility is working; automatic response/Telegram reply is not complete yet.