Peer-to-Peer Information Systems Week 14: Instant Messaging Old Dominion University Department of Computer Science CS 495/595 Fall 2004 Michael L. Nelson <mln@cs.odu.edu> 11/30/04

People 2 People For most people, computers are for communication, not computing “Killer applications” Communications: asynchronous, 1-1, 1-many E-mail web pages (esp. blogs) synchronous, 1-1, 1-many instant messaging (IM) others: the most successful games have synchronous, person-2-person play many file sharing P2P applications assume the existence of a communications medium for resource discovery

Early IM Tools Unix “talk” Internet Relay Chat Zephyr http://www.gnu.org/directory/livecomm/chat/ytalk.html Internet Relay Chat http://www.irc.org/ Zephyr http://web.mit.edu/olh/Zephyr/

Proprietary IM Protocols Oscar/AIM http://aimdoc.sourceforge.net/OSCARdoc/ YMSG http://www.cse.iitb.ac.in/varunk/YahooProtocol.php http://search.cpan.org/dist/Net-YMSG/ MSN Instant Messenger Protocol http://www.hypothetic.org/docs/msn/sitev1/ ICQ (now owned by AOL) http://www.d.kth.se/~d95-mih/icq/

Centralized IM Alice Bob MSN, Yahoo(?) “Bob is online” “Alice is online” “Where is everyone going to lunch today?” “We’re headed to Rajput” Alice Bob MSN, Yahoo(?)

P2P IM Alice Bob ICQ “Bob is online” “Alice is online” “Where is everyone going to lunch today?” “We’re headed to Rajput” Alice Bob ICQ

Hybrid IM Alice Bob AOL AIM, Yahoo? “Bob is online” “Alice is online” “Where is everyone going to lunch today?” “We’re headed to Rajput, here is a scan of their menu” Alice Bob AOL AIM, Yahoo?

IM Lock-in AIM, YMSG, MSN, etc. are an improvement over irc, talk, etc. in that they: remove location dependency from identity pass the P2P litmus test: variable connectivity & temp IP addresses autonomy for nodes at edges of the network But they are all proprietary: limited to the supported client locked in to the provider that supports the protocol you and your brother are on AOL, but you parents are on Yahoo! and your sister is on MSN its like having 3 separate email clients & email addresses to communicate with all of your friends & colleagues

Multi-Protocol Clients Multi-protocol clients exist: Everybuddy http://www.everybuddy.com/ Trillian http://www.trillian.cc/ Fire http://fire.sourceforge.net/ GAIM http://gaim.sourceforge.net/ etc. But they require identities for each of the services

Supporting Multiple Protocols DJ Recall@yahoo.com dj_recall@aol.com DJ Precision@aol.com precision@yahoo.com DJ Recall DJ Precision

Jabber An open source / open protocol alternative Features: http://www.jabber.org/ Features: protocol is defined in XML cf. binary proprietary protocols! adopted by the IETF as the platform for the evolving Extensible Messaging and Presence Protocol (XMPP) separate clients and servers for installation gateways for legacy protocols (AIM, YMSG, etc.) as well as person-2-application conversations

Romeo & Juliet montague.net capulet.com Jabber Servers Jabber Clients to: juliet@capulet.com By a name I know not how to tell thee who I am: My name, dear saint, is hateful to myself, Because it is an enemy to thee; Had I it written, I would tear the word. to: romeo@montague.net What man art thou that thus bescreen'd in night So stumblest on my counsel? Jabber Clients JID = romeo@montague.net JID = juliet@capulet.com DiCaprio & Danes images from http://www.romeoandjuliet.com/

Jabber Clients A rich set of clients supported (many with built-in support for other IM protocols too) http://www.jabber.org/user/clientlist.php Jabber IDs (JIDs) they look like email addresses, but they’re not but they’re similar in effect relative to hierarchical naming they make explicit what was hardwired in AIM, YMSG, etc e.g. DJ_Recall@yahoo.com

Use a public server… …or run your own

Jabber URIs jabber://user@server/resource resources generally used as connection ids resource addresses are hidden from users; only used by software/protocol “data”, as shown on p. 85, is not part of the Jabber IETF draft

XML Messages from: http://www.jabber.org/ietf/attic/draft-jabber-00.txt <message to="hamlet@denmark" from="horatio@denmark" type="chat"> <subject>Plotting</subject> <body>Here, sweet lord, at your service.</body> <thread>100052</thread> </message> from: ch. 6, p. 84 <message to=“horatio@denmark” from=“hamlet@denmark”> <body>Angels and Ministers of Grace, Defend us!</body> <prayer xmlns=“http://www.grace.org/”> <verse> … </verse> </prayer> </message> XML messages bundled through the use of <stream> tags (see section 5.2 of the Jabber draft; also section 10 for examples)

