On Android in the past two years I have tried them all, including notables such as Jabbdroid, Beem, Jabiru, Yaxim, Emess and many others not even worth citing. Some of them are hampered by a slow graphical user interface, some deplete batteries in a hurry, some lack features I consider essential, some even crash on receiving a message and not a single one is capable of remaining connected while the radio segment hops from GPRS to UMTS to Wi-Fi and back again… They won’t even try to reconnect – leaving me slack-jawed at the lack of such a basic feature when there is even a standard Android class that notifies applications when network connectivity changes.

Enter Xabber – it does everything I expect from an Android Jabber client. Yes, it really does – you can drop that unbelieving face. I’ll spare you the whole features list… Let’s just focus on what I was looking for :

• Permanent tray icon as link to contacts lists
• vCard based avatars
• XMPP priorities
• Groups
• Contacts list management
• TLS/SSL support
• Full Unicode support
• Chat history
• Parameters for just enough customization
• Multi User Chat – you can even join multiple rooms
• Does not deplete the batteries too quickly
• Reconnects promptly after each disconnection while the radio segment hops from GPRS to UMTS to Wi-Fi and back again

As a bonus it publishes geographical location, but I have no idea where it gets it from, nor if it is supposed to implement XEP-0080.

Don’t you love the feeling of discovering a new application and finding that it behaves the way you expect, as if the developers had been reading your mind and making helpful suggestions about the fuzzy parts of what they had read ? On Android K-9 Mail is the only other example I can think about… Yes, Xabber is that good.

The only downside of Xabber is that the code is not free… The site does not even mention a license. So you don’t know what lies hidden inside, you can’t modify it and you are at the mercy of the developer changing his mind and starting to ask for money for further versions. But even as a Free software fanboy I’m willing to live with that for now – I’m so relieved to at last have something that works.

From now on, expect to find me online while I’m on the move !

Edit 20130130 – Xabber is now Free Software !

Enter OneSocialWeb, a free, open and decentralized XMPP-based social networking platform with all the federated goodness one might expect from an XMPP-based system. Sounds good doesn’t it ?

Laurent Eschenauer is a software engineer at Vodafone Group R&D and he is the architect of OneSocialWeb – the team also has Alard Weisscher, Lorena Alvarez and Diana Cheng on board. Today he posted great news about OneSocialWeb at Vodafone’s RndBackyard :

“Two months ago, we introduced you to our onesocialweb project: an opensource project that aims at building a free, open, and decentralized social networks. We explained the idea, we showed what it looked like, and we answered many questions. However it was only a prototype running on our servers, there was no such federated social network.. yet.

Today, we have released the source code and compiled versions of the core components of our architecture. With this, you are now in a position to install your own Openfire server, load our Onesocialweb plugin, and you will immediately be part of the Onesocialweb federation. We also provide you with a command line client to interact with other onesocialweb users.

As you see, we are not releasing the web and android client today. They will require a bit more work and you should expect them in the coming weeks. This means that this first release is mainly targeting developers, providing them with the required tools and documentation to start integrating onesocialweb features in their own clients, servers and applications.

This is a first release, not an end product. Our baby has just learned to walk and we’ll now see if it has some legs. We look forward to keep on growing it with the help of the community. Please have a look at our protocol, try to compile the code, and share your feedback with us on our mailing list. You can also have a look at our roadmap to get a feel for where we are going”.

Laurent only mentions Openfire and the OneSocialWeb plugin for Openfire is the only one currently available for download on OneSocialWeb’s site, but despair not if like me you are rather an ejabberd fan : “Its protocol can be used to turn any XMPP server into a full fledged social network, participating in the onesocialweb federation“. So if everything goes well, you may bet on some ejabberd module development happening soon. And who knows what other XMPP servers will end-up with OneSocialWeb extensions.

