IM Glossary

Console

The Console allows you to create new applications and manage existing ones to utilize RC's services such as instant messaging, push notifications, and real-time audio and video. From the Console, you can obtain the credentials (App Key and App Secret) for your application in either the production environment or the development environment.

App Key / Secret

The App Key / Secret serves as the account and password for your application on RC. The App Key is essential for the RC SDK to connect to the server. Note that applications created in the Console have both production and development environments, each with its own set of App Key / Secret.

Development Environment

A convenient environment for developers to integrate and test their applications. The user registration limit is 100, and it offers the same functionalities as the production environment. Data is isolated between the two environments to prevent conflicts between development and production data. Each environment provides an independent App Key / Secret. By default, applications created in the RC backend are set to the development environment.

Production Environment

The commercial environment where the app operates after going live. Data is isolated from the development environment to prevent conflicts. An independent App Key / Secret is provided. Ensure to switch from the development environment to the production environment before the official launch.

Target ID

The Target ID is used to identify a conversation, also known as the target ID or conversation ID, typically represented by the targetId parameter. The sender's ID is often denoted by senderUserId.

• For group chats, chatrooms, and ultra group chats, RC directly uses the group ID, chatroom ID, or ultra group ID to identify the conversation. Therefore, for all users participating in any group chat (or chatroom, ultra group chat), the Target ID is consistent.
• For one-to-one chats, RC uses the user ID of the other party as the Target ID for the local one-to-one conversation. Thus, for the two users participating in the same one-to-one chat, the Target ID of the conversation is inconsistent. For the local logged-in user, the Target ID of the local one-to-one chat is always the user ID of the other party. Due to the inconsistency of the Target ID in one-to-one chats among participants, misunderstandings may occur when inserting messages into a one-to-one chat using the "insert message" interface on the client side. Whether inserting a message sent by oneself or received by oneself, remember that the targetId field should be the Target ID of the one-to-one chat (the user ID of the other party).

For example, when user A sends a message to user B, the targetId and senderUserId in different conversation types are as follows:

Participant	Conversation Type	targetId	senderUserId
Sender (User A)	One-to-One Chat	User B	User A
	Group Chat	Group ID	User A
	Chatroom	Chatroom ID	User A
	Ultra Group	Ultra Group ID	User A
Receiver (User B)	One-to-One Chat	User A	User B
	Group Chat	Group ID	User B
	Chatroom	Chatroom ID	User B
	Ultra Group	Ultra Group ID	User B

Token

The Token is a user credential, serving as the identity token for the current user to connect to RC on the app. Each user needs a Token to connect to the server, and the Token must be changed when the user changes. The Token must be submitted to the server every time the connection is initialized.

One-to-One Chat

Refers to a one-to-one chat between two users, who can be friends or strangers. RC does not manage user relationships; the conversation relationship is established and maintained by RC. When the app is running in the background or the app process is killed, push notifications will be received for new messages.

Group

A group refers to a chat involving more than two users. Group member information is provided and maintained by the app. RC is only responsible for delivering messages to all group members. Push notifications can be received when the app is running in the background or the app process is killed. Each group can have a maximum of 3000 members, and there is no limit to the number of groups in the app.

Ultra Group

Ultra groups support the creation of independent channels. Message data (conversations, messages, unread counts) and group members are aggregated by channel. Ultra groups offer a new form of group business (distinct from regular groups or chatrooms), with no user limit, allowing users to build social relationships within ultra communities and focus on content of interest amidst a sea of information, helping developers create highly engaging communities.

Ultra group business optimizes message requests, storage, distribution, and push logic for different platforms and scenarios, leaving ample customization space for clients. Ultra group member information is provided and maintained by the app. Each user can join up to 100 ultra groups, and there is no limit to the number of ultra groups in the app.

Chatroom

Chatrooms have no user limit, with massive message concurrency and instant delivery. Users are considered to have left the chatroom once they exit the chat interface and will no longer receive any messages from the chatroom, with no push notification functionality. The conversation relationship is established and maintained by RC. Users can join or leave chatrooms via SDK interfaces.

System Conversation

A system conversation is a specific type of conversation where operators use predefined system accounts (non-user accounts, users cannot log in) to send system messages or broadcast messages to specified users or all users in the app via the server API. System messages are stored in system conversations, primarily for app operations. Upon receiving messages in a system conversation, users can only view them and cannot reply.

Channel

Independent conversation channels can be created within an ultra group conversation. Members of the same ultra group can freely send messages in different group channels, but messages between channels are isolated. One-to-one chats, group chats, and ultra group chats support the channel feature.

Conversation List

Refers to the list interface where various conversations are arranged in order, with each list item referred to as a conversation. The order depends on factors such as pinning and the time of the last message in the conversation. Chatroom-type conversations do not appear in the conversation list.

Chat UI

Refers to the interface for sending and displaying messages, supporting the display of message content and basic user information, including user names and avatars. It provides functionalities for sending text, emojis, voice messages, short videos, and audio/video calls, along with customizable input areas, input boxes, and message content display.

Push Notification

Push is a technical concept that refers to the real-time delivery of remote notifications from the server to the client.

iOS devices use Apple's APNs (Apple Push Notification service), while Android devices use Google's FCM (Firebase Cloud Messaging). In China, where Google services are unavailable, Android apps must integrate third-party push services. RC currently supports Xiaomi, Huawei, Honor, OPPO, Vivo, Meizu push services, and its own built-in push service.

