Telepathy is a flexible, modular communications framework that enables real-time communication via pluggable protocol backends. Telepathy creates the idea of communication as a desktop service. It uses D-Bus to separate components running in separate processes. Telepathy clients use this D-Bus API (usually via a convenience library — e.g. telepathy-glib) to share connections between multiple clients (e.g. an instant messaging program, presence in email application, collaboration in word processor).

Do One Thing and Do It Well

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together.

Doug McIlroy

Telepathy components are modular, this means that developers can focus on making each component being the best it can be.

Application developers can focus on user interaction whilst protocol developers can focus on an individual protocol.

Figure 1-1 Conceptual example of Telepathy clients (blue) and Connection Managers (green)

Backends for many popular instant messaging protocols already exist including XMPP/Jabber (telepathy-gabble), SIP (telepathy-sofiasip), MSN (telepathy-butterfly) and IRC (telepathy-idle). The development of a new protocol backend can be utilised immediately by all Telepathy consumers.

Telepathy backends can expose the different features of a communications protocol, including presence (status), text chat (instant messaging), voice and video conferencing, file transfer and Tubes (contact-to-contact network sockets brokered by Telepathy); and do this in a unified way via D-Bus interfaces.

Is Telepathy a Specification or an Implementation?

It's both.

There is one specification which defines the D-Bus API for how one Telepathy component talks to another. Additionally there are many implementations of this specification in the form of libraries that wrap the D-Bus API in a model that might be more familiar to you; and components (e.g. the Connection Managers) that allow you to do useful things with Telepathy.