There seems to be a lot of confusion about what the Telepathy-KDE project is and what it has to do with Kopete. I’ll try and explain in this blog post everything, so that it is clear to everyone.

First of all, Telepathy is a framework for writing applications that can use real-time communication and collaboration features. In Telepathy, there are the so-called connection managers that connect to IM and similar networks and the clients that use those connections over D-Bus. This allows dividing the several tasks of an IM client to several applications, which makes it easier to reuse code and easier for applications to add collaboration features without caring about protocols, contact lists, presence status and all that stuff.

In Telepathy-KDE what we are trying to do is to integrate Telepathy with the KDE Plasma desktop. What we imagine is not to have a monolithic IM client like kopete or empathy but to integrate all the features of an IM client directly into the desktop. For this reason, we are going to add the following components into the KDE SC:

A presence plasmoid. This will be a plasmoid sitting in your notification area or somewhere else, showing your online status and allowing you with a popup to change status, to enter a status message, etc… A contact list application. This will be a standalone application that will just show the contact list. It will of course have all the necessary actions to start a chat or a call or do something else with any of your contacts. A chat window application. This will be a standalone application providing just the chat window. When a new chat starts, it will be auto-launched via D-Bus service activation and allow you to chat. A VoIP call window application. This will again be a standalone application providing the call window, also auto-launched to handle calls. This is actually KCall, what I wrote in last year’s summer of code, but it won’t have the contact list and won’t be named “KCall”. An approver daemon. This will be a daemon sitting in the background and listening for incoming channels. When somebody requests that you start doing something with him (be it chat, video call, play a game together, share your desktop, etc…), it will show a KNotify popup allowing you to accept or reject the request. A file transfer daemon. This will be a daemon that will be auto-launched like the chat and call windows when you want to do a file transfer to or from one of your contacts and handle that file transfer for you. The nepomuk integration daemon. This is an implementation detail, really internal, not shown to the users. This will allow you to have metacontacts by pushing all of your contacts into the nepomuk database and defining relations between them. It will also allow at some point sharing contacts with akonadi and other cool stuff.

In the future, other components could be added, such as a logger daemon that logs all your chats into files or into a database or something like that and of course it will be very simple to add collaboration features to other applications for doing anything with your contacts. For example, krdc already has telepathy integration and it is possible that if someone requests you over telepathy to share his desktop, you could use krdc to view his desktop, without caring about firewalls or anything. Unfortunately, the server side of this is currently only implemented in gnome, so only a user using gnome can currently share his desktop with you, but that will be fixed in the future.

As a sidenote here, telepathy also allows you to share D-Bus connections over the IM network, which makes it extremely easy to add collaboration features to an application that has no idea about networks or protocols. With this feature, called D-Bus tubes, all you have to do in your application is to expose a D-Bus interface which will be called from the remote side using normal D-Bus calls, as if the other side was running on the same computer. With this feature, we could add collaboration features to many KDE applications in the future very easily. Unfortunately, this currently requires a patch in Qt that has not been merged yet and it is not yet certain if it will make it for Qt 4.8 (which actually screws the whole feature, but we can still hope it will be in Qt 4.8, so that we can start using it in KDE 4.7 or 4.8).

To get to kopete now, as you realize, there is no much place for kopete in all this. So, as soon as we merge all this in the KDE SC, kopete is going to get out of there. All in all, it has not received much development in the last years and even many of its former maintainers are now looking towards Telepathy-KDE, so I don’ t think we have any reason to keep it around. In addition, kopete’s code is not very much reusable in its current form, so we are not going to use it at all. Many people have stated that this may be a bad idea, but we have actually tried to port code from kopete and it didn’t really work, so we decided to do a new implementation from scratch.

I hope that pretty much explains everything now. Let’s stop talking about kopete and let’s start working on Telepathy-KDE 😀

PS: If you want to get involved with it, come and find us on irc in #kde-telepathy on irc.freenode.net.