ff

Let's write it in advance in capital letters: THE XMPP STANDARDS FOUNDATION  IS A GREAT COMMUNITY. Anybody playing with XMPP should consider joining, since its members are very open, helpful and most of all there is talent. Without talent in fact it is impossible to deliver such a set of specifications together with working and interoperable software. Many others have produced piles of documents or made big announcements, but XSF people have been able to make the hacker born Jabber protocol to advance among the most successful and widely adopted standards in the net.  It has been fun, and though I had a very little part, I feel great thinking that part of my discussions in the ML or in the meetings may have contributed to build something that will last. 

Unfortunately in the last  year I had to spend most of my time in managing tasks and to work "underground" for developing the business of my company. Many meetings, presentations, plans, talks with possible customers, suppliers, and so on... no time to play the role of the protocol geek any more, and as a consequence my contribution to the XSF have been almost nil. For this reason I've decided not to renew my membership for the next year. Yes, our core technology will always be based on XMPP, I will continue to lurk the mailing lists, but since I think that being part of a community is also a responsibility, I don't want to renew the membership just to display a badge or not to break the record. It is also a reminder for me: since one of the things I intellectually like more is to play with XMPP and find new ways to make it better, not being a member is a way to compel myself to better balance the workload and personal life in order to find again the time get back to the XSF.

I must admit it, trying to setup a XMPP service with a good support for external network gateways is difficult. There are many reasons:

• gateways are evil; many XMPP folks righfully think that, and perhaps we should just give up and wait for the others to starve or federate... unfortunately this is not an option if you want to offer a comprehensive messaging solution, yet.
  
• people don't understand gateways, multiprotocol clients show all networks as equal, and they either allow you to connect directly to the legacy networks and to XMPP as well (eg. this is the Pidgin approach) or they force you to create a local account and they offer transparent server side gateways for everything, XMPP too (eg. the Trillian or Nimbuzz approach); so there is no notion of a main ID (the JID) and the fact that many indicate XMPP/GTalk as different entities just worsen the confusion
  
• present gateways/client implementations have tons of troubles when trying to synchronize your roster with the foreign networks

Can we make it better? I think so and the problem is the protocol used since now. Historically when subscribing to a gateway and importing the contacts, we used presence subscriptions from virtual JIDs in the gateway domain. This was not bad, but a bit clumsy since we had to accept tens or hundreds of new presence subscriptions. And it was impossible to reflect groups or other peculiar roster features (e.g. MSN handled nicknames differently from XMPP). XMPP folks then introduced a new XEP Roster Item Exchange (XEP 144) for advanced roster synchronization, allowing external entities (such as gateways) to push bulk roster additions or modifications. After having implemented few gateways and modified/used others we definitively decided not use XEP 144, since it just makes everything worse. The reason is that with XEP 144 we make an entity (the gateway) to synchronize two separate states (the XMPP and the legacy roster), and this entity can just see half of the state, since it can't read the XMPP roster. This makes it impossible to identify and recover from any error. To make things clear let's make an example.

There are five actors: an XMPP client (A), an XMPP server (B), a gateway (C) to another network (D), and a client (E)  in that network.  The state, i.e. the two rosters, is kept in B and D. A and E can modify B and D at any moment, while C must synchronize them. However with XEP 144 C can just read D, try to keep track of changes and ask A to apply them to its roster (B). C has no means to know if the changes have been applied. If A is a mobile client losing its connection while applying the changes to B, C may think that the modifications are ok and it won't resend them, making the two roster de-synchronized.

The problem is simple: for an entity it is impossible to synchronize to separate states if it hasn't read access to both of them

Which is the solution? There are at least two: give the gateways direct read/write access to the roster on the server, or start using multiple roster sources. I  pick the second one. Direct access to the roster will be possible only if the servers will start offering a standard way for interfacing with client sessions, thing that I see very difficult in a near future. Moreover this will work only for local components, because I really don't think that services like GTalk or Facebook will allow things like this. The concept of multiple roster sources has also another advantage: we don't clutter the XMPP roster with a bunch of poorly mapped external contacts, and presence propagation becomes much lighter (just one presence to the gateway, instead of one for each contact). How does it work? It's really simple:

• a user registers with a gateway and they establish a mutual presence subscription, as it happens now
• the user's client after the registration (and after each login) asks for the roster directly to the gateway (now in a new namespace, with the new XMPP specs with a direct jabber:iq:roster stanza), and it locally merges the results from different sources
• the gateway replies as if it where the server, optionally using any available optimization such as XEP-237
• the XMPP server sends presence packets only to the JID of the gateway, which replies with direct presences from all the virtual contacts in the legacy network

A new beta release of Glider for Blackberry is available for download here. What's new:

• this is the preview of the full version, where you can use any XMPP server;
• improved network connection wizard: now Glider can automagically discover and set the correct parameters for connecting from tens of  mobile networks worldwide;
• unlimited rss feeds subscriptions.

The event of the day has been the news about Facebook being granted a patent about communicating user location and status between users in a social networks. The patent itself is a nonsense, since it is utterly broad and it completely lacks of innovation: any sw engineer with enough skills would have found the same solution, and therefore it is not "not obvious" as required.

Moreover what is really amusing is that in 2007, when the patent was filed, the technology was already so common that it is almost impossible to to find prior art. Basically any GPS enabled device sending information to other devices could be prior art, but XEP-80 User Location, initially published, in 2003 really kills the patent. Just read the intro and learn the level of laziness of the patent reviewer:

This document defines a format for capturing data about an entity's geographical location (geoloc). The format defined herein can describe most earthbound geographical locations, especially locations that may change fairly frequently. Potential uses for this approach include:

• Publishing location information to a set of subscribers.

• Querying another entity for its location.

• Sending location information to another entity.

• Attaching location information to presence.

• Geographical location is captured in terms of Global Positioning System (GPS) coordinates as well as civil location (city, street, building, etc.).