There were some news about OpenSocialWeb about two month ago, but that was unlucky timing as the project’s message got lost in the Google Buzz media blitz. Anyway, as Daniel Bo mentions : “Many years of discussion have gone into determining what a federated social network would look like, and the OneSocialWeb doesn’t ignore that work“. Indeed, as the OpenSocialWeb mentions, it “has been built upon the shoulders of other initiatives aiming to open up the web and we have been inspired by the visionaries behind them: activitystrea.ms, portablecontacts, OAuth, OpenSocial, FOAF, XRDS, OpenID and more“. Only good stuff there – an open standard built on top of recognized open standards is an excellent sign.

All that just for microblogging ? Isn’t that a slight overkill ? Did we say this was a microblogging protocol ? No – the purpose of OneSocialWeb is much more ambitious : it is to enable free, open, and decentralized social applications. OneSocialWeb is a platform  :

“The suite of extensions covers all the usual social networking use cases such as user profiles, relationships, activity streams and third party applications. In addition, it provides support for fine grained access control, realtime notification and collaboration”.

Two weeks ago, Laurent attended DroidCon Belgium and he explained how OneSocialWeb will enable developers to create social & real-time mobile applications, without having to worry about the backend developments:

“In my view, this is one of the most exciting element of our project. Beyond the ‘open’ social network element, what we are building is truly the ‘web as a platform’. An open platform making it simple to create new social applications”.

Here are his slides from DroidCon Belgium :

Is it a threat to Status.net ? No : being an open protocol, it can be used by any system willing to interoperate with other OneSocialWeb systems. @evan has expressed interest about that and I would trust him to hedge his bets. OneSocialWeb certainly competes with Status.net’s ambitious Ostatus distributed status updates protocol, but whichever wins will be a victory for all of us – and I would guess that their open nature and their similar use-cases will let them interoperate well. Some will see fragmentation, but I see increased interest that validates the vision of an open decentralized social web.

By the way, if you have paid attention at the beginning of this article, you certainly have noticed that Laurent’s article was posted at Vodafone’s RndBackyard. Yes, you read it right : OneSocialWeb is an initiative of Vodafone Group Research and Development to help taking concrete steps towards an open social web. Now that’s interesting – are big telecommunications operators finally seeing the light and embracing the open instead of fighting it ? Are they trying to challenge web services operators on their own turf ? My take is that this is a direct attack on large social networking operators whose rising concentration of power is felt as a threat by traditional telecommunications operator who have always lived in the fantasy that they somehow own the customer. Whatever it is, it is mightily interesting – and even more so when you consider Vodafone’s attitude :

“We by no means claim to have all the answers and are very much open to suggestions and feedback. Anyone is invited to join us in making the open social web a reality”.

“We consider it important to reality check our protocol with a reference implementation”.

They are humble, they are open and they are not grabbing power from anyone but walled garden operators : this really seems to be about enabling an open decentralized social. I have such a negative bias about large oligopolistic telecommunications operators that I would have a hard time believing it if I had not had my understanding of the rational behind one of them funding this effort against the likes of Facebook… But free software and open protocols are free software and open protocols – wherever they come from !

As Joshua Price discovered Juick almost a year before me, I’m going to recycle his introduction to the service – he paraphrases Juick’s help page anyway :

Juick is a web service that takes XMPP messages and creates a microblog using those messages as entries [..] There’s no registration, no signup, no hassle. You simply send a XMPP message to “juick@juick.com” and it creates a blog based on the username you sent from and begins recording submissions.

1. Add “juick@juick.com” to your contact list in your Jabber client or GMail.
2. Prepare whatever message you want juick to record
3. Send your message

That’s it. Juick will respond immediately telling you the message has been posted, and will provide you with a web address to view your new entry.

The simplicity of an account creation process that sniffs your Jabber vCard is something to behold – I makes any other sign-up process feel ponderous. This poor man’s OpenID Attribute Exchange does the job with several orders of magnitude less complexity.

Almost every interaction with Juick can be performed from the cozy comfort of your favorite XMPP client – including threaded replies which are something that Status.net’s Jabber bot is not yet capable of handling (edit – thanks to Aaron for letting us know that Status.net’s Jabber bot has always been able to do that too). And contrary to every microblogging service that I have known, the presence information is displayed on the web site – take a look at Nÿco’s subscribers for a example.

