Connecting to Facebook’s server is as simple as adding a new account in your favourite client, with chat.facebook.com as the server and your Facebook username as the user. Obviously then, they’re only contactable from the outside world by people who have an account within the walled garden already, but it’s a start. Anyway, it’s handy for people like me who have an account there but, for reasons of taste, common sense, downright dislike of having adverts stuck in their face, etc., don’t ever log in to it.

My first impressions are that their implementation is solid and well thought out. This is to be expected – despite any other criticisms I might have, Facebook have always struck me as a very technically capable organisation. Only one small problem is apparent to me so far, and it’s this: Say Bob is on the Facebook web site and Alice is using her XMPP client. Bob is browsing through the messages on the ‘I Dress Up As A Goat and Eat My Wife’s Underwear’ page, something he does regularly but (uncharacteristically, for a Facebook user) doesn’t want to tell the world about. At this point, Alice uses XMPP to send Bob a link to something on her web site. Bob clicks the link, and blam – his goat/underwear fetish is revealed in Alice’s server logs as the HTTP Referrer.

While I’m thinking of Facebook, something I’ve mentioned elsewhere but is worth repeating, is in relation to this story. Read the story, then look at the two images – in particular the copyright notice on those images. Do Facebook really claim copyright on those images, or have the Daily Mail got it wrong? Either way, it’s definitely something that should be making you go hmmmmm.

Therefore a good example of what I’m talking about would be a private instance of Laconica running on a local network, or perhaps in a private setup on the public internet. I say private because some of the examples I’m going to give are most appropriate for a private setup.

So let’s consider some examples of information you might push to a microblog on a home network, each going to a different user account:

• Security camera events
• Music played
• Bluetooth device presence monitoring – i.e. who’s at home?
• TV recording information – e.g. from MythTV

Some of the above would also apply to an internal company network. These ones definitely do: (my examples are biased towards a software development company)

• General news and announcements
• Automated build process status
• Bug tracker issues opened/closed/commented – example
• Automated QA test results
• Version control commits
• Birthdays, social events
• Network/IT status – example
• Wiki/intranet changes
• Local traffic/transport updates – example

With these examples in mind why does a microblog, not designed for this purpose, lend itself so well to being a hub for all this information. And why have such a hub at all?

Firstly, from the user perspective, there are a wide variety of friendly ways of accessing all this information either in real time, on demand, or retrospectively, and all of these can be mixed and matched easily and simply. For example, subscribe via XMPP to things you need to know about in real time, grab RSS/Atom feeds for important but not real-time stuff, browse the via the web interface for others, and integrate some into your calendar. All kinds of other useful machine-readable information also come for free – microformats, RDF, FOAF, for example.

In addition to these methods, an ever expanding range of desktop and mobile device clients is available.

On the publishing side things are easy too because as well as a simple API for posting notices, there is already a range of ready-made tools for doing so. For example, many information sources already produce an RSS and/or Atom feed – these can be easily hooked up using feed2omb. For sources that produce output in the form of emails, Laconica will accept those directly, and various solutions exist for SMS.

Amongst all the above machine generated data, you can intersperse the obligatory microblogging-style “Jill in accounts is eating an egg sandwich” trivia, or more seriously the “Jack is heading back from a meeting where the terms of the new contract with Acme Widgets were finalised”.

I think so far this is just scraping the surface of what’s possible. If you want to join in, the Laconica software is Open Source and has deliberately low install dependencies to allow it to work on the widest range of possible platforms. Also of interest is the recently announced status.net which will soon be providing turnkey hosted Laconica instances, both public and private.

Stuff you need:

sudo apt-get install build-essential
sudo apt-get install libexpat1-dev zlib1g-dev libssl-dev
sudo apt-get install m4 libncurses5-dev

Erlang:

wget http://www.erlang.org/download/otp_src_R12B-3.tar.gz
tar -xzf otp_src_R12B-3.tar.gz
cd otp_src_R12B-3
./configure
make
sudo make install

Ejabberd:

wget http://www.process-one.net/downloads/ejabberd/2.0.1/ejabberd-2.0.1_2.tar.gz
tar -xzf ejabberd-2.0.1_2.tar.gz
cd ejabberd-2.0.1/src
./configure
make
sudo make install

With that done just edit the config in /etc/ejabberd as required, generate or otherwise obtain an SSL certificate, and you’re ready to go.

I also can’t help viewing those VMware ‘appliance’ things with suspicion, and I’m starting to put real data on these things now, so I went for a clean install from debian-40r1-i386-netinst.iso. Doing the initial setup via the VMware Server console, viewed via VNC, is unbelievably painful but all that was needed after the actual install was to reconfigure the networking and install sshd before getting back to a nice clean SSH login.

