I have owned an an HTC “G2″ Magic for almost two years and one of my biggest disappointments with the Android operating system has been my inability to find a decent Jabber client. On the desktop, my love of Psi has been going on for half a decade but my encounters with mobile Jabber clients have been nothing but disappointments.

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 !

This week-end I noticed Juick, an XMPP-based microblogging system with some nice original features. But Juick is not free and its author does not seem interested in freedom. So who’s gonna save XMPP-based microblogging ?

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 !

I don’t quite remember how I stumbled upon this page on Nicolas Verite’s French-language blog about instant messaging and open standards, but this is how I found a microblogging system called Juick. Its claim to fame is that it is entirely XMPP based. I had written about Identichat is a Jabber/XMPP interface to Laconi.caStatus.net – but this is something different : not merely providing an interface to a generic microblogging service, it leverages XMPP by building the microblogging service around it.

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 :

According to a report from the Wall Street Journal mentioned by ReadWriteWeb, Google might be offering a microblogging service as soon as this week.

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 ?

On 13th May 2008, Facebook announced ”Right now we’re building a Jabber/XMPP interface for Facebook Chat. In the near future, users will be able to use Jabber/XMPP-based chat applications to connect to Facebook Chat“. The news has been greeted positively in various places everywhere.

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 ago this day, Facebook announced “Right now we’re building a Jabber/XMPP interface for Facebook Chat. In the near future, users will be able to use Jabber/XMPP-based chat applications to connect to Facebook Chat“. The news has been greeted positively in various places everywhere.

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…

Chat is supposed to be realtime conversation – and it often is. But just as some corporate victims live in Outlook (that abortion that Microsoft shoves down user’s throat as an excuse for a mail client) some fellow geeks live with an IRC screen at hand. Those people use IRC for realtime conversation, but not only. Soliloquy is widespread, and having a client with at least half a dozen tabs that are as many parallel conversations is a common occurence. IRC users were microblogging before the term was coined and web interfaces imagined.

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 !

I have become a user of Brightkite, a service that provides situational awareness in the geographical context. Once its relationship to user location information sources such as Fire Eagle improve, it may become a very nice tool, especially in mobile use cases where location reporting may be partly automated.

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…

Some people notice I am quite dogmatic about open networks. And they are right : to me, open is everything and the rest is details. But even my zeal has its limits : I don’t gratuitously shove tools in the face of people who can’t use them in practical conditions. I have been advocating jabber among my technically minded friends since 2001 and running my own server since 2003, but it took Google joining the XMPP network in 2006 to actually make it a viable option for pushing open instant messaging to the masses of people I don’t want to support myself. Before that I could understand the necessity for joining proprietary networks and run multiprotocol clients to reach people I could not decently drag to Jabber or IRC. But now I can tell them that getting presence information and instant messenging from me is just a Google account away – and since it is a mainstream service offered by an established and well known service provider they can hardly anymore label me a techno-excentric for using it. So – no I will not join your proprietary instant messaging network.

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…

Since version 1.4, a Jabber module is available in Asterisk. If you know me, then you probably wonder why it took me that long to discover it. I began playing with it tonight and the short story is that it works, it is simple to configure and it makes telephony aware of presence.

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…

Openness is everything – the rest is details. The technology is there and people have been talking about it for more than a year. Let’s bow to the inevitable : just as Compuserve, AOL, The Source, Prodigy and their ilk have all dissolved in the Internet, Twitter will find a decentralized replacement. And let’s make the inevitable happen by pushing XMPP !

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.

Now that in its 2.0 incarnation Ejabberd supports publish-subscribe and therefore personal eventing, it is time to play with it and demonstrate to the wider world the marvellous use-cases that the future holds. A nice first one that should be popular and therefore useful for propaganda purposes is using Psi so that contacts can see in your presence status the music that you are playing. I stumbled upon an Amarok script that notifies Psi’s through the tune file interface and lets Psi publish the currently playing song status via PEP – and it looked good.

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…

