An often-overlooked and perhaps under-appreciated feature, sending and receiving text-based messages is a critical piece of many WebRTC-based applications. Audio and video tend to steal the limelight, but the ability to exchange messages adds an extra layer of expressiveness and interactivity that is simple and reliable, even on old devices and slow networks.
In some apps, like Slack, text messaging is the primary feature, while audio and video communication take a secondary role. There are a variety of use cases for messaging, but most of them will fit into one of three categories — chat messages, system messages, or application messages.
The most common type of text message is a chat message. Chat messages originate from the users of your system and are typically delivered to either another user or a group of users in a conversational style.
These conversations can be:
1. Private, or invite-only, as is the case with iMessage.
2. Semi-private, where users in the same account can join or leave at will, as with Slack.
3. Public, where any user can join or leave, like IRC
Chat messages are typically persistent, in the sense that they need to be stored in an application database. This permanent storage is required to provide context when a user opens their app on a new device. Unless the most recent messages are displayed, it is difficult for a user to tell where they were in the conversation when they last left.
How messages are stored, and for how long, is largely an application-level decision. Some applications may want messages to be encrypted when stored for privacy reasons, whereas others might have a legal basis to avoid storage completely. Some applications may choose to retain all messages ever sent, while others might only retain a fixed number to control storage costs.
System messages bear much in common with chat messages, but unlike chat messages, they originate from the server or a bot. System messages could be as simple as a one-way welcome message sent to new clients joining a channel for the first time, or they could be as complex as a series of statistical reports for logging. Most of the time, system messages are simply notifications letting users know about some change of state in the application.
System messages can be:
1. Application-wide, targeting all users, as would be the case with a system downtime or maintenance notification.
2. Channel-wide, targeting users in a particular channel/ room/session, as would be the case with an end-of-session notification.
3. User-specific, as would be the case with a ban notification from an administrator.
4. Device-specific, as would be the case with a notification that a newer version of your client app is available in the device app store.
5. Client-specific, as would be the case with a kick notification sent to an app left idling in an active session.
6. Connection-specific, as would be the case with a mute or unmute notification sent to clients receiving media from the stream.
Application messages originate from users of your application but are not chat-based. For example, a simple shared whiteboard application could use the signaling system to send each stroke on the board as a message that includes the coordinates, color and stroke characteristics. An online chess platform might use application messages to send move information between participants.
Choosing how to send application messages is a bit of a gray area. They can easily be sent over the signaling engine in most cases, but in some cases, using WebRTC data channels would result in an improved user experience and/or more optimal use of server resources. For example, while sending player moves in a chess game over the signaling engine is quite practical, player moves in a real-time racing game are much more frequent and require lower latency for a good gameplay experience, and so data channels make more sense for that case.
Even the whiteboard example used above could benefit from the lower latency and streaming nature of data channels. Sending the stroke data piece by piece as it happens instead of as a single message after the stroke completes allows the receiving end to reconstruct the stroke piece by piece as well, changing the user experience entirely.
In this case, assuming we want to persist the whiteboard drawings, we could make use of both techniques. Data channels stream the stroke data “as it happens” for the live user experience, while signaling sends the completed stroke to the server to be stored for late-joining participants or historical viewing.
While there are different types of messaging for an array of applications, each one serves its own purpose. Chat messages and system messages depend on two parties respond back to one another (although they originate from different systems), and application messages require lower latency since there are more moving parts than simply two parties chatting back and forth. In all cases, WebRTC consistently improves the user experience through real-time streaming services offering a clear, fast connection.