Alex headshot

AlBlue’s Blog

Macs, Modularity and More

Real-time Text for Jabber

2011

Here's something that might be interesting to those who remember talk (and friends such as ytalk and ntalk); the Real-time Text for Jabber, also known as XEP-0301.

These days, chat systems work by sending a block of text at a time, usually when the person on the other end presses the Enter key. In Google Talk, you sometimes get a notification when someone has started typing; but you don't see anything until they've concluded with what they were trying to say.

Although this lacks immediacy, previous systems had the capability to show people's text as they were typing. These were usually inefficient, sending a network packet for each character pressed – but realistically no more different to a modern remote SSH terminal onto a remote host, which does the same thing.

What seeing someone type does is gives you an idea of a conversation flowing, much like a spoken conversation would. You can interrupt someone (to say that you've heard it, and they needn't spend time going in detail) or ask them to expand on the point that they're making.

The real-time Jabber extension to XMPP has been published as XEP-0301, which means any Jabber client could implement it if it wanted. The way Jabber extensions work is that any Jabber client has a list of supported extensions that it knows about, and if two clients both support it then they are free to use it. This permits (for example) clients to agree on what features they support and so to send real time data (or not). Needless to say, it is also backward compatible and will send a full body after the message has been sent, so in group chats (for example) those clients that can support the real time text can display it, whilst those that don't will simply see the final message.

If the protocol was merely batching up changes and firing them out periodically, then you'd see characters turn up in batches. That wouldn't look natural, and it wouldn't solve the problem of trying to get a conversation to evolve either. Instead, the real time text protocol includes timing information for the characters typed, so that the client on the remote end may receive a single packet of data but then drip feed the characters to the screen at an appropriate rate.

To get an idea of how this looks in practice, take a look at the real-time text demo at the creator's website. This shows the same conversation, shown as it is at the moment (with messages appearing en masse as they are finished), one where the characters are merely batched and flushed each second, and one where the characters are drip fed out. (The example uses an animated GIF to show how it would look, and is fairly effective at getting the point across.)

The status of the real-time text protocol is marked as “Experimental” so it may be a while before it is picked up by other major players such as Google and Apple. However, the XMPP protocol used means that Google Talk could be used to act as the intermediary for two supporting clients. It will be interesting to see if Google is interested in using this for Google Talk on the Web, or whether it is an idea in waiting for the future.