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.

Gaim being evicted from my workstation I went shopping. Gabber and Gabber 2 are no longer developped so that rules them out. Tkabber seems to serve the Jabber hackers well and I found it featureful and highly configurable - I keep it on my shortlist but it does not have the look and feel I am looking for. Gajim looks sweet and solidly gnomish but still a bit wet behind the ears and too simple for my taste. Finally, from my highly subjective point of view it is Psi that strikes the right balance with its good compromise between configurability and simplicity, its excellent coverage of Jabber functionnality and a look and feel to suit my taste. And as a bonus, Psi is available on both Windows and Linux with excellent consistency and Psi will soon feature Jingle. I’m sold !

Gaim does not let the user set the priority of the Jabber client on his workstation. Since I use three different workstations (home, work and mobile), setting Jabber priority is essential so that I get my messages at whichever station I happen to sit or on my mobile when I am not sitting at a desk. So I need another Linux Jabber client…

On my Windows XP workstation at work I found that when receving a message in not yet clearly defined conditions which probably include the message not being aknowledged by the user, Exodus provokes the occupation of about 1 GB of swap space and makes the whole system slow down to a crawl. I went opening a bug report but someone already reported a bug that looked identical to me. So anyway I need another Windows Jabber client…

Nathan Fritz reports Lars Mikkelsen patching class.jabber.php to support Google Talk. Nathan is reviewing the patch and considers including it in a next release of class.jabber.php.

So we learn simultaneously that class.jabber.php does not support Google Talk and that it soon will…

When I open a chat with a contact from any client, I want to see our past conversation. Jabber server-side message archiving capable is what I need to really make instant messaging the tool it should be. Being a long time user of Dircproxy, an IRC proxy that does just that, I sorely miss it when using Jabber. Now that Google Talk features “Chat History” the clamor from the masses is growing for implementations of Message Archiving as described in JEP-0136.

Right now the only choice seems to be Datasink, an external component that implements Message Archiving (JEP-0136). It is theoritically pluggable into any Jabber server. There is a good recipe for installing Datasink along Ejabberd. But client support is lacking : apart from JWChat I have not found a single client supporting the functionnality provided by Datasink. As the author of Datasink says : “Datasink uses MySQL as storage backend. It’s been written mainly for having a chat history with JWChat as it can’t save to a local disk itself due to security restrictions“. So we can consider that anything else is a lucky by-product.

The Google Talk “Chat History” is not JEP-0136. But as a recent conversation on [jdev] about Google Talk and server-side logging testifies, the topic raises significant interest.

A discussion on the Ejabberd development forum mentions that “JEP-136 seems to be implemented [..] by Jabberd 1.4.5“. But I have found no trace of that anywhere else. Right now, JEP-0136 implementation is a wishlist item for Ejabberd. I’ll think about it for my next letter to Santa Claus.

You may have noticed that I have added a to the Jabber presence indicator on my personal web page. It is provided by Edgar, a sophisticated Web Jabber presence indicator based on class.jabber.php. To use the Edgar service, all you need is an image tag such as :

http://edgar.netflint.net/status.php?jid=jim@jabber.grabeuh.com&type=image

Edgar displays status fast because it splits processing in two independant parts sharing a database :

• edgar.php is a command line script that collects presence data into the database.
• status.php reads the database and displays presence on an HTML page.

Edgar is licensed under the GPL so you can download it and set it up on your own host.

I like Edgar and I will certainly study it as an exemple of a non-trivial implementation of class.jabber.php. But I shall continue to use my pathetic Web Jabber presence indicator based on one of the examples provided with class.jabber.php because Edgar does not yet display ressources whereas the script I use does.

One of the problems with my Jabber presence indicator on a web page was that the page’s presence was being sent to the polled account instead of being hidden. I fixed that and the updated code is available. The fix was trivial :

29c29
< $JABBER->SendPresence();
—
> $JABBER->SendPresence(”invisible”);

Although widely implemented (even Edgar does it that way), the “invisible” presence type is not XMPP compliant. JEP 126 explains how to provide selective visibility in a XMPP compliant manner. Of course this is less trivial. But since JEP 126 provides the appropriate XML snippets, I could probably do it the right way using SendPacket($xml) to send the raw XML. Maybe next time… Meanwhile I reported the standard compliance issue on the Edgar bug tracker.