OpenIM and IMFreedom

Few months ago I wrote a bug report on the freedesktop.org bugzilla to ask for means to start a new project. The goal of that project, called “OpenIM” was to gather effort on the opening of closed instant messaging protocols. In the bug thread and on the pidgin mailing list, a discussion started to determine if freedesktop was the right place to host that kind of project (i.e. support reverse engineering and documentation of proprietary protocols) and a lot of people joined it, agreeing that such an effort was needed, regarding the poor and all over the place documentation parcels (at least referring to the MSN protocol ones). Those people included valuable guys from amsn, pidgin, pymsn, jabber, and other worthy individuals of the IM field.

Instead of freedesktop, the pidgin guys proposed to host the initiative on IMFreedom, a Foundation they did setup as a façade when they got justice problems with AOL. We all agreed that using IMFreedom for OpenIM would make more sense. That gave birth to a brand new wiki to collect our efforts.

Be interested, sweat, contribute!

an OpenIM proposal

I finally wrote a freedesktop.org project request for the OpenIM thing that Ali and I (and certainly lots of other people involved in IM protocols reverse engineering) would like to see come up. The request is a bug report on freedesktop bugzilla, please bring your observations and ideas! Here is quoted the text of the proposal :

This is about a new project that I would like to see come up under the fd.o banner.

I’m part of the pymsn project. Our goal is to provide a full implementation of the latest MSN Messenger protocol for interoperability purpose. So far the project is kind of hosted by Telepathy since it’s the base library for telepathy-butterfly but this is clearly not the place where it should be.

Based on that observation, we would like to build an OpenIM initiative. Such a project would aim to the gathering of people working on the opening of closed instant messaging protocols.

One of the most important goal in this would to have centralized shared documentation on protocols and a clear follow up of features implemented in each project.

Status of pymsn services development

Here we are :

• Implementation of the address book is finished : the integration in msnp and the rest of pymsn happened last weekend. We are now massively debugging the behaviors of the service thanks to the help of Julien Enche (Trapamoosch) who is developing a client, daily integrating each of our feature adds, thus detecting lots of bugs. Thanks again Julien for your assiduity to post bug reports.
• Implementation of the content roaming service is finished : this is fresh from tonight but all my tests went good. We are now able to retrieve the display name, personal message and display picture stored on the server as well as we can publish those. We now need to find a way to properly integrate this within the client stuff.
• Implementation of the offline messages service is close to be finished : we’re able to get the message headers and fetch their content. The method used to send messages is the only thing missing for now but that’s just a matter of time since there’s no difficulty around. Little work on integration with the rest of the library is still to be done.

Future : it seems that concerning services, we’re closer to the end than ever. Anyway, there’s a huge thing missing for now : Spaces. That service is the last existing. It allows to user to interact with all the blogging stuff in the MSN/Live network. Supporting spaces would be a great plus for clients. So we’re gonna start to work on this. Nothing is done yet and there’s a lot of reverse engineering effort needed. [Update : more on this in Youness's comment]

Now a screenshot taken from the excellent Baobab, a disk usage analyzer, concerning the library directory from the rewrite :

We easily figure out that the service package represents about 56% of the whole library. This is due to the huge amount of lines of code we have to write to set a new service up. We can be glad with our SOAP stack since we now can generate anything we want in a clean enough way but services aren’t a fun part to work on : once the reverse engineering is done, you just have to follow the rules, fit the design, and you finally get your stuff working. I hope I’ll be able to contribute more on other parts of the library soon.