Comparison of instant messaging protocols
From Wikipedia, the free encyclopedia
The following tables compare general and technical information for a number of instant messaging protocols. Please see the individual protocols' articles for further information. This article is not all-inclusive or necessarily up-to-date.
[edit] General information
Basic general information about the protocols: creator, version, amongst others.
Creator | First public release date | License | Identity (not inc. alias) | Asynchronous message relaying | Transport Layer Security | Unlimited amount of contacts | Bulletins to all contacts | One-to-many routing 5 | SPIM protection | Supports groups or channels for members / nonmembers / nobody | |
---|---|---|---|---|---|---|---|---|---|---|---|
Cspace | Cspace | 17 July 2006 | Open | Unique RSA-Key e.g. 9827347235 |
No | Yes | Yes | No | No | No | No |
Gadu-Gadu | Gadu-Gadu | 17 July 2000 | Proprietary | Unique number e.g. 12345678 |
Yes | ? | |||||
IRC | Jarkko Oikarinen | August 1988 | Open standard | Nickname!Username@hostname (or "hostmask") e.g. user!~usr@a.b.com 1 |
Yes, but via a memo system that
differs from the main system |
Sometimes, depending on individual server support | No 3 | No | Simplistic multicast | Medium | Yes (everyone, multiple simultaneous, any size) |
Meca Network | Meca Communications | Nov 2002 | Proprietary | Username | Yes | ? | |||||
MSNP (Windows Live Messenger, etc) | Microsoft | July 1999 | Proprietary | E-mail address (.NET Passport) | Yes | No | Only for certified robots | No | Centralistic | None | ? |
OSCAR protocol (AIM, ICQ) | AOL | 1997 | Proprietary | Username or UIN e.g. 12345678 |
Yes | Yes (Aim Pro, Aim Lite) | No | No | Centralistic | Yes? | Yes |
PSYC (Protocol for SYnchronous Conferencing) | PSYC Project | 1995 | Open standard | PSYC URI as in psyc://server.example.net/~nickname | Yes | Yes | Yes | Yes | Custom multicast | Yes | Yes (multiple simultaneous, any size, programmable) |
TOC protocol (deprecated) | AOL | ? | Proprietary | Username or UIN e.g. 12345678 |
Yes | No | paying members only | ||||
TOC2 protocol | AOL | Sep 2005 | Proprietary | Username or UIN e.g. 12345678 |
Yes | No | No | No | Centralistic | No | paying members only |
XMPP (Jabber) | Jeremie Miller, standardized via IETF | January 1999 | Open standard | Jabber ID (JID) e.g. usr@a.b.c/home 2 |
Yes | Yes | Optional 3,4 | Yes | Unicast lists | Several Standardized Types | MUC add-on for small groups |
SIP/SIMPLE | IETF | Dec 2002 | Open standard | user@hostname | Yes | Yes | Yes | Yes | No | Medium | ? |
YMSG (Yahoo! Messenger) | Yahoo! | ? | Proprietary | Username | Yes | No | No (groups discontinued due to liability) | ||||
DirectNet | Open standard | ? | |||||||||
Zephyr Notification Service | Open standard | ? | |||||||||
Gale | Proprietary | ? | |||||||||
Skype Protocol | Skype | Proprietary | Username | No | Proprietary | No | No | Yes | |||
Creator | First public release date | License | Identity (not inc. alias) | Asynchronous message relaying | Transport Layer Security | Unlimited amount of contacts | Bulletins to all contacts | One-to-many routing | SPIM protection | style/practicalities of groups |
Note 1: In ~usr@a.b.com, the a.b.com part is known as the "hostmask" and can either be the server being connected from or a "cloak" granted by the server administrator; a more realistic example is ~myname@myisp.example.com. The tilde generally indicates that the username provided by the IRC client on signon was not verified with the ident service.
Note 2: In usr@a.b.c/home, the home part is a "resource", which distinguishes the same user when logged in from multiple locations, possibly simultaneously; a more realistic example is user@jabberserver.example.com/home
Note 3: Scalability issue: The protocol gets increasingly inefficient with the amount of contacts.
Note 4: For empirical evidence stpeter often has more than 2000 roster entries, and currently has about 1300.
Note 5: One-to-many/many-to-many communications primarily comprise presence and groupchat distribution. Some technologies have the ability to distribute data by multicast, avoiding bottlenecks on the sending side caused by the amount of recipients. Efficient distribution of presence is currently however a technological scalability issue for both XMPP (Jabber) and SIP/SIMPLE.