​

Channel Recipes

​

Start Here

​

Pick The Right Recipe

​

Surface Map

​

Shared Readiness Loop

loong doctor
loong channels

​

Reading Rule

• Use this page when you already know the delivery lane and want concrete config or smoke tests.
• Use Channel Guides when you need the exact built-in contract for one surface.
• Use Configuration Patterns when you want the shared default_account, accounts.<id>, and trust-toggle shape before the per-surface walkthroughs.
• Start with one surface only; do not jump to multi-channel supervision first.
• Keep Feishu / Lark, Telegram, Matrix, WhatsApp, and WeCom in the runtime-backed lane.
• Keep webhook, email, Slack, Discord, Teams, Google Chat, Mattermost, Nextcloud Talk, Synology Chat, LINE, DingTalk, Signal, IRC, iMessage / BlueBubbles, Nostr, Tlon, and similar sinks in the outbound-only lane.
• Jump to Common Setups when the provider and channel should be chosen together.

​

Need A Full Rollout Instead?

​

Recipe 1: Feishu / Lark Inbound Runtime

[feishu]
enabled = true
domain = "lark"
mode = "webhook"
receive_id_type = "chat_id"
webhook_bind = "127.0.0.1:8080"
webhook_path = "/feishu/events"
app_id = { env = "LARK_APP_ID" }
app_secret = { env = "LARK_APP_SECRET" }
verification_token = { env = "LARK_VERIFICATION_TOKEN" }
encrypt_key = { env = "LARK_ENCRYPT_KEY" }
allowed_chat_ids = ["oc_ops_room"]

[feishu]
enabled = true
domain = "lark"
mode = "websocket"
app_id = { env = "LARK_APP_ID" }
app_secret = { env = "LARK_APP_SECRET" }
allowed_chat_ids = ["oc_ops_room"]

loong feishu-send --receive-id "ou_example_user" --text "hello from loong"
loong feishu-serve

• the team already lives in Feishu or Lark
• you need a shipped inbound runtime rather than outbound notifications only
• reply-loop behavior matters more than a generic webhook sink

• domain = "lark" selects the Lark base URL, while domain = "feishu" keeps the Feishu lane.
• webhook mode requires verification_token and encrypt_key
• websocket mode should not be documented as if webhook-only secrets were mandatory
• allowed_chat_ids remains the conversation trust boundary in both modes

​

Recipe 2: Telegram Reply-Loop Bot

[telegram]
enabled = true
bot_token = { env = "TELEGRAM_BOT_TOKEN" }
allowed_chat_ids = [123456789]

loong telegram-send --target "123456789" --text "hello from loong"
loong telegram-serve

• one bot token should own the lane
• chat ids are easy to review and allowlist
• you want the shortest path from local assistant to live reply loop

• allowed_chat_ids is the trust boundary, not just a convenience list
• if you later need several bot identities, move to default_account plus accounts.<id> instead of replacing one token repeatedly

​

Recipe 3: Matrix Room Sync Bot

[matrix]
enabled = true
base_url = "https://matrix.example.org"
access_token = { env = "MATRIX_ACCESS_TOKEN" }
user_id = "@loongbot:example.org"
allowed_room_ids = ["!ops:example.org"]

loong matrix-send --target "!ops:example.org" --text "hello matrix"
loong matrix-serve --once

• you need a self-hosted or federated room lane
• the homeserver boundary is part of the runtime truth
• you want to verify the sync loop once before running it long-lived

• base_url should point at the homeserver URL, not a random Matrix web client URL
• user_id helps self-message filtering when that matters for the room topology

​

Recipe 4: WeCom Official AIBot Runtime

[wecom]
enabled = true
bot_id = { env = "WECOM_BOT_ID" }
secret = { env = "WECOM_SECRET" }
ping_interval_s = 45
reconnect_interval_s = 12
allowed_conversation_ids = ["group_demo"]

loong wecom-send --target "group_demo" --text "hello wecom"
loong wecom-serve

• the deployment is already standardized on WeCom
• the official long-connection transport is the desired runtime contract
• proactive sends and reply-loop service should share the same account identity

• the official websocket URL is used by default; override websocket_url only for controlled environments or bridge setups
• ping_interval_s and reconnect_interval_s are the right knobs when the network path needs tuning
• keep the docs language aligned with the shipped long-connection contract
• do not describe a webhook callback mode as if it were the same supported path

​

Recipe 5: Multi-Account Feishu / Lark Or WeCom