Extensibility Through Namespaces Client request for registration information to a server service (service.denmark): <iq type="get" id="1001" to="service.denmark"> <query xmlns="jabber:iq:register"/> </iq> Server response with registration fields required: <iq type="result" from="service.denmark" to="hamlet@denmark" id="1001"> <query xmlns="jabber:iq:register"> <instructions>Choose a username and password to register with this server.</instructions> <name/> <email/> <password/> <key>106c0a7b5510f192a408a1d054150ed1065e255a</key> </query> </iq> from: http://www.jabber.org/ietf/attic/draft-jabber-00.txt

Extensibility Through Namespaces Client request to register for an account: <iq type="set" to="service.denmark" from="hamlet@denmark" id="1002"> <query xmlns="jabber:iq:register"> <name>hamlet</name> <email>hamlet@denmark</email> <password>gertrude</password> <key>106c0a7b5510f192a408a1d054150ed1065e255a</key> </query> </iq> Successful registration: <iq type="result" from="service.denmark" to="hamlet@denmark" id="1002"/> Failed registration: <iq type="error" from="service.denmark" to="hamlet@denmark" id="1002"/> <error code="406">Not Acceptable</error> </iq> from: http://www.jabber.org/ietf/attic/draft-jabber-00.txt

Presence <presence from="hamlet@denmark"> <show>xa</show> <status>Gone to England</status> </presence> from: http://www.jabber.org/ietf/attic/draft-jabber-00.txt

Roster Client request for current roster: <iq type="get" id="1001"> <query xmlns="jabber:iq:roster"/> </iq> Server response to client query: <iq type="result" id="1001"> <query xmlns="jabber:iq:roster"> <item jid="claudius@denmark" name="Uncle Claudius" subscription="from"> <group>Family</group> </item> <item jid="horatio@denmark" name="Horatio" subscription="both"> <group>Friends</group> <item jid="fortinbras@norway" name="Prince Fortinbras" subscription="none" ask="subscribe"/> </query> </iq> from: http://www.jabber.org/ietf/attic/draft-jabber-00.txt

People 2 Applications Using XML namespaces inside the <iq> element, we can create “conversations” with applications as well as people. Some hypothetical examples: “What was the result of November 18th 1995 Virginia Tech football game?” “What is the 5 day forecast for zip code 23508?” <iq type="get" id="1001"> <query xmlns="jabber:iq:hokiesports.com"> <gameresult> <date>1995-11-18</date> <sport>football</sport> <result type=“boxscore”/> </gameresult> </query> </iq> <iq type="get" id="1001"> <query xmlns="jabber:iq:weather.com"> <forecast days=“5” zipcode=“23508”/> </query> </iq>

XMPP Extensible Messaging and Presence Protocol (XMPP) http://www.jabber.org/ietf/ (www.xmpp.org soon) defined in 4 drafts: core protocol defines streams, stanzas, authentication & security, internationalization issues extensions for IM & presence further definition & use cases particular to IM end-to-end object encryption mapping XMPP to the Common Presence and Instant Messaging Protocol (CPIM) http://www.ietf.org/html.charters/impp-charter.html

Streams and Stanzas |--------------------| | <stream> | | <presence> | | <show/> | | </presence> | | <message to='foo'> | | <body/> | | </message> | | <iq to='bar'> | | <query/> | | </iq> | | ... | | </stream> | stream: a container for the exchange of XML elements between any 2 entities over a network stanza: a discrete semantic unit of structured information that is sent from one entity to another over an XML stream from: http://www.jabber.org/ietf/draft-ietf-xmpp-core-20.txt

Stream Examples A basic "session": C: <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> S: <?xml version='1.0'?> from='example.com' id='someid' ... encryption, authentication, and resource binding ... C: <message from='juliet@example.com' to='romeo@example.net' xml:lang='en'> C: <body>Art thou not Romeo, and a Montague?</body> C: </message> S: <message from='romeo@example.net' to='juliet@example.com' S: <body>Neither, fair saint, if either thee dislike.</body> S: </message> C: </stream:stream> S: </stream:stream> A "session" gone bad: C: <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> S: <?xml version='1.0'?> from='example.com' id='someid' ... encryption, authentication, and resource binding ... C: <message xml:lang='en'> <body>Bad XML, no closing body tag! </message> S: <stream:error> <xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> </stream:error> S: </stream:stream> from section 4.7: http://www.jabber.org/ietf/draft-ietf-xmpp-core-20.txt

Security in XMPP XMPP Server XMPP Server XMPP Client TLS XMPP Server XMPP Server SASL TLS SASL TLS = Transport Layer Security, RFC 2246 SASL = Simple Authentication and Security Layer, RFC 2222 XMPP Client

Additions in XMPP The core is very similar to the original Jabber protocol; some notable additions: use of the “xml:lang” attribute to specify language type: definition of a “jabber:iq:privacy” namespace to maintain privacy lists, block communication based on JID, group, subscription type, etc.