[RFC] Phase 4 — IM adapter framework (Feishu / DingTalk / Telegram / WeChat)

[GoDiao]

Background

With Phase 3 (H5 Remote Access) shipped, the next big piece on the roadmap is Phase 4 — IM Adapters: let users chat with their DreamCoder desktop session through Feishu, DingTalk, Telegram, or WeChat.

A skeleton already exists under AdapterSettings, but the real work is:

• defining a stable adapter contract (auth, message I/O, rich-card rendering, permission approval flows)
• mapping bi-directional messages to / from the desktop session
• handling pairing securely (so an adapter can't impersonate the user)
• platform-specific quirks (callback URLs, attachment APIs, audit logging)

This RFC issue is the place to discuss the design before anyone writes a full adapter PR. We want to land the framework once, then accept per-platform PRs from the community.

Goals

1. Single adapter interface — implementers fill in 5–6 methods, not a whole stack
2. Pairing UX consistent with the H5 Phase 3 token model (QR + rotating token)
3. Permission approval flows degrade gracefully into IM card / button UI
4. Persistent IM ↔ session mapping so a user gets the same context across reboots
5. Adequate test surface — adapters should be testable without hitting real platforms

Open questions

• Adapter contract: typed Adapter interface vs. event bus vs. RPC?
• Where does the adapter run — inside the desktop process, in the sidecar, or as a separate worker?
• How do we handle long-poll vs. webhook platforms uniformly?
• Attachment / file upload — store in the local cache directory, or stream?
• Audit logging: per-adapter, or unified?
• Multi-account: one user, multiple IM identities — how do we render that in the UI?

Proposed work breakdown (subject to RFC outcome)

1. Framework PR — adapter interface + lifecycle + pairing token
2. Telegram adapter — easiest to test (open API)
3. Feishu adapter — most-requested by Chinese users
4. DingTalk adapter
5. WeChat adapter — last; most platform-specific friction

Each platform PR is scoped to one adapter and must come with mocked tests.

How to contribute to this RFC

• Comment with concrete proposals or pushback on any of the open questions
• Link prior art if you've built bots for the same platforms
• Volunteer for one of the adapter slots — we'll add you to the planning doc

Mentor: @GoDiao