Unified communication identity integration - a draft for discussion

GOALS:

• Programming language, desktop and platform independent standard
• Easy to implement (minimum complexity, maximum results)
• Resulting in a perceived integration (the end user has the perception of real integration) between many, many communication programs, whether they are from KDE, GTK, Mozilla or any other origin.

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?

• your personal/corporate calender/agenda/schedule has identities
• your email client knows about identities
• your Instant messaging client has identities
• your addressbook has identities and can map them to each other (for example email to telephone number)
• your voip client, softphone, skype etc. have identities
• website identities (hyves, myspace, linkedin etc.) (for these to integrate with the other identities you need a browser plugin)
• your wordprocessor has identities (the author of the document), this is especially true in corporate environments
• your IRC clients knows about many identities

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

• if there is a design tradeoff between the application programmer and the daemon programmer the following choice has been made: make it simple for application programmers. Adoption by application programmers is most important for adoption of the standard.
• KISS: keep it simple stupid

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 email-client receives an email message from foo@bar. It sends information to the daemon that foo@bar is an email account and that it has current status 'New mail from foo@bar', and that it allows action 'Send mail to foo@bar'

• the user right clicks user foobar@jabber.org in a jabber client. The jabber client requests information about foobar@jabber.org from the daemon.

• The daemon is told (configured by the user, or by some application) about the mapping between email-client:foo@bar and jabber-client: foobar@jabber.org . The daemon returns the status information 'New mail from foo@bar' and returns action 'Send mail to foo@bar'

• The application displays a context menu, showing there is one new mail from this user, and a menu entry to open a compose window in the email application
• the user clicks this last menu entry. The jabber-client sends a message to the daemon.
• the daemon checks if the email client is online (otherwise it will start the email client) The daemon passes the message to the email client.

The daemon interface: methods from the daemon called by applications

addidentity

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

• identity - a unique identifier within the client, or within the commonclient, for example me@email.com or me@jabber.org

• client - the name of the application client that can handle this identy. Should be unique for each application. For example 'Pidgin' or 'Thunderbird'. The client can be left empty in the case of an application that knows about email adresses, but cannot handle them (for example an addressbook application or contacts manager). Such an application can register identities without knowing what to do with them.

• class - a machine readable string such as 'mail' to suggestthis identity equals this identity in another client but an equal class'class'. e.g. me@email.com in client 'thunderbird' and me@email.com inclient 'evolution' are the same if they both use the class 'mail'

• description - a human readable string, for example "Firstname Lastname"

• status - a human readable status message (or empty) such as 1 unread mail from foo@bar or away

removeidentity

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.

• identity
• client

provisionidentityaction

this method is called to register actions with the daemon.

• identity
• client

• actionID - a per-client-unique ID (only within each application this ID should be unique for this action. For example new mail could be ID 0 for thunderbird). Clients that have just a single action can safely use 0 all the time.

• actionDescription - a human readable string, other applications will put this in in the context menu. For example send mail to

• isOfflineAvailable - a boolean if this action is available even if the application itself is currently not registered with the daemon
• offlineAction - commandline to start the action if the client is not running

releaseidentity

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

• identity
• client
• actionID - if actionID is set to -1 everything about the identity is removed (including status). If set to 0 or higher, only the specified actionID action is removed. All other actions and the status is retained.

releaseall

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)

• client

listidentitystatus

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

• identity
• client - the calling application (which will be excluded from the results)
• returns a list of status strings, each from a different client (can be 0, 1 or multiple strings)

listidentityactions

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

• identity
• client - the calling application (which will be excluded from the results)

returns a list with the following records:

• identity
• client
• actionID
• actionDescription

executeidentityaction

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

• identity
• client - the client that makes the call
• actionClient - not the client that is making the call, but the client that has to execute the action
• actionID

registerClientAction

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

• client
• actionID
• actionDescription

registerequalidentities

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

• identity1
• client1
• class1
• identity2
• client2
• class2

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

executeidentityaction

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

• identity
• client
• actionID

Daemon configuration

• users should be able to map identities to each other
• in corporate environments the daemon can use the corporate directory to find out about mappings (possibly a different implementation of the daemon can be created for corporate environments, or a special plugin)
• users probably want to set a cleanup interval, for example expunge all identity information that is not mapped to another identity after four weeks