Telepathy

Overview

Telepathy is a framework for real-time conversations, including instant messaging, IRC, voice calls and video calls. It provides a modular approach to implementing these types of communications, so that applications do not have to reimplement common functionality.

Telepathy uses the D-Bus IPC system between components, allowing development of new components in any language, to conform to the Telepathy D-Bus specification. This means that Telepathy components can be added to existing applications which can talk D-Bus, without a hard dependency.

Telepathy is supported by Collabora Ltd

Presentation

See Rob McQueen's recent presentation on Telepathy at linux.conf.au: OGG SPX

Rationale

Benefits of Telepathy's modular approach:

• Robustness: one component can crash without crashing others
• Ease of development: components can be replaced within a running system; tools like dbus-inspector can trace interactions between components
• Language independence: components can be written in any language that has a D-Bus binding; if the best free implementation of the Oscar (AOL) protocol is in Java, you can write your Oscar connection manager in Java to take advantage of that
• Desktop independence: D-Bus has been adopted as an IPC mechanism by both GNOME and KDE
• License independence: components can be under different licenses that would be incompatible if all components were running in one process
• Code reuse: Telepathy allows clients to ignore protocol details as much as possible, easing transitions between different communications systems
• Connection reuse: multiple Telepathy components can use the same connection simultaneously
• Security: components can run with very limited privileges; a typical connection manager only needs access to the network and to the D-Bus bus, making it possible for an SELinux policy to prevent protocol code from e.g. accessing the disk

(from http://telepathy.freedesktop.org/wiki/)

Connection Managers

Telepathy Connection Managers (CMs) provide the back ends for protocols. Since these are modular, a Telepathy-enabled application can use whichever CMs are available, providing they support the appropriate interfaces.

Used by OLPC

OLPC uses the following CMs:

• Gabble: for XMPP via a Jabber Server
• Salut: for link local XMPP

See Activity sharing for an overview of activity collaboration, and Presence Service to see how the Sugar stack interfaces with these Telepathy CMs.

See Activity Sharing for some historical discussion on the rationale of using Telepathy for OLPC.

Other CMs

In addition, there are CMs implemented for the following protocols:

• Idle: IRC
• Telepathy-SofiaSIP: SIP
• Butterfly: MSN
• Haze: uses libpurple to provide all the protocols that Pidgin supports (AIM, ICQ, Yahoo, MSN...)

Telepathy Spec

At the core of Telepathy is the DBus interface specification which describes how Telepathy components communicate with each other. See Telepathy D-Bus Interface Specification for the current version.

Proposed Standards

These documents were generated from the XML files included in telepathy-gabble/docs and telepathy-salut/docs:

• XEP-proto-olpc1.0: OLPC-specific properties, version 1.0
• XEP-proto-tubes: Tubes over XMPP
• XEP-proto-muc-bytestream: MUC Bytestreams
• XEP-proto-clique: Clique - link-local chat rooms

More Telepathy Documentation

The Telepathy wiki has documentation. In particular, see the following documents:

Telepathy Architecture

• See Telepathy Framework Architecture.
• Telepathy Developers Manual (under construction)
• Telepathy chapter in The Architecture of Open Source Applications

Other links

• Multiple tube discussion, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg08050.html