Did you ever want to find out what XMPP clients people in your contact list are using? Do you want to migrate your contact list from one server to another, but don’t want to provide your password to some on-line service to do that? Do you have some XMPP-related task you quickly want to write a script for, but don’t want to deal with complex asynchronous APIs? Well, Sluift may be just the thing you are looking for!

Sluift is a Lua-based script layer on top of the Swiften XMPP library. It provides a simple API to do common XMPP tasks, either interactively (through an XMPP console), or by running a script in batch mode. In this post, we’ll go through some examples of what you can already do with Sluift today.

After Tobias Markmann told me that he was running into resource limitations with a Swiften-based tool for testing server load, I decided to do a small experiment myself. I created a small benchmarking tool, and ran it through the memory allocation profiler from Apple’s Instruments. It turned out that the combination of TLS and ZLib compression (aka “squishy data”) was causing a much higher memory usage than I would have expected.

Although the primary focus of XMPP: The Definitive Guide is explaning the XMPP protocol and all its extensions through text and illustrations, we also included a few Python code examples to help people get started with implementing their own ideas. In fact, we devoted a whole chapter to building an XMPP application, starting out with a simple bot implementation, but gradually extending the application into a full server component. For people who want to try this out for themselves, we’re releasing the source code of all code examples, including a simple echo bot, and different variants of the CheshiR microblogging platform XMPP interface.

Because Openfire has been hogging too much of my limited el-tramo.be server resources lately, and because I don’t need a beast of an XMPP server for only 2 users, I decided to replace it by the lightweight Prosody. The migration went flawless, with the help of two tools: Sleek Migrate, and a Prosody XEP-0227 Importer.

Adam Goucher and Tim Riley (Director of QA at Mozilla) announced a few months ago that they are putting together a Beautiful Testing book for O’Reilly. I took the opportunity to write a chapter about testing in the context of XMPP (more specifically, about testing protocol implementations in Swift), and just submitted the final draft for technical review. The book is expected to be released this August.

O’Reilly just sent us the cover for our upcoming XMPP Book, and it seems we got the world’s smallest ungulate: the lesser mouse-deer. I haven’t seen one in real life before, am not sure I ever want to, but still: great! Have a look below to see what the cover of the book will look like when it hits the stores in 2 months.

A while ago, the Psi development team switched from Darcs to Subversion for version control, because the Darcs pros (distributed, extremely simple and elegant) did not compensate for the cons any longer (slowness, non-scalability, ‘infinite’ merges, lack of community and tools, …). Our development was pretty central anyway at that time, so we decided that Subversion was good enough. However, we started to miss local commits more than we thought we would, and some of us are working on their own forks, which makes Subversion a suboptimal choice. We are therefore currently trying out Git as a replacement, which should bring us all the good stuff from Darcs, combined with the speed and portability of Subversion. Note that during the experiment, we will not be updating our Subversion branch any more (which will soon cause breakage, since Subversion automatically updates changes to the external Iris repository).

Although Psi has had a fair number of succesful Google Summer of Code projects so far, we have experienced some failures as well: the summer before last, 3 out of 6 projects didn’t make the final deadline. A project’s failure was typically due to not having anything really usable at the end of the summer, regardless of the good work that was done during the past months. To reduce the risk of such surprises, I decided to take an Agile Development approach for this year’s ‘Roster improvement’ project.

The day before yesterday, Peter Saint-Andre sent out a couple of Jaiku invites to all Jabber Google Summer of Code students and their mentors, including me. Never having looked at microblogging before, I toyed around with it a bit, and it quickly reminded me that I still had something on my Psi wish-list for a while now: a flat, live log of all Jabber events in your network. Since I had a long weekend, I quickly coded up a prototype, and hooked it into Psi.

For a while now, Psi users have been requesting several changes and additions to the roster (or ‘contact list’). These requests include grouping contacts into meta-contacts, nested roster groups, and displaying user avatars in the roster. We have been postponing all these changes to the roster as much as possible, because none of us wanted to touch the roster code, for reasons I’ll explain below. This year, Psi is fortunate enough to have Adam Czachorowski (aka Gislan), a student from the Google Summer of Code, to work on roster improvements.

