Unified communication identity integration - a draft for discussion

disclaimer: this is in the current status just a draft for discussion. I first want to contact the communities of several communication programs. After discussion I want to propose the resulting standard at freedesktop.org for further discussion and formal publication.


update: the Telepathy: Flexible Communications Framework seems to be related to this functionality. From what I see it provides integration on a much lower level, but at the cost of high implementation complexity. Supporting telepathy might require a complete reqrite of an application. It's not something done by a plugin (please correct me if you feel I'm wrong about that). It seems that only Gnome developers are looking at Telepathy right now. The Banter client is built on top of this. Galago is a desktop presence framework, it allows you to see that the author of an email is online in your IM client using Telepathy. Galago is desktop neutral which is good, but it seems that only Gnome application developers are looking into Galago. Soylent is another project I wasn't aware of that does a idenity integration approach already. It uses libempathy. I Will look into it soon.

update: Guifications is a starting project to send notifications between different applications. Very leightweight protocol. Nice.

The end-user perspective

Example1: IM client with email integration

The end user is using a IM client, where the he's notified in the chat window that a new email arrived from the same person he's chatting to (even if the IM account is different from the email account). The user may right click this buddy in the IM client, and in the context menu it says you have unread mail from this person, and the context menu will allow you to send email to this person, or call this person using VOIP.

Example2: wordprocessor with IRC chat integration

You open a document which has a username in the metadata. You open the metadata, and your wordprocessor notifies you that this user is online on IRC channel #foo and it shows you a menu entry to call this user using VOIP

Example 3: presence information in your email client

In your email client you right click the email address. You get a popup showing this person is online with ICQ, and an option to initiate a chat session, and you see the person is logged-on in linkedin.com

So what can be linked together?

The standard

To do this we need a standard that all applications can use to exchange information with the daemon.

Communication over Dbus (with the C api) seems to be the most logical choice for interprocess communication in modern desktops(good accessible from different programming languages, etc.).

Design choices

every app a single channel communication with a daemon - we could just have every app open an IPC channel to every other app on the desktop to check for status on the user. this is tricky for the application programmer: different applications will return information after different times, so a right click context menu has to be changed several times after new information comes in, or the menu will pop-up only after the last application has returned the requested information. Instead of that we chose to have a daemon that collects all the data from all the apps, and every app has a single communication channel to the daemon: request status about a user from the daemon, and you'll get it all in one go. So the application waits for the daemon, and the daemon should have all data already available

a daemon exists that can map different accounts to each other - for example email me@email.com is the same as ICQ #123456789 and is the same as sip: foobar@provider.com . The daemon knows this, so if you request data for ICQ #123456789 you will get data about sip: foobar@provider.com and mail: me@email.com

Application perspective

The daemon interface: methods from the daemon called by applications


This method is called whenever a client application internally discovers a new identity, or whenever a status message needs to be changed (for a new or existing identity). This may be a new identity for the daemon, or an existing identity


this method is called to remove an identity from the daemnon. For example if an email is marked as spam the originating address could be removed from the list handled by the daemon.


this method is called to register actions with the daemon.


this method can be called if all status information and actions for this identity are unavailable (for example: IRC user goes offline)


this method can be called if all status information and actions for all identities registered by this client are unavailable (For example: your IRC client is disconnected from the network)


this method is called by an application to retrieve the status of a certain identity


this is called by an application to retrieve all actions for a certain identity

returns a list with the following records:


this is called by an application if the user activated one of the actions retrieved with listidentityactions


this method is called after an application started to indicate the application can handle identities known by a certain class (for example class mail). If an identity with class mail is registered (for example by an addressbook application) without an application, these identities will have the action registered with this function


this method is called if an application knows about certain mappings, for example an addressbook application can register an email address and a jabber account, and register they are the same person

Client interface: methods that clients should implement that can be called by the daemon


If the daemon method executeidentityaction is called, the daemon will call the method from the application that has to execute the action

Daemon configuration