Posted
by
timothy
on Thursday July 07, 2011 @04:36PM
from the no-room-for-oopses dept.

mdrejhon writes "Geeks who miss the UNIX 'talk' days, have a new modern savior: XMPP.org has published the new XEP-0301 Real-Time Text standard, which allows streaming text that is continuously transmitted as it is typed or otherwise composed. It allows conversational use of text, where people interactively converse with each other."

After 2 years of russian spam, I finally logged out of my 6 digit account for good. As much as I used to love ICQ it just went down and down and downhill after they sold out until finally no one used it but fucking bots and idiots like me.

It is a feature that is very friendly to the deaf, as the spec even mentions deaf people in the introduction of the specification document.http://xmpp.org/extensions/xep-0301.html [xmpp.org] "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times

Understandable, but real-time text can be turned on/off.Some users like, it and some don't. AIM has an enable/disable feature for Real-Time IM.It can be an optional feature, like optional audio or video in their IM chats.I'm a deafie, and it's beneficial to use from time to time.

As Jabber wraps each message in a bunch of XML and for federated systems sends it to the other system much like one would send an email via SMTP, this would obviously wrap each letter typed in a bunch of XML, and send each letter as an individual message.

Actually, the spec does a compromise to transmit only 1 packet per second, even if there's 10 key presses per second.It buffers the key presses for a full second, even including the original intervals between the key presses.Then it transmits XML for the whole sequence, all at once.

This avoids overloading the network with too many messages per second, while keeping it sufficiently real-time, in a balanced compromise. (Yes, I know, it's "inefficient" XML, but XMPP.org encourages ease of programming over ban

It wouldn't be difficult for Google to add it to Google Talk (unobtrusively, turned off by default)...

It works on Google Talk's network already via third party software. Thus, no XMPP server modifications needed.

An example is RealJabber experimental demo chat software whose source code I posted at http://realjabber.googlecode.com/ [googlecode.com]... I tested XEP-0301 real-time over google's XMPP severs (gmail.com / talk.L.google.com)... Google was able to handle up to more than 10 XMPP messages per second very easily, b

Oh -- and Google does not capture all messages.There's lots of hidden XMPP message transmissions that goes on for other things, and Google does not log those.

XEP-0301 is intentionally designed to be backwards compatible, so you can safely transmit real-time text to any XMPP chat software, and it just ignores the real-time text part. It just displays only the finished (completed) messages. Though section 5 of the XEP-0301 spec recommends that you detect whether the remote end supports the real-time text,

It wasn't new in 1981 either. You just thought it was at the time. Every generation thinks that their ideas are original, that the next generation rips them off and they lack the knack for innovation. Ask your parents, they'll tell you the same thing about your generation.

Wrapped in a large XML turd and not even following XML philosophy at that, randomly introducing one character tags. How is this protocol really helping anything?

<t p='#'>text</t> Insert specified text at position p in message. <e p='#' n='#'/> Deletes n characters of text to the left of position p in message. <d p='#' n='#'/> Deletes n characters of text to the right of position p in message.

I know.:-)One thing though, that isn't HTML, it's XML over XMPP. We used a binary code at first for XEP-0301, until I realized XMPP encouraged XML. Our task group chose one-letter XML elements, to save some bandwidth. Key press interval elements ended up being the best way to transmit real-time text, at only 1 packet per second (protecting the network), while fully preserving key-press delays, so that typing comes out naturally, thanks to the delay elements:http://xmpp.org/extensions/xep-0301.html#key_press_intervals [xmpp.org]

This is a protocol optimized for assistive use for the deaf, too; and it can be turned on/off. (i.e. real time text is optional) This really, is an unobtrusive add-on that can be off by default (much like AIM's existing real time text feature is off by default)

There's an excellent reason for the XML (in)elegance.- We first tried a compact binary protocol, base64 encodings, and other alternate encodings.- But, XMPP prefers XML-based protocols.- We wanted ease of software development, so ease outweighed a lot of factors.- Deaf-friendly: Something that can be added to existing traditional chat interfaces in existing chat software (much like AOL's proprietary Real-Time IM, but as an open standard). It can be turned on/off- We chose delibrately short XML tags to reduc

<w> allows transmitting of key press intervals, so that one packet can playback 10 keypresses naturally. XEP-0301 is the world's first real time text standard that packetizes the delays between the key presses, so you can transmit only a few packets per second. And yet keep the typing smooth.

I do need to correct that last sentence.As shown in the animation, "you can transmit a multiple keypresses in only one packet per second. And yet keep the typing smooth."

do you really need to send a delay?did you try dividing a second by the number of characters in the packet to automate smoothing on the receiving end? If you did, what did not work? didn't feel natural?

Yep, that worked, and it works well.In fact, XEP-0301 mentions that an alternate smoothing method can be used as an alternative in the last bullet of Section 6.2.3.

However, because this standard is designed to benefit deaf people like me:Some of us deafies are sensitive to 'emotion' in typing. People type differently when calm (smooth, typo free) or panicked (fast, lots of typos), or tired (slow, more typos). When we talk to the same person frequently, we can pick up the emotion partially from the typing,