After a short hiatus, I finally resumed work on my new Jabber/XMPP client project, which I christened ‘Greem’. The main goal of the project is to create a mobile Jabber/XMPP client for the Qtopia platform. The nice thing about Qtopia is that its target audience keeps on expanding: besides running on the GreenPhone (of which Trolltech was kind enough to provide me with one), Qtopia has recently been ported to the Neo 1973 (OpenMoko), and even Windows CE and Windows Mobile. In this post, I briefly describe what the expectations and the goals are for Greem, and how Psi fits into the picture.

While the last bugs are being squeezed out of Psi 0.11’s release candidates, work on 0.12 has already begun. One thing I’m excited about as a developer is the fact that we’re making the Psi codebase ’testable’, which has some nice consequences.

It is time for us to be honest: the reason Psi has not had a release in the past year and a half is because we have secretly been working on one of the most controversial and least implemented features in the Jabber world: XEP-0076 (Malicious Stanzas). We have allocated two full-time developers for achieving this: Machekku has done the groundbreaking work, implementing the main processing loop, statistic gathering, and user interfaces for this type of stanzas, whereas I have been concentrating mostly on backend issues. Although our work is still in a highly experimental stage, we decided to release the full source code in order to get useful feedback from the community. Besides a Psi implementation, we also provide an Openfire server-side implementation for malicious stanza tagging as an extension of the content filter, targeted at fixing non-XEP-0076-compliant behavior of entities.

We recently made Psi’s dialogs related to account creation, registration, and modification a bit easier to use. The account registration process is now a wizard-like dialog, where a user first needs to select a server (from a centralized on-line list), and then needs to provide the information requested by the server (according to XEP-0077: In-Band Registration). We have also introduced new default settings that should avoid the need to tweak any account settings when adding an existing account. This means that you should be able to log into any XMPP server (including Google Talk) just by entering your JID and password. Some more details and screenshots below.

After gathering dust for a few months in some deep and dark corner of my hard disk, my vCard-based Extended Presence plugin for Openfire is now publicly available here.

This weekend, mblsha and I had a coding sprint to make Psi XMPP-compatible, hoping to be in time for the XMPP interop event. Although we didn’t make it physically to the event, we still managed to get Psi compliant.

I have to confess, i’m kind of a fan of very simple Jabber clients that do not overwhelm you with menuitems, toolbars, and options. This is why i like clients such as Google Talk and iChat so much. I always hoped Psi could one day be such a simple client, but the fact is that we have a very broad userbase, of which many are power-users that do not want to give up any option or feature whatsoever. I never really understood why people needed to send plain messages (instead of chats) in IM, why there is such a thing as ‘Extended Away’ and ‘Free for chat’ in a chat system where you have status messages, why someone would want to hide contacts that are ‘Away’, and the list goes on. However, we’ve had many discussions about this before, and the conclusion is always that someone on this planet wants this, so we never touched these (IMO) silly features. Until now …

The Psi feature frenzy continues! With my PhD draft text delivered last week, I finally had some more time over the weekend to implement some neat stuff. And not just any stuff: after many years of being blamed for not keeping up with the times, we finally have support for JEP-0045 (Multi User Chat) in our mainline development branch. Sure, maybe some small aestetic modifications can still be done here and there, but all of the functionality should be there. This means you don’t have any excuse whatsoever to be anti-social anymore, so start joining all the fun chatrooms such as psi@conference.jabber.ru.

As some of you probably know, the upcoming 0.11 version of Psi will have remote controlling capabilities. For those of you for which this is new information, or for people that have a hard time imagining what this feature exactly does, I created a screencast (requires QuickTime) showcasing the current list of available commands (and more).

There has been a slight shift in the roadmap of Psi. While the only goal of 0.11 was to port it to Qt4 (do i hear a booooring somewhere?), we decided to make 0.11 also fully XMPP-compliant. We therefore merged the current ’next generation’ branch (which amongst others supports privacy lists) with the mainline development branch. A consequence of this is that other features were pulled into mainline as well (yay!), so it’s not unacceptable to start looking forward to the next release.

