Slashdot Mirror
Real-Time Text Over Jabber/XMPP/Google Talk
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."
"http://www.redtube.c-"
"sorry, wrong vt"
oh how i miss you.
Good-bye
I want to think about what I'm typing before I let the other person know about it.
Now I can idle in real-time.
I do remember the days of real-time text. I don't want it back. I make too many typos and other such mistakes. I'd rather not let others watch me type.
A unique way to learn a language: http://languageloom.com
I think i
Welcome to 2011, where 1981 is continuously re-invented
Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson
they finally figured out talk and ytalk. Good for them.
You can't handle the truth.
Only ting-tong.
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 those who didn't realize that their client was providing realtime status information...
Will this be integrated into the upcoming Hollywood OS?
I've been in many jobs in the last ~15 years where a chat infrastructure is a standard tool of the IT group.
I've also seen managers, who traditionally kept out of the admin channels, start to invade them, in the name of "keeping a pulse of the group's activities and issues..."
No sir, I don't want or need my boss seeing what I type and erase in the chat client before I type a calmer chat and hit enter.
Do Not Want.
-- "In order to have power, I must be taken seriously." -Mojo Jojo
I used talk recently when stuck in an odd situation. The guy on the other end and I usually use IM.
His comment to me, "christ, Bill, you type like shit."
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Transmitting a TCP packet every time a character is typed seems kind of inefficient unless there is a big gain here.
Join the Slashcott! Feb 10 thru Feb 17!
I mean, I really don't think anyone wants to watch me type a word, delete back to the beginning because I misspelled it, retype it, the continue on to the end and then watch me go back to use the spellchecker to finally get it right (As happened 4 times writing this). When I watched that on Google Wave, all I did was yell at the screen "Okay - I know what you are typing. Just finish already!"
...all of my ^H^H^H jokes will be funny again.
Last I tried sending a file via XMPP it still (after what 10 years) failed.
That would be a nice thing to work out first.
I'm going to copy-paste all my comments to reproduce the feel of that old-time instant messenger experience.
Rules of Conduct:
#1 - The DM is always right.
#2 - If the DM is wrong, see rule #1
> which allows streaming text that is continuously transmitted as it is typed or otherwise composed.
Wasn't it done already with a display mode in mIRC in user to user communication?
cap: antique
Yes, welcome to yesterday.
I thought that when Google announced Wave they said it used XMPP for the communications. I assume this is just a formalization of what was created back then?
Procrastinating life a way at a rapid rate of speed.
Oh, you mean the most hated feature of Google Wave? Yeah, I'm ok without it.
Why?
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.
I actually thought of this.
XMPP real-time text is the world's first real time text protocol that encodes key press delays:
http://www.marky.com/realjabber/real_time_text_demo.html
So even at 10 keypresses per second, even over a satellite connection (or other high-latency bursty connection), it only needs to transmit 1 packet per second, and the typing comes out naturally.
XEP-0301 (the protocol) is a packetization of typing including typing delays, much like VoIP packetizes short snippets of audio.
Explained in first section in section 6:
http://xmpp.org/extensions/xep-0301.html#implementation_notes
This feature can be turned on/off.
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
"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]."
Hello --
Some general comments that addresses common comments:
(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
"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.
(4) There is an animation of the key press intervals (delay coding) at:
http://www.marky.com/realjabber/real_time_text_demo.html
(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.
What fanfare over nothing, as post said above 1981 is reinvented. Next they will bring back the 300 BAUD modem.
does no one remember?
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie
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.
And what on earth would you use a "beep" command for?
Darn near everybody else has it:
Yahoo Buzz
BlackBerry Ping
Windows Live Nudge
XMPP.org's XEP-0224 "Attention" (for Jabber / XMPP / Google Talk / etc)
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 reduce bandwidth. Yes, that does not follow XML philosophy in naming, but it is a bandwidth compromise.
- We delibrately avoided using tag names of existing HTML tags, even though this is a different XML namespace. We avoided <b> and <i> anyway.
First, see the animated GIF of this real-time text protocol, to see some of the reasons why this XML was chosen:
http://www.marky.com/realjabber/real_time_text_demo.html
Now read section 7.1 through 7.9 of the XEP-0301 specification:
http://xmpp.org/extensions/xep-0301.html#action_elements
As you can watch in the animation,
<t> is insert text, to support transmission of key presses, text block inserts, and text being pasted.
<e> is backspace.
<d> is delete key (forward delete), or cutting / deleting blocks of text
<c> is cursor positioning (optional)
<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.
<g> is for backwards compatibility with similiar features like Yahoo Buzz, MSN Nudge, BlackBerry Ping, Jabber XEP-0224 Attention, etc. It is very deaf-friendly and this is optional and can be turned off, but some like this feature.
More info about these action elements:
http://xmpp.org/extensions/xep-0301.html#action_elements
Only the first 3 XML elements are required (insert, backspace, and delete)
So as you can observe, there is excellent rationale for the "turd" we had to use. It is for instant messaging conversations, not for things like Google Wave, and is rather instead an optional add-on to existing instant messaging that can be turned on/off.
http://www.marky.com/realjabber/real_time_text_demo.html
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, especially when supplemented with additional context (typed words, emoticons, etc). The spec encourages the use of high-precision transmission of delays in typing (Section 6.1.2), because that is more interesting than packet bursting (Section 6.1.1).
Time-based smoothing has the advantage of masking out typos especially if I do word transmission (giving the sender the opportunity to fix typos first). However, many deafies prefer seeing the original typing at high precision, for "maximum fidelity" of text-based communications.
The spec is being continually updated, to cover additional use cases, and this may be covered/clarified in a future update (since the spec is still in its Experimental stage, there is plenty of time to improve the spec; as XMPP.org gives every specification a mandatory minimum 12-month experimential period, before being upgraded to Draft status.)
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 RealJabber.org [1].
That said, it's useful in the enterprise in certain contexts like an assistive-friendly workplace that does not involve boss chats, and also between two different engineers who intentionally turn on the feature (which is an on/off feature, like audio can be turned on/off and video can be turned on/off). In your use case, you definitely want to turn this feature off.
Good answer.
Some interesting notes to add, for this technology: ...) and generate the action elements that way. That way you capture all possible changes to the text, as generally recommended in Implementor's Notes in section 6.2.1 of the specification. Although keypress events are OK, if you can strictly control all other possible changes to text (i.e. alternative text entry methods, copy/pastes, etc)
-- 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-repeat)
-- Generally, instead of capturing keypresses, an even better method is to monitor for text changes instead.
This is because of the need to capture copy/pastes, automatic text replacements (auto spell checkers), voice recognition systems, special keyboards, that might not output one keypress at a time. Everytime the text in the sender's message changes, scan for the change (which is done in EncodeRawRTT( ) line 315 in RealTimeText.cs in realjabber.googlecoe.com
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 bandwidth efficiency. I'm fine with that. Besides, it doesn't really use much total bandwidth, anyway, especially since XMPP now permits base64 transmissions of avatar images and file transfers, etc -- all of which use more bandwidth than real time text. And the capped message rate is very reasonable.)
As this spec is partly designed for use by deaf people (including me; the specification's introduction specifically mentions this assistive use, too.), it is very desirable to see the original delays between the key presses. There is an animation of the key press interval encoding:
http://www.marky.com/realjabber/real_time_text_demo.html
As you notice in the animated GIF in the above link, there is a slight 'emotion' in the keypresses (calm typing versus panicked/emphatic typing) that deaf people like to pick up on, when supplemented with other contextual cues (text content, emoticons, etc).
Note -- For everyone else, the real-time feature can be turned on/off like audio/video is already an on/off feature in chats.
Thanks for the info. I wonder how difficult something like google chat would be to integrate such a system. As it keeps all IM messages in its system. I'm guessing these wouldn't be captured?
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/ ... 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, but XEP-0301 limits it to a recommended setting of just 1 XMPP message per second maximum, to be gentle on the network. (In fact, that's probably comparable to text-happy kids who say "Hi" "wassup" "u?" and type those messages once a second before transmitting them -- ha ha -- annoying to our group, but the XMPP network clearly can handle a protocol that requires a once-a-second message rate.)
I am working with several parties that are creating clients for Android as well as in AJAX/JavaScript (Linux/Android/iPad compatible). To prevent annoying users, Google could keep it turned off by default, but just an on/off menu item or button. Turning on/off real-time text like turning on/off audio or video. (It shouldn't be annoying as Google Wave that way, yet provide an important service for deaf people like me, and for people who *do* feel like turning on the feature -- even 1% or 10% is still a lot of people).
In fact, some existing chat software sometimes have real time text already (AOL AIM's "Real Time IM" -- a feature that is turned off by default and is a feature usually not discovered by most non-deaf people. Unfortunately, it is proprietary, unlike the open XEP-0301 protocol that anyone can use over Jabber/XMPP.)
P.S. You can't believe how some of us deafies are stuck with older technologies. For example, our text telephones (TDD / TTY) run at 45 baud! (Yes. 45. that's slower than 300 baud -- don't believe me? -- see http://en.wikipedia.org/wiki/TDD/TTY ..)
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, and to avoid transmitting real-time text, in order to save network bandwidth.
So existing software without real-time would work fine, even when connected to a real-time capable client that's intentionally transmitting real-time messages. (they're ignored since it's an additional XML element that's ignored, and only the finished full line of messages are displayed)
I'm texting in real-time, oh wait, I have a phone....
I'm going to make a voice phone call. Much easier and faster.
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]."
http://www.pubnub.com/blog/tutorial-how-to-build-real-time-keystroke-chat - pre-made LIVE example.