Message-related Features
Related paths and models
- Admin API path:
/messages. For specific API details, please refer to the OpenAPI documentation - Client interface: Please refer to the
MessageServiceControllerclass - The underlying request model: please refer to the interface description file in the
https://github.com/turms-im/proto/tree/master/request/messagedirectory - Configuration class:
im.turms.server.common.infra.property.env.service.business.message.MessageProperties
function list
Message function | Function description | Related configuration |
|---|---|---|
| Offline Messages | Implementation ideas: You can actively request the Turms server for specific offline messages of all private chats and group chats received when the user is offline every time the Turms client logs in. Quantity, and the specific data of the last N messages (default is 1)>, so as to take into account both the real-time nature of the message and the performance of the service. By default, the Turms server does not regularly delete any offline messages stored on the Turms server | turms.service.message.default-available-messages-number-with-total |
| Roaming Messages | ✍When a new device logs in, the developer calls the message query interface of the Turms client, specifies the number and time period, and requests roaming messages from the Turms server. The implementation of roaming messages is essentially the same as that of "historical messages" (✍Reason: Turms cannot judge what is "new device login") | |
| Multi-terminal synchronization | When a user has multiple clients online at the same time, the Turms server will send the message to all the online clients of the user | |
| Historical Messages | Support querying user's historical messages. By default, Turms permanently stores messages (including user messages or system messages) The implementation of historical messages is essentially the same as that of "roaming messages" | turms.service.message.message-retention-period-hours turms. service.message.expired-messages-cleanup-cron |
| Send Message | turms.service.message.time-type turms.service.message.persist-message turms.service.message.persist-record turms.service.message. persist-pre-message-id turms.service.message.persist-sender-ip turms.service.message.check-if-target-active-and-not-deleted turms .service.message.max-text-limit turms.service.message.max-records-size-bytes turms.service.message.allow-send-messages-to-oneself turms.service.message.allow-send-messages-to-stranger turms.service.message.delete-message-logically-by-default turms.service.message.send-message-to- other-sender-online-devices turms.service.message.use-conversation-id turms.service.message.sequence-id.use-sequence-id-for-group-conversation >turms.service.message.sequence-id.use-sequence-id-for-private-conversation | |
| Message Recall | Withdraw a message that has been successfully delivered. By default, the sender is allowed to withdraw the message within 5 minutes of the successful delivery time | turms.service.message.allow-recall-message turms.service.message.available-recall- duration-seconds |
| Message Editing | Edit a successfully sent message | turms.service.message.allow-edit-message-by-sender |
| Burn after reading | After the recipient receives the sender's message, the recipient's client will automatically destroy it on time according to the time preset (or default) by the sender | |
| Read Receipt | ✍Notify the private chat object or group members that the current user has read a message Check the read/unread status of the other party in the private chat and group conversation (✍reason : Turms cannot know under what circumstances your user has "read a certain message". The developer needs to call turmsClient.messageService.readMessage() to inform the other party that the current user has read a certain message) | turms.service. conversation.read-receipt.enabled allow-move-read-date-forward turms.service.conversation.read-receipt.update-read-date-after-message-sent turms .service.conversation.read-receipt.update-read-date-when-user-querying-message turms.service.conversation.read-receipt.use-server-time |
| Message Forwarding | Forwarding a message to another user or group | |
| @someone | is used to specifically remind a user. If the Turms client detects that the user @ in the received message is currently logged in, the Turms client will trigger the @ callback function. Developers can implement subsequent related business logic by themselves. It is often used to remind users who are @. There is no essential difference between the @ message in the group and the ordinary message, only that when the @ message is received, special processing is required (triggering a callback function) | |
| Typing | ✍When a party in a communication is typing text, inform the recipient (user or users) that the user is typing the message (✍Reason: Turms has no way of knowing whether your users are typing text) | turms.service.conversation.typing-status.enabled |
Precautions when querying session messages
By default, Turms does not support "In a private chat session, the message sender can query the messages he sent himself" (specific reason: Message Index Design. Note: In a group chat session, the message sender can always query his own messages.) Developers can pass in turms-service Configure turms.service.message.use-conversation-id=true in the configuration file of the server to enable conversation ID.
Afterwards, the semantics of turmsClient.messageService.queryMessages({areGroupMessages: false, fromIds: [10,11,12]}) will be replaced by the original "query messages sent by users whose IDs are 11, 12, and 13 in a private chat session. "Messages to the current user" becomes "query the messages sent by the users whose user IDs are 11, 12 and 13 to the current user, and the messages sent by the current user to users whose user IDs are 11, 12 and 13 in the private chat session ".
Business message type
From a developer's point of view, the Turms client has and only uses one data model when sending messages, namely CreateMessageRequest. Since it has fields of type string and List<byte[]>, you can actually pass any kind of data when sending a message. It's just that in order to facilitate developers to quickly implement various business message types, the Turms client divides common message types to facilitate developers to get started quickly.
Reminder: Turms messages (messages of all business types) can be marked as system messages. However, system messages can only be sent through the turms admin API, and the Turms client cannot send system messages.
Business message type | Description |
|---|---|
| Text message | The content of the message is text Reminder: Text can also be JSON, encoded as Base64 binary data |
| Image message | The content of the message is the description part (optional): image URL address, size, image size Image data (optional) |
| Voice message | The content of the message is the description part (optional): URL address, duration, size, format of the voice file Voice data (optional) |
| Video message | The content of the message is the description part (optional): URL address, duration, size, format of the video file Video data (optional) |
| File message | The content of the message is the description part (optional): URL address, size, format of the file File data (optional) |
| Geographic location message | The content of the message is geographic location title, address, longitude and latitude information |
| Combined message | The content of the message is text information and any number of other messages of any content type (for example: a message contains both text, pictures and audio) |
| Custom message | Turms only uses one data structure during transmission, and it can carry string and List<byte[]> data structures. Therefore, developers are free to implement any custom message types, such as messages in the form of red envelope messages, rock-paper-scissors, etc. |
Implementation of binary data transmission
There are two main implementation schemes for the transmission of binary data (files):
| Use the Turms client to send the records field of the message API (not recommended) | Use object storage services (AWS S3, Alibaba Cloud OSS, etc.) | |
|---|---|---|
| Introduction | By default, Turms supports the transmission and storage of binary data records attached to messages, so you can store binary data such as pictures, videos, files, etc. in records | Your application client (Note: here "client "It is not the client of Turms, but the client of your IM application) to request the OSS operation permission Token from your service server program, and the client will take this Token to find the OSS service and upload the file to OSS, and then take it from OSS The returned file URL is passed to the Turms server, and Turms saves the URL text instead of the binary data of the file. Because the Turms plug-in supports developers to implement file management services by themselves, you can also implement this function by implementing a plug-in. For example, the integrated implementation turms-plugin-minio of the MinIO object storage server officially provided by Turms is implemented based on the Turms plugin, for your reference |
| Advantages | Simple implementation | Unlimited capacity; Support CDN acceleration, optimize user experience; Support UI visual management, and provide various operation and maintenance management functions. Cloud storage services generally support practical features such as redundant storage, server-side encryption, and hierarchical storage of hot and cold data (which greatly reduces data storage costs) |
| Disadvantage | A Turms client has and only establishes one TCP connection with the server, so if the user uses the records field that comes with the Turms client to transfer a large file, it will block the data transmission of other business requests;When MongoDB queries message data, it will load the entire message record into the memory, which greatly slows down the message query speed |
Reference: Storage Service