A few weeks ago, Tom Germeau from MozChat brought to my attention that recent clients such as Google Talk, Gajim, Pandion (and of course MozChat) are all using JEP-0085 (Chat State Notifications) for doing ‘Contact is typing …’ notifications. There have been many discussions in the past on whether or not to prefer this JEP over the old JEP-0022 (Message Events), which most of the other clients out there implement. This is why Psi didn’t implement chat sates yet. However, we recently decided to put this (cleaner, standards track) JEP into our mainline development version after all.

Magnus Henoch announced a few days ago that he was working on an ejabberd implementation for JEP-163 (Personal Eventing Protocol), the protocol formerly known as SPPS. I found a bit of spare time today to finish the real (as opposed to pseudo-) PEP implementation in Psi, while Magnus fixed some things on the server side. The implementation isn’t available publically yet (since no server supports it anyway), but interested server developers are of course always welcome to ask for a snapshot.

We’re currently working on putting JEP-0163: Simplified Personal Publish-Subscribe into Psi. A result of this work, together with an implementation of User Tune as our use case, can be seen in action here.

TuneController is a modular plugin-based Qt interface for talking to media players such as iTunes, XMMS, and WinAmp. The provided functionality is currently limited to notifying of player state and song changes, but other features (such as remote controlling, queueing, …) will be added in the future.

Support for JEP-115 (Entity Capabilities) has just hit the Psi mainline development branch. This doesn’t mean much to the user, except that it can display the client version of contacts without the burst of client-version queries each time you connect. However, there is still the overhead of the extra tag in every presence packet sent and received, but stream compression (either through TLS or using JEP-138) should take care of this in the future. JEP-115 also describes a server optimization to reduce traffic, but as far as we know, no server implements this. We hope that if more clients start supporting entity capabilities, the servers will follow as well.

Good news to start the year: the new Psi Qt4 branch has been made public as a new year gift. Yes, another branch of Psi to keep track of, and I have a feeling that this won’t be the last one either ;). For those interested, I wrote something together about the new soon-to-be-mainline-development branch.

I finally got around to doing some more privacy list work for Psi. After porting what i had to our soon-to-be-released Qt4 branch, i even managed to add some more functionality. Basically, what I have so far can be seen here (minus the ‘Add’ button in the rules list).

As many of you know, Psi has been using Darcs for version controlling since the development of 0.10. However, although Darcs works on most platforms, some people have been experiencing problems with getting Darcs to work for them. Because of this, and some other inconveniences (not being able to checkout subdirectories of the development tree, long checkout times, the lack of a scalable web-interface, …), we have decided to create a Subversion mirror our development repository (using Tailor).

As Google released a new version of libjingle last friday, I decided to experiment with their file transfer implementation in Psi this weekend. I added some code that allows someone to accept files sent by Google Talk, and tested it with a few Google Talk contacts, with a perfect success rate (so far). For the brave who wish to experiment with this, see the instructions below. Note that this code is unofficial, untested, only uses a very rudimentary UI (there is no integration with the existing file transfers), still suffers from at least two bugs (on Mac OS X: one that segfaults when receiving images, and one where CPU skyrockets to 100% after a while, which we had with older libjingles as well), and has no support from the Psi developers whatsoever. Comments should therefore go directly to me.

Jason Kim, who previously designed the Psi logos and the Stellar iconset, has drawn a new Stellar icon. Combining his shiny icon with the overlays from the Crystal iconset resulted in the new Stellar3 iconset, which you can see in action below. The new iconset, which is still subject to small changes, has been added to the Psi mainline development branch.

We reported earlier about our work on finally bringing Psi up to speed with the XMPP standard. Because of necessary changes in QCA2, this could only be tested through the nightly Mac OS X and Windows builds we provide. Today, we merged a patched version of QCA2 into the Psi mainline development branch, making it possible for everyone to compile Psi with XMPP1 support (enabled by default).