The drawbacks is that this is a small social network intended for Russophones, and the software is not free. But still, it is an original project whose features may serve as inspiration for others.

For some technical information about Stoyan Zhekov‘s presentation :

When Google opened Google Talk, they opened the service to XMPP/Jabber federation. As a new entrant in a saturated market, opening up is the logical move.

The collaborative messaging field as a whole cannot be considered saturated but, while it is still evolving very fast, the needs of the early adopter segment are now well served by entrenched offers such as Twitter and Facebook. Touching them will require an alternative strategy – and that may lead to opening as a way to offer attractive value to users and service providers alike.

So maybe we can cling on a faint hope that Google’s entry into the microblogging field will support decentralized interoperability using the OpenMicroBlogging protocol pioneered by the Status.net open source micro messaging platform. Shall we take a bet ?

Don’t you love bar talk speculation based on anonymous rumors ?

A year later, strictly nothing had happened, and that silence has not gone unnoticed. Facebook has not even issued the slightest announcement, except a wishlist bug report comment by Charlie Cheever mentioning that “some people are working on this.  It will probably be done in a few months. Sorry the timeline isn’t more clear“.

But today the people at ProcessOne noticed that preparations for an opening have reached an advanced stage that hint at the imminence of a public XMPP service :

It now seems the launch is close as the XMPP software stack as been deployed on chat.facebook.com, as our bot at IMtrends have found out: chat.facebook.com on IMtrends.

The biggest question that remains is whether federation is on the menu. By federating with Google Talk and the rest of the XMPP world, Facebook has an opportunity to make a huge splash in instant messaging with 300 million users at once and deal a heavy blow to Yahoo and Microsoft. Will the partial ownership of Facebook by Microsoft keep them from interoperating ?

I would love to be able to chat with all those Facebook friends who will never use a chat client that was not pushed by a mass market service provider. So far, Facebook has always chosen the closed way – opening its service to a federation would be a first. I’m eager to see if Facebook can take this golden opportunity to surprise us in a good way.

A year later, strictly nothing happened, and that silence has not gone unnoticed. Facebook has not even issued the slightest announcement, except a wishlist bug report comment by Charlie Cheever mentioning that “some people are working on this.  It will probably be done in a few months. Sorry the timeline isn’t more clear“.

Is that all that a major player such as Facebook can do to interoperate with the rest of the instant messaging world ? Words with no deeds to back them up are very disappointing, especially from a player with ample means. Annoucements followed by complete silence are an even bigger blow to anyone’s credibility. Will Facebook step up to the plate ?

By federating with the rest of the XMPP world and especially with Google Talk, Facebook has an opportunity to make a huge splash in instant messaging in a rare case where their interests are aligned with their user’s. Why the silence ?

Maybe I should not be using Facebook at all. But it has been so successful at attracting the family, the non-geeks and the girls that I have settled for the compromise of using it while serving some constructive criticism. But I feel better at Identi.ca and Friendfeed…

People come to IRC channels such as project channels to meet the whole group. But just as often they come there to hang out with acquaintances, which they find spread accross various channels. Wouldn’t it be great if each user could have his own channel with just his friends ? This is what microblogging is : a people aggregator, just as any feed aggregator but for the people you want to follow.

I have had a hard time so far trying to convince my IRC addicted friends that we should use a Jabber MUC chat room in lieu of our usual IRC channel. Jabber MUC is superior to IRC in every way possible, but as much as we like to rail against the common user’s inertia to technological adoption, we are sometimes no better.

I believe that the problem was that Jabber MUC provides only marginal incremental improvement to their usage. And adopting a microblogging service is a huge stretch from their current use cases. I have therefore long been dreaming about a chat interface to microblogging that would meld the social power of microblogging and common chat usage patterns into a workable migration path for my IRC addicted friends. And there it is :

Neat isn’t it ? Jack Moffit mentioned it evasively in his article about filtering the realtime web and it piqued my curiosity.

