Channels
Use this page when the base CLI path already works and you need to choose the right delivery surface story before diving into commands or config fields. The base CLI path still comes first. A user should be able to succeed withask or chat before enabling service channels.
If you want the exact per-surface setup contract instead of the conceptual
surface map, go directly to
Channel Guides. Keep
Channel Recipes for representative rollout
paths, smoke tests, and multi-channel sequencing.
If you already know the provider and channel together, skip the narrower recipe
pass and go to Common Setups plus the dedicated
playbook that matches the rollout shape.
If you specifically need the owner model behind gateway run, continue to
Gateway And Supervision.
Canonical Channel CLI Story
Public docs now prioritize grouped shells over flat verbs:- generic channel actions:
loong channels send <surface> ... - generic channel serve loops:
loong channels serve <surface> ... - richer family namespaces stay first-class when they expose more than thin wrappers, but those richer payload workflows should stay on the dedicated family namespace instead of widening the canonical grouped contract
Already Know The Rollout Shape?
If the provider and channel are already obvious, skip this concept page and go straight to the matching playbook.| If you already know you want… | Go here |
|---|---|
| Volcengine plus Feishu or Lark | Volcengine Plus Feishu Or Lark |
| Volcengine plus WeCom | WeCom Rollout |
| BytePlus Coding plus Telegram | BytePlus Coding Plus Telegram |
| a local model plus outbound delivery | Local Model Plus Outbound Delivery |
| several runtime-backed channels on one host | Gateway Rollout |
Fast Path By Situation
| If you need… | Start with… | Why |
|---|---|---|
| Feishu or Lark should own a live team-chat runtime | Feishu/Lark | it is the most feature-rich managed-bridge-capable service channel today |
| Telegram is enough for the live reply loop | Telegram | it is the smallest managed-bridge-capable service setup path |
| Matrix should own a self-hosted or federated room runtime | Matrix | homeserver and room trust boundaries stay explicit on a managed-bridge-capable service lane |
| WhatsApp Cloud API should own a business-account reply loop | WhatsApp Cloud API | direct sends and the webhook reply loop are both shipped on a managed-bridge-capable service lane |
| WeCom should own the official enterprise AIBot lane | WeCom | it aligns with the shipped managed-bridge-capable long-connection contract |
| WeChat or personal WhatsApp ecosystems should route through an external bridge | Weixin, OneBot, or WhatsApp Personal | plugin-backed surfaces keep bridge ownership explicit instead of pretending a native runtime exists |
| QQ should own a native official gateway runtime | QQ Bot | Loong owns the runtime directly through channels serve qqbot or gateway run |
| one LINE or generic inbound webhook lane should run a built-in serve loop without gateway supervision | LINE or Webhook | standalone native-serve surfaces are real runtimes, but their owner is still the direct channels serve <surface> loop |
| outbound notifications without a reply loop | Channel Guides and Channel Setup | outbound-only surfaces stay visible without being overclaimed as runtimes |
| one host supervising several runtime-backed channels | Gateway And Supervision | owner commands, selectors, and rollout order live there |
Reading Rule
- Use this page to choose the delivery-surface lane.
- Use Channel Guides when one surface is already decided and you need the exact built-in contract.
- Use Channel Recipes when you need commands, smoke tests, or concrete config.
- Use Common Setups when provider and channel choice belong together.
- Use Gateway And Supervision when the real question is ownership, selectors, or long-lived supervision.
Choose The Right Surface Story
| Layer | What it means | Current examples |
|---|---|---|
| Base assistant loop | local operator-first path | onboard, ask, chat, doctor |
| Gateway owner contract | daemon-owned runtime control for longer-lived surfaces | gateway run, gateway status, gateway stop |
| Gateway-supervised service channels | Loong-runnable service lanes that can join gateway run; some still keep implementation_status=plugin_backed in the catalog because their setup and transport contracts preserve managed-bridge capability | Feishu / Lark, Telegram, Matrix, QQ Bot, WhatsApp Cloud API, WeCom |
| Standalone native-serve channels | Loong-runnable send plus serve lanes whose runtime still stays on their own channels serve <surface> loop; some still keep managed-bridge-capable catalog metadata | LINE, Webhook |
| External plugin-backed bridge surfaces | shipped channel contracts whose upstream session lifecycle stays in an external bridge or managed plugin | Weixin, OneBot, WhatsApp Personal |
| Config-backed outbound surfaces | shipped direct-send surfaces without a full reply-loop runtime | Discord, Slack, DingTalk, Email, Teams, Google Chat, Signal, Twitch, and similar outbound integrations |
| Catalog or planned surfaces | inventory or future direction only | Zalo, Zalo Personal, WebChat |
Gateway And Runtime Ownership
gateway run,gateway status, andgateway stopare the current explicit owner contract for longer-lived delivery surfaces.- LINE and Webhook have native serve commands, but they are still standalone native-serve lanes rather than gateway-supervised ones.
- Loong does not flatten gateway ownership, standalone native serves, plugin-backed bridge surfaces, and outbound-only sends into one vague “channel support” story.
- Use Gateway And Supervision when you need the command-by-command ownership model, selector syntax, and rollout order in one place.
Gateway-Supervised Service Channels
These are the service lanes that can currently joingateway run at the operator/runtime layer. Some still keep implementation_status=plugin_backed in the catalog because their setup and transport contracts preserve managed-bridge-capable or externally bridged history.
| Surface | Transport shape | Primary commands |
|---|---|---|
| Feishu / Lark | webhook or websocket | loong channels send feishu, loong channels serve feishu |
| Telegram | Bot API polling | loong channels send telegram, loong channels serve telegram |
| Matrix | Client-Server sync loop | loong channels send matrix, loong channels serve matrix |
| QQ Bot | official QQ gateway runtime | loong channels send qqbot, loong channels serve qqbot |
| WhatsApp Cloud API | Cloud API plus verified webhook service | loong channels send whatsapp, loong channels serve whatsapp |
| WeCom | official AIBot long connection | loong channels send wecom, loong channels serve wecom |
Standalone Native-Serve Channels
These are Loong-runnable send plus serve lanes, but their runtime owner is still the individualchannels serve <surface> loop instead of gateway supervision. Their catalog metadata may still preserve managed-bridge-capable setup truth even though the current operator/runtime grouping is standalone.
| Surface | Transport shape | Primary commands |
|---|---|---|
| LINE | Messaging API push plus signed webhook reply loop | loong channels send line, loong channels serve line |
| Webhook | outbound POST plus signed inbound webhook service | loong channels send webhook, loong channels serve webhook |
External Plugin-Backed Bridge Surfaces
These are already operator-visible channel contracts, but they stay honest about runtime ownership.| Surface | Current transport story | Primary operator surfaces |
|---|---|---|
| Weixin | ClawBot / iLink-style bridge | loong doctor, loong channels, managed bridge discovery |
| OneBot | OneBot v11 bridge ecosystem | loong doctor, loong channels, managed bridge discovery |
| WhatsApp Personal | QR-linked Baileys bridge | loong whatsapp-personal bridge run, loong doctor, loong channels |
Outbound Surface Families
These surfaces ship direct sends, config validation, and inventory metadata without claiming a full reply-loop runtime. This page keeps the concept layer short on purpose; the fuller field-level inventory remains in Channel Setup.| Surface family | Current examples | Typical command shape |
|---|---|---|
| workplace chat sinks | Slack, Discord, Microsoft Teams, Google Chat, Mattermost, Nextcloud Talk, Synology Chat | loong channels send <surface> |
| messaging and bridge targets | DingTalk, Signal, IRC, iMessage / BlueBubbles, Nostr, Tlon | loong channels send <surface> |
| direct delivery and alerting lanes | Email, Twitch | loong channels send <surface> |
Public Documentation Rule
Loong tries to keep the public channel story truthful:- the gateway contract is documented as the runtime owner contract
- shipped gateway-supervised surfaces are documented as gateway-supervised
- shipped standalone native-serve surfaces are documented as native serve lanes without overclaiming gateway supervision
- shipped plugin-backed surfaces are documented as bridge-owned rather than pretending the gateway already owns their listener lifecycle
- outbound-only surfaces are documented as outbound-only
- catalog entries are not overclaimed as runtime support
Typical Progression
- Get the local assistant path healthy first.
- Add one gateway-supervised service channel if you need the shortest path into
gateway run. - Use a standalone native-serve channel when you need a real built-in
channels serve <surface>loop but do not need gateway supervision yet. - Reach for a plugin-backed bridge surface when the ecosystem is real but Loong intentionally delegates login and listener ownership to an external bridge.
- Use outbound-only surfaces when you need governed direct sends without pretending they are full runtime surfaces.
- Reach for
gateway runwhen you want multiple gateway-supervised service channels attached to the same CLI host.
Where To Go Next
- Continue to Channel Guides for the full actionable channel matrix.
- Continue to Channel Recipes for representative gateway-supervised, standalone native-serve, and outbound rollout examples.
- Continue to Channel Setup for the practical public setup guide.
- Continue to Gateway And Supervision for the longer-lived owner contract and channel-account selection rules.
- For the broader public runtime contract, continue to Use Loong.
- The full field-level source spec still lives in the repository’s public Channel Setup markdown.