Channel
Understand how a Channel represents a message target and organizes direct chat, group chat, membership, and history.
A Channel is the message “address” or “room.” Every message belongs to one Channel, which determines where the message goes, who may receive it, and the scope in which messages remain ordered.
The combination of channel_id and channel_type identifies a Channel. The same ID under another type is a different Channel.
Why Channels matter
- Select a target: Sending to a person or a group is fundamentally selecting a Channel.
- Organize participants: Channel type and membership together determine who may send and receive.
- Hold continuous history: Each Channel numbers, orders, and recovers its ordinary persistent messages without mixing unrelated chats.
- Reuse communication primitives: Notifications, support, live interaction, communities, and Agents can also build on Channels.
Relationship to other concepts
- Sending a Message identifies a target Channel; ordinary persistent message order is scoped to that Channel.
- A User participates in direct, group, or other communication through Channels.
- A Device is only an endpoint through which a user accesses a Channel; it does not change Channel identity.
- A Conversation is one user's entry to a Channel. The same Channel has user-specific unread and visibility state.
The two most common Channel types
| Scenario | Choosing the Channel ID | Who owns participation |
|---|---|---|
| Direct chat | Use the other user's UID when sending | The product system owns contact, stranger, and other send policy |
| Group chat | Use a stable group ID from the product system | The product system creates the group and synchronizes members, deny/allow lists, and related state to WuKongIM |
When Alice sends directly to Bob, Alice uses Bob's UID as the target. Bob uses Alice's UID when replying. WuKongIM normalizes those two viewpoints to one internal direct-chat history; applications do not construct that internal Channel ID.
WuKongIM also defines specialized types for communities, feeds, live interaction, visitors, and Agents. Use one only when the server, selected SDK, and complete product flow support it. See Channel Types for the current values.
A Channel is not the same as a product group
A group chat often shares a group ID with its Channel, but the responsibilities differ:
| Product system owns | WuKongIM owns |
|---|---|
| Group name, avatar, announcement, and roles | Channel identity, message routing, and per-Channel order |
| Who may create, join, invite, or leave | Membership and Channel policy synchronized by trusted services |
| Content rules, tenant isolation, and moderation | Message persistence, realtime delivery, and offline recovery |
After creating a product group, a trusted backend must still synchronize membership and policy with WuKongIM. Knowing a Channel ID alone does not grant permission to join or send.
Remember when building
- Store
channel_id + channel_typeas the complete Channel key, never the ID alone. - For direct chat, send to the peer UID; do not write the server's normalized internal identity back as a product contact ID.
- Channel Type is not authorization. The product system still owns membership, roles, and content policy.
- For 100,000-member groups, use bounded membership updates and paged delivery work as described in the Large Groups tutorial.
Continue with User and Conversation. For replicas, commit, and migration, read the Channel Messaging Layer.