Broadcast

Broadcast is a business concept that involves sending a message to all users in an app via the backend management interface or by calling server APIs. When users are offline, this message will automatically be converted into a push notification.

System Message

A system message is a business concept that refers to messages sent to users using a system account (non-user account, users cannot log in). These can be messages sent to everyone via the broadcast interface or single notification messages such as friend requests.

In the RC platform, there is no concept of system messages per se. Generally, system messages specifically refer to messages in conversations of the "SYSTEM" conversation type.

Offline Message

When the other user is offline, RC servers retain received messages for 7 days. If the other client comes online within 7 days, RC will directly send the messages to the client. If the other client does not come online within 7 days, RC servers will discard the expired messages. One-to-one chats and group chats support offline messages. Chatrooms do not support offline messages.

Refer to Technical Practice: IM Message Data Storage Structure Design for a detailed explanation of offline messages and historical messages.

Message Compensation

Refers to a compensation mechanism for messages when users switch devices or reinstall the app, allowing users to view messages sent and received on other terminals starting from midnight on the new device. This feature requires enabling Multi-Device Message Synchronization.

Custom Message

Message types and content structures created by developers based on business needs. Custom message types and structures must be consistent across platforms to avoid interoperability issues.

Message-bearing Notification

A Message-bearing Notification generates a RC system conversation message that reaches the user. Users receive the message instantly when online; when offline, RC will generate a remote push notification by default.

Push-only Notification

A Push-only Notification is essentially a remote notification method, appearing as a remote push notification on the client (only generating a notification, not a conversation message). Push-only Notifications are always delivered via the push channel, using RC's built-in push channel or third-party push channels already integrated by the client. iOS uses APNs (Apple Push Notification service), while Android uses the push service configured in the SDK by the developer, including RC's own push service, Xiaomi, Huawei, Meizu, OPPO, Vivo, and FCM.

Message Extension

Adds extended information to an already sent message. Extended information is stored in key-value pairs, with a maximum of 300 extensions per message.

Post-messaging Callback

Refers to the real-time synchronization of all messages sent by users in the app from the RC IM server to the customer's application server address. This feature allows for the storage of full message data on the application server.

Server Message Callback

Messages that meet custom conditions (sender, receiver, conversation type, message type) are called back to the developer's application server and not directly sent to the target user. The decision to deliver the message is based on the response from the application server. Suitable for scenarios where integration with self-hosted or third-party content moderation services is required.

Message Cloud Storage

Stores one-to-one, group, ultra group, and chatroom messages sent by users on the RC server, allowing users to retrieve historical messages after switching devices or deleting local messages. One-to-one and group messages are stored by default for 6 months, ultra group messages for 7 days, and chatroom messages for 2 months. You can extend the cloud storage duration for each message type in the Console.

User Online Status Update Callback

Real-time synchronization of the terminal user's connection status with the RC SDK to the developer's application server. For detailed information, refer to User Online Status Update Callback.

Currently, the following statuses are supported:

• Online: Indicates that the app is connected to the RC server.
• Offline: Indicates that the app has disconnected from the RC server.
• Logged Out: Indicates that the app has logged out.

Blocklist

In one-to-one chat scenarios, restricts the receipt of any messages from specified users by adding them to the blocklist.

Allowlist

The opposite of a blocklist, only users who are mutually on the allowlist can send messages to each other. Suitable for applications with strong friend relationships.

Banned User

Prohibits users from using RC IM services. During the ban period, users cannot connect to the RC IM server.

Navigation Domain

Used to obtain the long connection address for IM service access and basic configuration information required by the SDK. The SDK establishes a long connection with the IM server using the obtained address.

Application Identifier

The unique identifier of the application on the mobile device. For iOS, it is the Bundle Identifier, and for Android, it is the ApplicationId. Developers need to set this in the Console. Multiple application identifiers can be created under one App Key, and users under different application identifiers within the same App Key can send messages to each other.

Bundle Identifier

The application package name, which is the unique identifier of the application on the device. It must be set in the Application Identifier in the Console to use the iOS push service.

ApplicationId

Each Android app has a unique application ID (applicationId), similar to a Java package name, such as com.example.myapp. This ID serves as the unique identifier for your app on the device and in the Google Play Store.

The application ID is typically configured in the app's build.gradle file. If applicationId is not configured in build.gradle, it defaults to the app's package name. For more information on application IDs and package names, refer to the Android official documentation.

You need to set the application ID (applicationId) in the Application Identifier in the Console to use the Android push service.

IMLib

Refers to the IM basic communication capability library without a UI, encapsulating communication capabilities and objects such as conversations and messages. After being referenced in the application project, developers need to implement the UI themselves. It is relatively lightweight and suitable for developers with high UI customization requirements.

Global IM UIKit

Encapsulates the RC IM basic communication capability library at the UI layer, including the most complex components of instant messaging products such as conversation lists, chat windows, message content display, and conversation settings. These interfaces can be directly integrated into your app, saving significant development and debugging time. It also supports custom UI components, allowing for free design and development based on specific interface requirements.

Development Version

The SDK development version, primarily showcasing the latest features and functionalities. Versions are released periodically and can be used for feature exploration.

Stable Version

The SDK stable version, offering stable functionalities based on the development version, suitable for app releases.