Owners of and AOL Instant Messenger can now use the service from Gmail. You may be surprised to learn that I consider that this is bad news. All the hype about interoperability between the two networks is just that : hype. This is not interoperability, this is just using Google as a multi-protocol client. In short, it merely hides the problem under the rug and further legitimates the fragmentation of the instant messaging world. I expected something more ambitious from Google. I thought that by opening their network to the Jabber galaxy, Google had made a statement in support of interoperability and open networks. But apparently this was just a way to embrace their competitors. I hope that users will some day understand the value of openness and demand it from their suppliers. They once did it for email and for internetworking – let’s hope the miracle happens again for instant messaging. Meanwhile, make sure that friends don’t let friends use closed networks !

Most social tools come and go. The ones that stay share a common feature : openness. For example, email is open : chose any technology, chose any provider or be your own provider, chose any client, any platform – any way you do it you are still connected to the whole world.

If you have the slightest understanding of your own interest, then there is no way you should even consider using a closed platform as your primary mean of communication. Why would you willingly chose to put your most critical asset outside of your control ?

Many users will object that they gladly surrender control to closed social networking platforms because plain email does not meet their sophisticated communications needs and they are not willing to invest in developing the skills currently required to participated efficiently in the blogging sphere. That is a tragedy because the social graph is quickly becoming the glue of the connected services.

And even if the functionality was sufficient, we would still have a huge mindshare gap to bridge. XMPP provides nice basic instant messenging and presence management in an open environment, but most users still prefer proprietary centralized networks and happily trade freedom for webcam compatibility.

But similar battles have been fought and won in the past : Compuserve, AOL, The Source, Prodigy and their ilk have all dissolved in the Internet. The forces of openness now have a new crusade to embark upon : we must take the best use cases of the closed social networking world and port them in the open !

Open is everything – the rest is details. That is what drew me to the Internet fifteen years ago.

As some of you may know, I have no fondness whatsoever for proprietary platforms. The mere thought of joining a proprietary instant messaging network sends shivers down my spine : to me the freedom of a decentralized infrastructure is essential and that is why I am a Jabber user. So by now you surely already know what my opinion of Twitter is.

As B. Mann mentions in “Twitter is Jabbber”, XMPP provides Jabber with all the message routing functionnality needed. He adds that “it has a publish and subscribe architecture built in, rather than all these crazy desktop apps that constantly poll the Twitter mothership“.

On top of that, XMPP Extensions enable plenty of functionality to match and surpass Twitter‘s. For example, XEP-0108 “User Activity” defines “an extension mechanism for capturing “extended presence” data about user activities, above and beyond availability“. An XML snippet is worth a thousand words :

<activity xmlns=’http://jabber.org/protocol/activity’>
<relaxing>
<partying/>
</relaxing>
<text xml:lang=’en’>My daughter’s birthday!</text>
</activity>

So let us see what makes Twitter so successful.

First we have mobility. Again B. Mann explains that “my only explanation for the Twitter craze is that North Americans are still enamored of anything that can do the tiniest bit of mobile integration. Yes, Twitter has managed to scale and spend many thousands of dollars paying for SMS gateways“. Sure there are Jabber SMS transports and they are usable from a phone, but you can’t beat free.

But I believe the reason for Twitter‘s success is web integration. Sure, Jabber notifications are provided by many collaborative tools, and there are ressources to make your own such as class.jabber.php, a Jabber library for PHP that I used to build Jabber presence indicator in a web page. But indeed they do not match the level of functionnality that Twitter provides out of the box. We need more web based Jabber clients – that is an interesting area that I’m quite tempted to delve into.

So the proprietary hydra has sprouted one more head, but our swords are far from dull and the jihad shall be eternal !

A while ago I built a Jabber presence indicator on my personal web page by customizing one of the examples provided with class.jabber.php. I have received enthusiastic feedback from a handful of users – that makes me feel warm inside ! Do not neglect the ego of people who provide free services, be they Free software developpers or volunteers for anything : a kind comment or a nice stroke in the right direction go a long way toward feeding their motivation. So next time you enjoy the produce of the gift economy be sure to let people know how much you liked it !

With the kind words came a question which made me aware that a newcomer may not find the required configuration as obvious as I do. One of the least obvious steps is telling the script whose status it is supposed to check. Don’t look for a JID parameter inside the presence indicator script : the presence indicator script itself knows nothing about the user whose status it checks. It is the watcher bot user that has the watched user on his roster. The presence indicator script will return the status of anyone on the watcher bot user’s roster. That makes it quite flexible because it will work for any number of users.

If anything remains unclear to you, please be sure to report it to me.