openclaw - 💡(How to fix) Fix [Feature]: Channel Broker consolidation program for maintained chat channels

Summary

Create a phased Channel Broker program so OpenClaw can consolidate maintained chat-channel behavior behind one provider-facing broker contract while keeping OpenClaw core responsible for message/session semantics.

Problem to solve

OpenClaw currently carries too much maintainer burden across native channel plugins. Telegram, Discord, Slack, WhatsApp, Signal, iMessage, Matrix, and the long tail repeatedly regress around streaming, verbose/tool output, receipts, routing, retries, and platform-specific delivery edge cases. Every platform-specific fix increases cross-channel regression risk.

Proposed solution

Adopt Channel Broker as the stable seam:

• OpenClaw owns sessions, allowlists, routing, model-run lifecycle, /verbose, /reasoning, streaming policy, durable final sends, receipts, retries, and auditability.
• Provider plugins/services own platform mechanics and expose capabilities through openclaw/plugin-sdk/channel-broker.
• Migrations proceed phase-by-phase with issue-first PRs, real behavior proof, and no default user-visible behavior changes until each channel has conformance coverage.

Rollout issues

• Phase 1 foundation: #86107
• Phase 2 major-channel proof: #86108
• Phase 2A conformance harness: #86109
• Phase 2B Telegram proof: #86110
• Phase 2C Discord proof: #86111
• Phase 2D Slack proof: #86112
• Phase 3 official app/API channels: #86113
• Phase 4 constrained/device-bound channels: #86114
• Phase 5 legacy freeze: #86115

Impact

Affected systems: all chat channels and future external channel providers.

Severity: high maintainer-load and regression-risk reducer.

Frequency: recurring channel regressions, especially streaming/verbose and routing behavior.

Consequence today: maintainers repeatedly patch platform-specific code instead of enforcing one broker contract.

Evidence/examples

• Foundation PR: #86096
• Existing channel issues and PRs show recurring Telegram/Discord/Slack/WhatsApp/Signal/iMessage/Matrix churn.

Acceptance criteria

• Each phase has a linked issue before implementation PRs are opened.
• Phase PRs include real behavior proof where behavior changes.
• Channel migration PRs keep native defaults unchanged until proof and conformance are present.
• Legacy channel plugins are frozen only after broker migration paths exist.