[feishu]
enabled = true
mode = "websocket"
default_account = "work"
receive_id_type = "chat_id"

[feishu.accounts.work]
domain = "lark"
app_id = { env = "LARK_WORK_APP_ID" }
app_secret = { env = "LARK_WORK_APP_SECRET" }
allowed_chat_ids = ["oc_ops_room"]

[feishu.accounts.backup]
domain = "feishu"
app_id = { env = "FEISHU_BACKUP_APP_ID" }
app_secret = { env = "FEISHU_BACKUP_APP_SECRET" }
allowed_chat_ids = ["oc_backup_room"]

[wecom]
enabled = true
default_account = "work"
ping_interval_s = 45
reconnect_interval_s = 12

[wecom.accounts.work]
bot_id = { env = "WECOM_WORK_BOT_ID" }
secret = { env = "WECOM_WORK_SECRET" }
allowed_conversation_ids = ["group_work"]

[wecom.accounts.alerts]
bot_id = { env = "WECOM_ALERTS_BOT_ID" }
secret = { env = "WECOM_ALERTS_SECRET" }
allowed_conversation_ids = ["group_alerts"]

• one config should hold prod, backup, or environment-specific accounts
• gateway or multi-channel supervision should target stable account ids
• you want top-level defaults plus account-level overrides instead of duplicating everything

• set default_account explicitly so the default lane is not accidental
• keep shared settings at the top level and override only the account-specific secrets or allowlists
• channel-account selectors can target those configured ids directly, for example lark=work or wecom=alerts

​

Recipe 6: Outbound-Only Delivery Families

[webhook]
enabled = true
endpoint_url = { env = "WEBHOOK_ENDPOINT_URL" }
auth_token = { env = "WEBHOOK_AUTH_TOKEN" }
payload_format = "json_text"
payload_text_field = "text"

loong webhook-send --text "deployment finished"
loong webhook-send --target "https://example.test/override" --text "one-off delivery"

[email]
enabled = true
smtp_host = "smtp.example.com"
smtp_username = { env = "EMAIL_SMTP_USERNAME" }
smtp_password = { env = "EMAIL_SMTP_PASSWORD" }
from_address = "loong@example.com"

loong email-send --target "ops@example.com" --text $'Release complete\nEverything is green.'

[dingtalk]
enabled = true
webhook_url = { env = "DINGTALK_WEBHOOK_URL" }
secret = { env = "DINGTALK_SECRET" }

loong dingtalk-send --text "robot delivery is healthy"

• you need delivery now, but not a reply-loop runtime
• the target system is a webhook, SMTP relay, or other outbound sink
• the surface should remain truthful as outbound-only in public docs

[slack]
enabled = true
default_account = "ops"

[slack.accounts.ops]
bot_token = { env = "SLACK_OPS_BOT_TOKEN" }

[slack.accounts.release]
bot_token = { env = "SLACK_RELEASE_BOT_TOKEN" }

• HTTP-backed outbound delivery blocks private or special-use hosts by default
• if you intentionally target a private bridge or loopback endpoint, widen that boundary explicitly:

[outbound_http]
allow_private_hosts = true

​

Recipe 7: One Host, Multiple Runtime-Backed Channels

loong multi-channel-serve \
  --session cli-supervisor \
  --channel-account lark=work \
  --channel-account wecom=alerts \
  --channel-account telegram=bot_123456 \
  --channel-account matrix=bridge-sync

loong gateway run \
  --session daemon-gateway \
  --channel-account lark=work \
  --channel-account wecom=work \
  --channel-account telegram=bot_123456
loong gateway status

• one machine should supervise several shipped runtime-backed surfaces
• account ownership needs to stay explicit per channel
• you want longer-lived service ownership instead of one-off shell sessions

• this lane is for runtime-backed service channels only
• lark= is the accepted alias for the Feishu channel family, and feishu= works too
• selectors should reference configured account ids such as work, alerts, or bot_123456
• outbound-only surfaces such as webhook, email, Slack, Discord, or Teams should not be described as if they join the same reply-loop supervisor
• when you need the ownership and inspection model without the recipe framing, switch to Gateway And Supervision

​

Channel Rollout Order

1. Get loong ask or loong chat healthy first.
2. Add one runtime-backed service channel or one outbound-only surface.
3. Verify with loong doctor and loong channels.
4. Only then graduate to gateway run or multi-channel-serve.

​

Continue Reading