From a user’s point of view, Identichat is about joining the Jabber multi-user chat at your_identica_user_name@identichat.prosody.im and you’ll immediately find yourself in a standard MUC room where the participants are your Identi.ca subscribers. The conversation is the microblogging stream that you would normally get at Identi.ca.

If you try to enter a notice, a help message in the chat window points out that ’You can register using your identica account by sending !register username password’. Do that – not ‘/register’ as I mistakenly typed out of IRC habit – and you are set to use Identi.ca as any chat tool.

How is that different from a graphical Laconica client ? It is not a Laconica client, it is plain XMPP MUC that about every decent XMPP client supports. As you may know, there are Jabber clients for about every platform you can imagine including mobiles – even some like Mcabber which provide a user interface which will make the console IRC user feel at home. Identichat is not just another client, it is a gateway to a whole world of existing XMPP clients so that every user can use his favorite.

Identichat will help Laconica by eroding chat user’s resistance to change. And it could also foster new uses of microblogging as a thick client enables considerably accelerated interaction compared to a web interface. For now it could be faster – the turnaround latency is perceptible compared to IRC or XMPP MUC, and a helpful “line too long” message would be better than “Send failed : error 406″. But I’m nitpicking : Identichat is a wonderful tool that gives new faces to the microblogging infrastructure. An infrastructure that can show different faces to different classes of users has a great future !

But even if they add technical value in the growing world of geographically aware applications, theses services are actually not innovative at the functional level. For example, in the ham radio universe, APRS is already a great system for real time tactical digital communications of information of immediate value in the local area – which includes among other things the position of the participating stations. And there is also TCAS, which interrogates surrounding aircrafts about their positions, and AIS which broadcasts ship positions and enables the entertaining Vessel Traffic Services such as the one provided by MarineTraffic. All these radio based systems broadcast in the clear and are not satisfying the privacy requirements of a personal eventing service. But that problem has also been solved by the Blue Force Tracker which even though it is still a work in progress has already changed how a chaotic battlefield is perceived by its participants.

“Where am I, and where are my friends ?” is not only the soldier’s critical information – it is also an important component of our social lives, witness the thriving landscape of geosocial networking. Geographic location is a fundamental enabler : we are physically embodied and the perimeter of location based services actually encompasses anything concerning our physical presence. So we can’t let physical location services escape our control. Fire Eagle may be practical for now, but we need to make geographical information part of the basic infrastructure under our control and available on a standardized, open and decentralized basis. The good news is that much thoughts have already been invested into that problem.

Physical location is part of our presence, and as you may have guessed by now, this means XMPP comes to the rescue ! We have XEP-0080 – User Location, an XMPP extension which is currently a XMPP Foundation Draft Standard (implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard – as good as a draft standard RFC and therefore good enough for early adopter use). It is meant to be communicated and transported by means of Publish-Subscribe or the subset thereof specified in Personal Eventing via Pubsub. It may also be provided as an extension of plain vanilla <presence/> but that is quite a crude way to do it compared to the Publish-Subscribe goodness.

The rest of the work is left to the XMPP client. Of course, the client can show them on a map, just as Brightkite currently does. But I can also easily imagine an instant messaging contact list on my PDA where one of the contact groups is “contacts near me”. I would love to have Psi do that…

Today we have the same situation with social networking. And while the technological prerequisites for open microblogging have been almost there for a while, they have not yet cristalized into something that can be fed to the masses. That day will come – and we are all pushing toward it. Until then, I have a Facebook profile. But soon I know that I’ll be able to tell the world that my social networking tool is my blog, or whatever other tools I fancy moving to and from thanks to data portability efforts. And it’ll be easy for others to do the same because interoperable services will blossom at the hands of mass-market providers – maybe even Facebook if they ever reach enlightenment. And when that is about to be ready for massive adoption, you know where I’ll be – and you know where I’ll not be anymore !

To me there is an element of religion in those choices. But the techno-apathetic average user can make the same choices out of pure self-interest. If there are a number of comparable offerings on the market, one of which lets the buyer choose between different suppliers and move between them at will, you can bet that the one-time cost of moving away from the proprietary offering will be more than offset by the future value of the open solution. If we look at the history of technologies, examples of such migrations are plenty. Let’s just take e-mail for example : what is the current weight of closed mail systems ? They still exist, but they are insignificant niches and many of them use e-mail for notification…

