zeroclaw-labs/zeroclaw

[Feature]: recover WeCom AI Bot WebSocket channel as separate wecom_ws support

Closed

#6201 opened on Apr 29, 2026

View on GitHub
 (0 comments) (0 reactions) (1 assignee)Rust (31,341 stars) (4,614 forks)batch import
channelchannel:wecomenhancementhelp wantedpriority:p2risk: mediumstatus:acceptedstatus:no-stale

Description

Summary

Recover the WeCom / WxWork AI Bot WebSocket long-connection channel work from #3305 as a separate wecom_ws channel, distinct from both the existing WeCom Bot Webhook channel and the WeChat personal iLink Bot channel.

Problem statement

ZeroClaw now has partial WeCom support:

  • #3439 added wecom, the WeCom Bot Webhook channel. This is useful for outbound/send-only bot webhook delivery.
  • #3090 originally requested both webhook mode and WebSocket mode.
  • #3305 implemented a larger WeCom AI Bot WebSocket long-connection path as wecom_ws, but that PR was closed unmerged.
  • #6130 is recovering the WeChat personal iLink Bot channel from #4221. That is a different platform shape and should not be expanded to cover WeCom WebSocket support.

The remaining gap is native WeCom AI Bot WebSocket mode for inbound chat handling and active-session delivery.

Proposed solution

Port or reimplement the useful parts of #3305 against current master as a focused wecom_ws channel.

The recovered scope should include, if still appropriate:

  • optional wecom_ws channel/config identity, separate from webhook-based wecom
  • WebSocket long-connection runtime
  • inbound chat handling
  • progressive/streaming reply behavior
  • allowlists for users/groups
  • attachment download/decrypt handling
  • proactive send support through the active connected channel session
  • docs explaining the distinction between wecom webhook mode and wecom_ws AI Bot WebSocket mode

Non-goals / out of scope

  • Do not fold this into the personal WeChat/iLink Bot recovery in #6130.
  • Do not replace the existing wecom Bot Webhook channel from #3439.
  • Do not redesign channel routing beyond what is needed for WeCom WebSocket support.

Alternatives considered

Keep #3090 as the only tracker. That works, but a separate issue is clearer because #3090 now covers both an already-landed webhook path and a remaining WebSocket path.

Acceptance criteria

  • wecom webhook support remains unchanged.
  • A distinct wecom_ws channel can receive inbound WeCom AI Bot WebSocket messages.
  • The channel can send replies through the active WebSocket session.
  • Access control is documented and covered by tests.
  • Docs clearly distinguish WeCom Bot Webhook, WeCom AI Bot WebSocket, and WeChat personal iLink Bot.

Architecture impact

crates/zeroclaw-channels/, crates/zeroclaw-config/, channel orchestrator wiring, docs, and possibly scheduler/proactive delivery plumbing.

Risk and rollback

Medium. This adds a new optional enterprise channel with WebSocket traffic, credentials/secrets, attachment handling, and active-session delivery behavior. Rollback should be removing/disabling [channels.wecom_ws] or reverting the feature PR.

Breaking change?

No

Data hygiene checks

  • I removed personal/sensitive data from examples, payloads, and logs.
  • I used neutral, project-focused wording and placeholders.

Contributor guide