This reminds me of a beautiful plugin for one of the chat clients, I can't remember which one now, that exploited the 'realtime typing notification' option that one of the IM systems offered.

By default, the client would only show typing notifications if you were already chatting with someone. This plugin warned you of typing notifications from people just initiating a conversation, which usually gave you time to quickly reply to them before they had a chance to say something to you. Totally freaked out t

You're thinking of the Psychic Mode plugin that comes with Pidgin [pidgin.im] of which is also used by the Bot Sentry plugin [sourceforge.net] to filter out spam messages. I remember the first time I got Bot Sentry working and noticed that it pretty much eliminated the spam problem coming from both ICQ and MSN networks, but the first time I saw "You feel a disturbance in the force" a week later kind of freaked me out as I didn't realize that was Psychic Mode's default behavior.

A long time ago I wrote a GAIM (Pidgin) plugin as a prank based on the observation that people usually try to avoid responding at the same time by watching the typing icon; if one person is typing, the other person stops typing to give the first person a chance to finish.

The plugin, instead of reporting my typing status, would *mirror* the other person's typing status. So as soon as they started typing, it would indicate that *I* was typing as well. Most of my friends didn't realize what was going on; they

The spec is actually more targetted towards deaf-friendliness. The spec mentions:"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see Re

Seriously. It is difficult to express in words just how inefficient XMPP is as a protocol -- and this will be even worse! Sure, it's not a big deal on the client side, but real-world XMPP servers spend a substantial amount of time just parsing XML stanzas...and this would be a worst-case for them. Wow.

If XMPP and its XML gobblydegook aren't the "wave" of the future, then what protocol should/must win out from a technical perspective?
Of course, I keep in mind that the best doesn't necessarily always win out, but for kicks and giggles...

If XMPP and its XML gobblydegook aren't the "wave" of the future, then what protocol should/must win out from a technical perspective? Of course, I keep in mind that the best doesn't necessarily always win out, but for kicks and giggles...

From what i understood this is not what they do.They check what key strokes have been entered in the past second and at what interval.They then transmit all this information to the other side where this is being shown.So while typing, one XML request / second is being send.

Still a lot of xml requests, but a nice compromise if you want natural typing in semi-realtime ( one second delay ).

Some interesting notes to add, for this technology:-- It's also allowed to use a different transmission interval (i.e. 300ms) to reduce the lag, especially if you're using your own XMPP network where you can control the servers, etc. If using your own LAN XMPP server, you could even turn off transmission buffering and transmit all changes/keypresses immediately, but that's not a good idea for the public XMPP network, since that means 30 XMPP messages a second for a key being held down (auto-r

I looked into this recently. It seems there are plenty of methods in XMPP for sending files in our modern mess of NATs. However, IM clients haven't necessarily kept up with the XMPP standards. The libpurple based clients (Pidgin, Adium, etc.) in particular seem to be stuck with the XMPP of several years ago. I've had better luck sending files with Psi, but that client is kind of clunky. Anyway, I suspect that file transfer is considered to be a solved problem from the point of view of the XMPP standard

Sending files in-band can fail/get stuck as GP said; also it is often capped by administrators. In my peer-to-peer filesharing application, dubbed Jake [sf.net], I use XMPP to negotiate a ICE/STUN peer-to-peer connection. If that fails, there is always the in-band method to fall back to. (The backend seems to work decently, the GUI and testing needs work though)

The jingle protocol is supposed to be for XMPP what ICE/SIP is for VoIP, but there are only few implementations.

Was this the most hated feature? There are plenty of cases where this is very appropriate. The problem with Wave was that your conversations quickly turned into a jumbled mess where you had no idea what the most recent contributions are.

But yeah, my first thought was: didn't Google Wave already do real time text over XMPP?

It's a good assistive technology feature for the deaf too. In fact, the Introduction also mentions its use by the deaf, too:http://xmpp.org/extensions/xep-0301.html [xmpp.org] "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the

(1) This is an optional feature that can be turned on/off.You only use it when you want it, so you don't have to show off your typos to everyone, if you don't want to.Just like audio can be turned on/off and video can be turned on/off.

(2) It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf:http://xmpp.org/extensions/xep-0301.html [xmpp.org]"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."

(3) It's not inefficient in message rate. It is only one packet per second, no matter how fast you type, even 30 keypresses per second (holding a key down). As far as I know, this is the world's first real-time text protocol that preserves key-press delays for chats. This means typing still looks smooth, even at low packet rates (1 packet per second), even if you are typing at 10 or 30 keypresses per second. Even over a satellite connection, or even over a dial-up connection (while an FTP is going on in the background), or over a mobile phone connection that has intermittent reception and variable ping latency.

(5) Some existing software already have this feature, that you may not notice, because it's off by default. For example, AOL Instant Messenger's "Real-Time IM" feature is a proprietary version of real time text, while XEP-0301 is an open standard that anyone can use for Jabber-based networks.

You saw every keystroke that other people were typing in real time.
I think there are real advantages, because you anticipate what someone is abou to type and interrupt them in realtime. I think that can save time in some conversations.
However, the typos, and the backspaces did become tedious.

It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf:http://xmpp.org/extensions/xep-0301.html [xmpp.org] [xmpp.org]"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by