Of course this is still far from the holy grail of a presence-centered converged synchronous communications platform, but it is a start and anything is better than today’s stupid mass-market telephony.

Here is my /etc/asterisk/jabber.conf :

[general]
;Auto register users from buddy list
autoregister=yes

;Jabber service label
[asterisk]
type=client
serverhost=jabber.grabeuh.com
username=asterisk@jabber.grabeuh.com/kisangani
secret=my_password
port=5222
usetls=yes
statusmessage="Watching the telephone"

Yes, that’s it : Asterisk is now registered as a Jabber client. There are other ways to do it using external modules, but this one is the simplest – and since it is now part of the main trunk it is probably the most stable. In particular you should be careful with class.jabber.php which is not maintained anymore and in the process of being replaced with the much more modern XMPPHP.

Now let’s declare a macro for taking full advantage of that. This one takes a look at the user’s presence and routes the call accordingly : if he is online or chatty the call goes to his desk phone – otherwise it goes his mobile phone.

[macro-reach_user]
; ${ARG3} is a destination such as SIP/whatever
exten => s,1,jabberstatus(asterisk,${ARG2},STATUS)
; presence in will be 1-6.
; In order : Online, Chatty, Away, XAway, DND, Offline
; If not in roster variable will = 7
exten => s,2,gotoif($[$[${STATUS}]<3]?available:unavailable)
; GotoIf(condition?label_if_true:label_if_false)
exten => s,3(available),jabbersend(asterisk,${ARG2},"Call from
 ${CALLERID(name)} at number${CALLERID(num)} on
 ${STRFTIME(,GMT-1,%A %B %d %G at %l:%M:%S %p)}")
exten => s,4,Dial(${ARG1})
exten => s,5(unavailable),Dial(${ARG3})

Since we have declared a macro, we have to call it in the context of our choice and assign the relevant values to the macro’s variables :

[whatever_context]
; ${ARG1} is the destination when at desk
; ${ARG2} is a jabber address used at desk
; ${ARG3} is the destination when not at desk
exten => 05600047590,1,Macro(reach_user,SIP/jml-desk,
 jim@jabber.grabeuh.com, SIP/freephonie-out/0666758747);
; repeat last line for each user

That’s all folks ! That is all it takes to have your calls routed to the right phone according to your presence status. It is really that easy.

Why no service provider is offering that is beyond me. The big ones are all waiting for the IMS systems they are going to deploy with a five years roadmap. But if you want the future right now there is no need to wait : all the technology is here today waiting for you to play with it ! And of course it is 100% Free software…

Techchrunch reported that “over the last few days a number of popular bloggers have complained, loudly, that it’s time to ditch Twitter and move to a decentralized version of the service that won’t go down every time usage spikes“. But I could not care less about that : I am not even a Twitter user. But I think there are good uses for micro-blogging and social instant messaging, so I want a free and open solution. That means decentralization in the classical Internetworking style.

PEP is defined “XEP-0163: Personal Eventing via Pubsub“. And Pubsub is defined by “XEP-0060: Publish-Subscribe“. So far so good. But digging around a bit I learned about “XEP-0118: User Tune” and then it dawned on me that there appeared to be room for improvement : the script outputs a composite “tune” element which is a radical simplification of the schema specified in XEP-0118.

So I had a go at modifying the script to get it as close to the specification as possible. You can judge of the resulting output for yourself : not quite XEP-0118 compliant but a good step in that direction.

The source code is available from the usual dump, but if you are an Amarok and Psi user you might actually want to use the Amarok script package that installs and runs in a coupe of clicks – thanks to the previous authors whose work I built upon.

While I was at it I discovered a bug that causes Psi 0.11 to use the element tag “source” to contain the album information, so I promptly provided the psi project team with the trivial patch needed.

It is is 3:30 AM and a few hours ago I did not realize that upgrading Ejabberd would get me that far for today…