I’m slightly cross with myself for not having scripted the rest of the setup yet, but on the other hand I’m pleased I was anal enough to document it all in the first place, because all I had to do was copy the commands out of my previous posts here and paste them into the SSH window to get back to where I was. I also set up Debian to use sudo, because I prefer that to using su.

The only differences in all the setup steps from the previous ‘doing X on Ubuntu’ posts due to the change of distribution were:

• The m4 package was already installed.
• Instead of libssl-dev, I needed openssl.
• I left out the detail of how to fix ejabberdctl. (added as a comment to that post)

I didn’t go as far as the Mnesia data import stage, stopping instead after installing and testing Erlyweb, for reasons that will become apparent later. For the record, the steps were:

• Erlang
• Ejabberd
• Jabberlang
• YAWS
• ErlyWeb

Similarly, if I was more serious about this I’d probably be writing my own XMPP client library, since Jabberlang currently leaves more than a bit to be desired. However, this is strictly a half-hour here and there evening hobby project – a refreshing interlude from the daily grind of watching an egg-timer float in front of Visual Studio 2005. As such, I don’t mind (for now) treading carefully around horrors such as this:

Message = io_lib:format("<message to='~s' type='~s'>
  <body>~s</body></message>",[To, Type, Body])

By the way, if it hadn’t become obvious already, the purpose behind documenting all this is so I can go back and script it when I need to set up an array of identical machines.

So, back to the task at hand. It’s not easy to find a version of Jabberlang that works. I got fed up of trying to patch various problems in 0.2 caused by API changes in ejabberd (on which jabberlang depends), and moved on to trying to fix the broken build system in more recent SVN version. In the end though, I found a sweet-ish spot at revision 5:

svn co -r 5 http://svn.process-one.net/jabberlang/trunk jabberlang
cd jabberlang
erl -pa ebin -make
cd ..

Starting up Erlang to use this requires the following:

EJABBERD_SO_PATH=/var/lib/ejabberd/priv/lib
erl -pa ../jabberlang/ebin /var/lib/ejabberd/ebin

And just to prove it’s all working, a quick test program:

-module(jerltest).
-export([main/0]).
 
main()->
   {ok,X}=xmpp:start("ubuntu01",5222),
   xmpp:set_login_information(X,"test",{password,"pwd"}),
   xmpp:connect(X),
   xmpp:subscribe(X,"ciaran@a.remote.server"),
   xmpp:message(X,"ciaran@a.remote.server","chat","Hello!").

There was a fair amount of head-scratching involved in getting the XMPP Server to Server communication going, but it turned out to be just a question of some bad inbound routing on my firewall, which would have been obvious if it wasn’t for Erlang’s sometimes cryptic error handling and reporting. Everything is working nicely now though, and I’m nearly approaching the point where I can write some code instead of criticising someone else’s.

One more thing – why am I setting up an XMPP server on each machine when I’m sending the messages elsewhere? One reason is for fault tolerance. I want to deliver messages to the local server, free from potential network woes, and rely on that to deal with getting the message to the destination. I haven’t actually checked if ejabberd will do that in case of a network outage – it may well just spit the message straight back as a delivery failure – but it seems to me that it should work that way. I’ll find out soon enough.

Before we start, a couple more pre-requisites in addition to the stuff we installed last time:

sudo apt-get install subversion
sudo apt-get install libexpat1-dev

The next step is getting and compiling ejabberd. For reproducability, I’m grabbing a specific revision of the source from SVN, which at the time of writing is the current one anyway.

svn co -r 905 http://svn.process-one.net/ejabberd/trunk
mv trunk ejabberd
cd ejabberd/src
./configure
make
sudo make install
cd ../..

Generating and installing an SSL certificate:

openssl req -new -x509 -newkey rsa:1024 -days 3650 \
   -keyout privkey.pem -out server.pem
openssl rsa -in privkey.pem -out privkey.pem
cat privkey.pem >> server.pem
rm privkey.pem
sudo mv server.pem /etc/ejabberd/ssl.pem

Now we can configure and starting ejabberd. Before doing this, some of tinkering is required in /sbin/ejabberdctl to account for some issues in the Makefile. Specifically there is some confusion with the ROOTDIR variable, which I just removed completely. Some editing of ejabberd.cfg in /etc/ejabberd is also required, mainly to set the hostname and configure the S2S settings. Once this is done:

sudo ejabberdctl start
ejabberdctl register admin ubuntu01 password

Obviously replace password with an appropriate password. Next, edit ejabberd.cfg again and add a line to grant admin rights to the new admin user (it’s documented in the file), and restart ejabberd to allow the change to take effect:

ejabberdctl restart

You can now test the web interface by going to http://ubuntu01:5280/admin in a browser.

IMified provides a framework where new ‘Widgets’ (essentially bot applications) can be plugged in. There are a range of Widgets already available, covering things such as reminders and todo lists, as well as support for blog posting to a range of different platforms such as Wordpress and Livejournal (which I used to post this message).