I’ve dusted off my packaging skills to create Ubuntu/Debian packages for Wokkel. These are make straight from Wokkel’s trunk, and I will update them periodically to track its changes. Now there’s no excuse not to start playing with the code!

You can find the package wokkel in my Launchpad personal package archive. Add the following lines to /etc/apt/sources.list, and then you can apt-get update and apt-get install wokkel.

deb http://ppa.launchpad.net/metajack/ubuntu intrepid main deb-src http://ppa.launchpad.net/metajack/ubuntu intrepid main

Enjoy!

Many people write XMPP services as client bots, but the problem with this is that this doesn’t scale well. The first step to improving the scalability of an XMPP service is to implement the service as a server component. To demonstrate this, I will revisit the echo bot tutorial and turn it into an XMPP server component. This turns out to be remarkably easy with Twisted and Wokkel.

Sub-Protocols To the Rescue

We created an echo bot protocol in the previous example which listened for incoming messages and replied to those messages. For our component, we want to do the same thing.

Wokkel is designed so that sub-protocols are mostly agnostic to the type of underlying connection. This means that we can re-use the exact same code for our componentized echo bot. Actually, we’ll make one tiny change to the EchoBotProtocol class since the original version sends initial presence to the server, which is only required for client connections.

Below is the new echobot.py. Note that we’ve added a very simple constructor, and we check self.client in connectionMade() to determine if initial presence should be sent.

from twisted.words.xish import domish from wokkel.xmppim import MessageProtocol, AvailablePresence class EchoBotProtocol(MessageProtocol): def __init__(self, component=False): MessageProtocol.__init__(self) self.component = component def connectionMade(self): print "Connected!" # send initial presence we're a client if not self.component: self.send(AvailablePresence()) def connectionLost(self, reason): print "Disconnected!" def onMessage(self, msg): print str(msg) if msg["type"] == 'chat' and hasattr(msg, "body"): reply = domish.Element((None, "message")) reply["to"] = msg["from"] reply["from"] = msg["to"] reply["type"] = 'chat' reply.addElement("body", content="echo: " + str(msg.body)) self.send(reply)

We’ve made no substantial changes to the code, and if we hadn’t made these changes, the code would still work. If you send <presence/> as a component, the server will just reply with an error, and the connection will not otherwise be affected.

Application Changes

The main change that we must make is to echobot.tac, the Twisted application file. The change is fairly trivial; we need to replace the use of XMPPClient with Component. The Component class takes two extra parameters since a component must know what server to connect to and what domain it will appear as. The rest of the changes to the file consist of changing the import statement and renaming the xmppclient variable.

from twisted.application import service from twisted.words.protocols.jabber import jid from wokkel.component import Component from echobot import EchoBotProtocol application = service.Application("echobot") xmppcomponent = Component("example.com", 5347, "echo.example.com", "pass") xmppcomponent.logTraffic = False echobot = EchoBotProtocol() echobot.setHandlerParent(xmppcomponent) xmppcomponent.setServiceParent(application)

The first and second arguments to the Component constructor are the domain of the server and the port at which the XMPP server listens for component connections. The third argument is the JID that the component will become. The last argument is the component password.

Just as with the original echo bot, we can run the component version with twistd -ny echobot.tac.

Server Configuration

An XMPP service built as a client needs to have an account to use; an component service needs some configuration as well. Generally the server must to configured to listen for component connections and the password must be set.

The configuration section below is for ejabberd, but other servers will probably have something very similar. The following lines go into the ejabberd.cfg listen section. Similar lines should already be there but commented in the default configuration file.

{8888, ejabberd_service, [ {access, all}, {hosts, ["echo.example.com"], [{password, "pass"}] } ]},

This will set ejabberd to listen on port 8888 for component connections and will allow the component to assume the JID of echo.example.com.

Components Are Easy

Writing components is not hard. In Wokkel and Twisted Words, it is exactly as much work as a client, except that you use a different connector. At the protocol level, the Jabber Component Protocol is quite a bit simpler than making normal client connections. The XMPP server does no extra work such as maintaining a roster or routing stanzas in a fancy manner, and this is why a component service scales better than a client service.

I knew that components were easy since we had already implemented many different ones with Twisted for Chesspark. It was a nice surprise to find out that the only change needed to turn my echo bot example in Wokkel into a component echo bot was to alter the application file.

The next time you’re building an XMPP service, I highly recommend starting with a component and giving Twisted and Wokkel a try.

There are two new XMPP PubSub extensions being proposed at the XSF. The first one is for pubsub chaining, and this defines how a pubsub node subscribes and re-publishes items from one or more local or remote pubsub nodes. The second is for pubsub queueing, which enables queue like behavior for a pubsub node. These ideas are young and fresh, and the XSF would love your feedback on them.

Chaining

Pubsub chaining can be used for a number of problems. The most interesting to me is its potential for use in aggregation of pubsub content. In the scenario where microblogs are just PEP or pubsub nodes, it is very useful to aggregate all of the microblog nodes under a single feed for use by third party service providers. It could also be used to establish and manage pubsub based planets.

Queueing

Pubsub queueing is an attempt to map a queue like API onto pubsub nodes. While some people are building pubsub on top of queues, this proposed extensions builds queues on top of pubsub. This could be extremely useful for decoupling applications or spreading workload to an army of worker processes.

We Need Help

There is still much work to be done, and several of us have been proposing changes and additions on the pubsub mailing list. Please come and participate and share your use cases, feature ideas, and feedback.

A bot is not a new thing, it has been done in IRC for a long time. In IRC, a bot is a program that listens to messages in a channel and responds to them.

Bots are also being used in XMPP and particularly Multi-User Chat. You can see a weather bot in action at the following url :

http://speeqe.com/room/zzchschat@muc.appriss.com/

Using XMPP you can extend a bot to respond to messages that are not direct chats. XMPP is xml so you can send and respond to xml messages. This makes XMPP better than IRC.

At Chesspark bots are used extensively. There is one in particular used for a King of the Hill game. It combines MUC and PubSub XMPP extensions to achieve a fun game, where you knock your opponent off the hill by winning chess games.

There are many ways to create XMPP bots, but I have currently been working on MUC support for Wokkel. From Wokkel's web page : "Wokkel is collection of enhancements on top of the Twisted networking framework, written in Python. It mostly provides a testing ground for enhancements to the Jabber/XMPP protocol implementation as found in Twisted Words, that are meant to eventually move there. " Wokkel is nice for implementing and staging things before they can go into twisted.

Using the MUC client branch, I will show you how you can create a Jabber MUC bot. We have to use the branch because it is still under development and not in trunk yet. Hopefully it will be soon. Note that everything is not fully implemented but there is enough to make a bot.

This bot will be simple and just keep track of users coming in and out of a room. You will be able to see user activity using a last command.

First we check out the developement branch. Then we install it.

svn co https://svn.ik.nu/wokkel/branches/wokkel-muc-client-support-24 wokkel python setup.py install

After this we will need to create the python class. Will will put it in the client.py file and call it MUCLastBot.

""" A simple last bot wokkel example """ from twisted.internet import defer import datetime from twisted.words.protocols.jabber import jid from wokkel import muc class MUCLastBot(muc.MUCClient): """ """


All this does it import the python modules we will be using and extend the muc.MUCClient class.

Next, we need to initialize and add 'last' support and methods to the bot.

def __init__(self, server, room, nick): muc.MUCClient.__init__(self) self.server = server self.room = room self.nick = nick self.room_jid = jid.internJID(self.room+'@'+self.server+'/'+self.nick) self.last = {} self.activity = None def _getLast(self, nick): return self.last.get(nick.lower()) def _setLast(self, user): user.last = datetime.datetime.now() self.last[user.nick.lower()] = user self.activity = user

This initializes the class with attributes we need and sets up methods to support user activity.


After this, we need to have the bot join a room. This is done with the 'initialized' method in MUCClient. This method is called after the XMPP client authenticates and its observers are initialized.

def initialized(self): """The bot has connected to the xmpp server, now try to join the room. """ self.join(self.server, self.room, self.nick).addCallback(self.initRoom) @defer.inlineCallbacks def initRoom(self, room): """Configure the room if we just created it. """ if int(room.status) == muc.STATUS_CODE_CREATED: config_form = yield self.getConfigureForm(self.room_jid.userhost()) # set config default config_result = yield self.configure(self.room_jid.userhost())

This code will make the bot join the room after start up and then will configure room if the status shows that the room was just created. It uses the 'join' method to join the room and when the bot joins the room 'initRoom' will be called.

You will notice the decorator 'inlineCallbacks', you can ignore this. This decorator allows the method to call deferred methods and use yield to get the call back result.

You can go to http://www.twistedmatrix.com to learn more. For our purposes we will just ignore it. :)

Next, we need to handle when someone joins and parts the room.

def userJoinedRoom(self, room, user): """If a user joined a room, make sure they are in the last dict """ self._setLast(user) def userLeftRoom(self, room, user): self._setLast(user)

All we do is mark their last activity.

We then need to handle commands and logging messages sent by users.

def receivedGroupChat(self, room, user, body): # check if this message addresses the bot cmd = None user_nick = None try: cmd, user_nick = body.split(" ") except ValueError: # value error means it was a one word body cmd = body cmd = cmd.replace("!", "") method = getattr(self, 'cmd_'+cmd, None) if method: method(room, user_nick) # log last message user.last_message = body self._setLast(user)


This method takes a groupchat message and processes it to see if there is a bot command. It also logs last message activity for the user.

So, the command we want to use is 'last', we need that method inorder to complete the bot.

def cmd_last(self, room, user_nick): """ """ if user_nick is None: # show last person to do something self._sendLast(room, self.activity) else: u = self._getLast(user_nick) if u: self._sendLast(room, u) else: self.groupChat(self.room_jid, 'Sorry %s, That person is unknown to me.' % (user.nick,)) def _sendLast(self, room, user): """ Grab last information from user and room and send it to the room. """ last_message = getattr(user,'last_message', '') last_stamp = getattr(user,'last', '') if room.inRoster(user): message = """%s is in this room and said '%s' at %s.""" % (user.nick, last_message, last_stamp) else: message = """%s left this room at %s and last said '%s'.""" % (user.nick, last_stamp, last_message) self.groupChat(self.room_jid, message)

The last command checks the activity for the user given, or if no user is given it will then show the last active user. It will also tell you it does not know the user if it has never seen them in the room.

The '_sendLast' method sends that information back to the room as a groupchat.

The bot is now complete, we will need a conf file to start it up. To do this I will use a .tac file for twisted.

from twisted.application import service from twisted.words.protocols.jabber import jid from wokkel.client import XMPPClient from client import MUCLastBot application = service.Application("lastbot") xmppclient = XMPPClient(jid.internJID("test@thetofu.com/lastbot"), "test") xmppclient.logTraffic = True mucbot = MUCLastBot('chat.speeqe.com','last', 'LastBot') mucbot.setHandlerParent(xmppclient) xmppclient.setServiceParent(application)

Simply use twistd to run the bot.

twisted -y muc.tac

That is it, have fun and look forward to more XMPP support in wokkel and twisted!

You can download muc.tac and client.py at the following url:

http://people.chesspark.com/~tofu/wokkel/lastbot/

Today I’ll be giving an interview to radio fsk, hamburg. The topic is about twitter and openmicroblogging. They’ll have Cem Basman from WhisperN News and Media (brokerz) at face and I’ll join later on to talk about the role of XMPP in the field of openmicroblogging. The live broadcast calls itself Nerdalert and will start at 17:00h CEST. And of course there is also a livestream available.

Version 0.32 of XEP-0166: Jingle has been released.

This specification defines an XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards. The protocol provides a pluggable model that enables t

The changelog is:

Added content-reject action to mirror content-accept for replies to content-add; also added transport-reject action to mirror transport-accept for replies to transport-replace. (psa)

I’m building some new Erlang modules related to OpenMicroblogging and thought it would be good build them properly. I wanted to be able to detect whether Erlang was installed, look for ejabberd header files, nsure that the ejabberd behaviors I needed were available, and compile and install the module. Having recently written about various new build systems, I decided to explore these to find an acceptable solution to my problem.

The short answer is that it wasn’t a very fun way to spend my time, and despite my strong dislike of autotools, I ended up using that in the end. If you’d like the gory details as well as example code, keep reading.

First Attempt With Waf

Waf seemed quite promising when I looked at it before. It used Python files to describe builds, had separate configuration and build steps, and it was even shippable along with the code. I decided to start with waf.

The first problem I ran into is that the documentation for waf is either extremely out of date or much newer than the latest stable release. Either way, the examples in the documentation failed completely because the API had changed. I was able to get some very basic examples working after digging around for a while.

The second problem is that while waf is capable of building arbitrary things, there is essentially no documentation for how to set up custom builders. The documentation assumes that everyone will be satisfied with the baked in languages. Since I’m compiling Erlang, and Erlang isn’t yet supported in waf, I was out of luck. I made a half-hearted attempt to investigate the baked in builders in hopes of it being pretty easy, but I became frustrated and gave up.

Another thing I noticed about waf is that there does not appear to be a separate install step. Installation seems to be part of the build step, and various options make it install happen or not while building. This seems like a weird omission, although I am probably missing something.

Second Attempt With SCons

I’ve used SCons before for Strophe. It’s not perfect, but I remember it working well enough and saving me from the horror of autotools. In the three years since I first played with SCons, it hasn’t changed much. What it has gotten is bug fixes and documentation. I was much more hopefully that SCons would work for me where waf had failed.

A Google search revealed that there was some 3rd party Erlang support for SCons. The Web site is half broken, but I did manage to find and download the code. It seems reasonable complete in that it supports building and dependency scanning for normal Erlang modules, Erlang applications, and EDoc documentation files. There is a real problem with both SCons and the Erlang support though.

The issue is that SCons has to be installed for someone to build your package, and on top of that, SCons Erlang has to be installed as well. SCons actually has a facility called site_scons for including extra build tools in your distribution so that they are available without having to install more stuff. I think that SCons Erlang could be made to live in site_scons, but I’m baffled why the author didn’t make this the default. The SCons documentation on builders gives an example of this, and the custom builder examples in the SCons wiki follow suit.

I did make an attempt to write some simple Erlang builder rules in site_scons, but I could not get the code to function as the documentation suggested it should. I suspect I was missing some small detail that is mentioned elsewhere in the manual than the examples I was following.

The final straw for me was the lack of a separate configuration step. This needs an example to explain fully.

In order to find the ejabberd headers and modules, I need to pass in the path where ejabberd was installed. In autotools, this would be done with an argument to configure like --with-ejabberd=/path/to/ejabberd or --prefix=/ejabberd/prefix. SCons can take arguments but these have to be passed every time as there appears to be no built in facility for persisting the configuration for the build between invocations of SCons.

I think such a persistence facility could be written, or possibly has already been, but I couldn’t find one and I was not in the mood to write my own. After all, I already had the work of writing tests for finding headers and modules plus the work of getting SCons Erlang to work in site_scons.

Third Attempt With CMake

I didn’t spend much time with CMake. I perused the documentation to see if it already supported Erlang or if it had examples on how to create custom builders. My impression was that it supports C and C++ out of the box and not much else, and I could not find any examples of how to set up build rules for arbitrary languages. I was left with a Win32 taste in my mouth due to the filename convention of CMakeLists.txt as the build file names.

Since I didn’t see any examples for custom builders, and the syntax of the build description files was novel, I punted.

Final Attempt With Autotools

By this time I decided to give in and try autotools. I managed to make it work eventually, but I ran into a lot of problems along the way.

Automake, You Suck

I first started with a basic configure.ac script which used automake. Because automake is fairly hardcoded around C and C++ based development, you have to jump through some hoops to make it deal with Erlang at all. Essentially you have to tell it that the Erlang files are data files derived from source files that automake shouldn’t care about. Here is an example I found on the mailing list:

beam_DATA = netaccess.beam EXTRA_DIST = netaccess.erl CLEANFILES = $(beam_DATA) .erl.beam: @ERLC@ -b beam $@ $<

Sure this works, but it is a big, ugly hack.

Automake sucks for more reasons than not being very nice with Erlang files. It creates a huge mountain of build steps. It gets the job done, but the screen is filled with useless build output from all the intermediate steps.

I now that standard Makefiles can be simple and elegant, so I abandoned automake and crafted my own.

Autoconf Knows Erlang

One of the happy discoveries is that autoconf already understands Erlang. In fact, it has numerous Erlang examples in the manual. I added my AC_ERLANG_NEED_ERLC line and dived in.

My first job was to detect header files. Autoconf does this for C type headers but does not include any support for Erlang headers. I decided to write support for this building on top of the AC_COMPILE_IFELSE macro, which attempts to compile an Erlang problem when AC_LANG_ERLANG is effect. This immediately fails because autoconf has a huge bug in its Erlang support. It never defines $ac_objext so can’t create BEAM files. This is a known issue, but I don’t understand how this code ever made it into autoconf in the first place if such a basic bit of functionality didn’t work.

This can be worked around, and here is my header checking macro, ERL_CHECK_HEADER:

# Check if we can find Erlang header files. AC_DEFUN([ERL_CHECK_HEADER], [AC_MSG_CHECKING([for $1]) AC_LANG_PUSH(Erlang) ac_objext=beam AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([[-include("$1").]], [[ok]])], [AC_MSG_RESULT([ok]) $2], [AC_MSG_RESULT([not found]) $3]) AC_LANG_POP])

I use this to detect ejabberd.hrl like so:

ERL_CHECK_HEADER(ejabberd.hrl, [], [AC_MSG_ERROR([ejabberd.hrl is required.])])

All is well and good so far. The next problem is to detect whether specific modules are available. Specifically, I want to know if autoconf can find the gen_mod module which any ejabberd module will need. The location of this module will be needed during the compile stage.

Just like the header check, there isn’t much in autoconf’s Erlang support to help us out. It does have an AC_ERLANG_CHECK_LIB, but this only finds Erlang libraries, not modules. Moreover, it’s broken too. There was a regression in autoconf 1.62 and later, still unfixed, which prevents AC_RUN_IFELSE from working. This sucks, because AC_RUN_IFELSE is exactly what we need to write the ERL_CHECK_MODULE macro.

Patching this in aclocal.m4 fixes the regression, but we also need to pass in some options to erl when it runs the program. This is, of course, not supported at all, and we have to patch this as well by passing in ERLFLAGS when erl is run so that it can hope to find the modules we’re looking for. The resulting macro is very similar to the one above except for the redefinition of AC_LANG_ERLANG that is needed to make it do anything useful.

I’ve put up my basic ejabberd module autoconf project skeleton here others to study or enjoy.

A Note On Other Options

Notably missing from my attempts are plain Makefiles or Erlang Emakefiles. Normal Makefiles work fine, but they do not provide any facility for configuration or detection of libraries. Emakefiles are even worse, since there doesn’t seem to be any standard way to include shell variables. I didn’t want to hard code the configuration or require special environment variables like EJABBERD_HOME. I realize autoconf is more than is needed for simple modules, but my goal was to explore build systems more than it was to do something practical.

That said, if you are going to package up a 3rd party ejabberd module, having configuration detection and support is very helpful for users. Most people have no idea how to build C, much less Erlang. The less we have to expose to them the better. The benefit of autotools is that many users will already be familiar with ./configure, make, and make install.

Several people suggested I check out zc.buildout, but this appears to be a meta system for configuring a bunch of dependencies along with a project that runs in the “buildout”. This reminds me a lot of something like pbuilder a little more cleverly done. It also seems very focused on Python. Perhaps someone familiar with it can chime in as to how appropriate it is for something written in Erlang or C.

Thoughts

I was extremely disappointed in the non-autotools options. Of the other three, SCons had the best documentation and examples by far. Waf and CMake left a lot to be desired if one is not building a C project.

I’d love to give the other systems another shot, and here’s what I’d like to see before doing so:

• SCons - I’d love to see a way to include SCons with my distribution so that the only dependency is Python. Waf does this very well, as does autotools. Some improvements in the site_scons documentation would be nice as well.
• waf - Waf really needs to get its act together documentation wise. It’s extremely frustrating to invest time in reading the documentation only to find out that it does not apply to the current version of the code. Build systems like waf need to realize that they fill a great niche that is under-served by autotools, which is making custom build tools much easier to develop. Lack of any examples in the documentation on how to do this make it harder than autotools.
• CMake Custom build support examples need to be in the documentation. I’m willing to put up with arcane syntax as long as it works and is well documented. If I have to read the code and pour through the build files of large projects to find information, I might as well read the source code for waf and solve the problem in a familiar domain.

As always, I’d appreciate your comments. Are you suffering with the un-fun, but reliable, autotools, or do you have a favorite alternative?

Version 0.9 of XEP-0186: Invisible Command has been released.

This document specifies an XMPP-compatible protocol for user invisibility.

The changelog is:

Further clarified server and client handling of stanzas during an invisibility session. (psa)

Version 0.3 of XEP-0152: Reachability Addresses has been released.

This document defines an XMPP protocol extension for communicating reachability information related to non-XMPP devices.

The changelog is:

[See revision history] (psa)

Last week I updated the XSF Subversion repository to generate pretty HTML commit emails. Now everyone can subscribe to the commit list and see the specifications change right before your eyes. This is extremely helpful to me as a XSF Council member; now I can easily follow along with all the changes to the specifications without leaving my e-mail client.

For those of you who want to similarly empower your own commit e-mails, I’ve written up instructions.

Also, if anyone knows to how to make the pretty versions show up in the archives, please let me know. They currently seem to be stripped.

Version 0.2 of XEP-0225: Component Connections has been released.

This document specifies a standards-track XMPP protocol extension that enables server components to connect to XMPP servers.

The changelog is:

Modified namespace to incorporate namespace versioning; clarified that the value of the element can be either or resource>. (psa)<p>

Peter Saint-Andre said something great the other day:

It’s amazing to me that after almost 10 years working on this stuff, it feels like we’re really just at the beginning.

I haven’t been working on XMPP stuff for nearly as long as him, but I whole-heartedly agree.

XSF Board and Council elections have completed for 2008-2009, and this year marks a notable increase in interest in these positions. For the first time ever, five board members were elected instead of just three, and the council had real competition among the applicants with 6 people vying for 5 spots. It’s great to see the XSF growing and new people stepping up to help the organization in a formal role. I’m pleased to serve another year on the XSF Board (my third term) and to serve once again on the Council (my second term). It’s not too late for you to participate if you haven’t already; the XSF Membership elections are coming up very soon.

The New Board

This year’s board members are the same as last year’s with the addition of two new faces: David Banes and Will Sheward.

With Alex, David, Mickael, and myself we have four founders/CEOs on board, and Will will round that out with his marketing experience. It’s about time we had some marketing chops on the XSF board, since many of our meetings are marketing related.

I look forward to working again with Alex and Mickael and to hearing the new ideas from Dave and Will.

The New Council

The new council has four of the same members. Remko and I had the pleasure of competing for the remaining spot which I won by a small margin. It was interesting to have decision to make this year on who to vote four, and the member voting bot had to be recoded to randomize the candidates since we had more of them than spots.

The XSF Council has a busy year ahead. Interest in XMPP is higher than ever, and much of that interest is around new and draft specifications. Peter has already sent out the draft agenda for the first meeting on Wednesday, and if its length is any indication, this will be a hugely productive year for the XSF and XMPP.

Come Join Us

You can become a member of the XSF as well. We hold quarterly elections to vote new members in, and these new members are responsible for electing the XSF Board and Council as well as participating in some policy discussions from time to time. Members also frequently represent the XSF at events all over the world. Membership also has some privileges; in the past, the XSF has paid for accommodations for members attending the XMPP Summits.

We’d love to have your help in making the XSF bigger and better.

Strophe continues to make progress thanks to the valuable feedback from its users. One of the neat tricks that you can do with BOSH is session attachment. A BOSH session is established by some other piece of code, and Strophe attaches to the already existing stream. This is used in features like passing a BOSH session from page to page or for auto-login on page load. I’ve added an attach() method to Strophe.Connection to support session attachment and included an example Django project which shows how it is used.

When To Get Attached

Session attachment is very useful in a number of situations. Here are two that I’ve discovered so far.

Auto-Login And Hiding Credentials

If your Web application also includes an XMPP component, it might be the case that users have one set of credentials for both interfaces. In this situation you can establish a BOSH session for the user without asking them to re-provide those credentials, making the user experience seamless.

One problem with this is that without session attachment you’d have to put the credentials into the rendered HTML page for Strophe to use. This is not secure at all since that page may be cached and will probably traverse the Internet unencrypted. However, the security problems can be avoided completely if your Web application establishes the BOSH session before rendering the page, and then passes only the session variables needed to continue the session into the resulting Web page. Strophe then uses these session variables to attach to the session.

One thing to note is that even if the page is cached, an attacker can’t easily use this data to hijack your session. A successful attack would have to happen during your session, and it would have to occur before you used the session or quickly after you started using it. The SID and RID variables that BOSH uses to identify sessions are useless unless you know the current RID or can guess it within a very small range (typical window sizes are around 5 to 7), and they become worthless as soon as that session is ended.

Passing Sessions Around

If your Web application involves moving around over a variety of pages, you may want to pass a BOSH session around with the user so that they can continue to interact with the XMPP parts. To make this as seamless as possible, it is necessary to keep a persistent session going in an iframe or via a popup or to pass the session state from page to page and let each page attach to it.

This can get complicated quickly, so session attachment may not be the best solution here. For example, what happens when two pages are active at the same time? Only one can attach to the session. Perhaps someone clever will think of a great solution for this problem.

An Example

I’ve written an example Django application which demonstrates how session attachment works. It’s pretty bare bones, but shows exactly how the feature works.

Django is used in the example, but any Web framework will probably have a very similar implementation.

For the example, the authentication information is stored in the Web application settings; in our case, this is attach.settings. When a user requests the root URL the code establishes a BOSH session by making HTTP requests to the BOSH connection manager and passing along the credentials. In the code, the attach.boshclient.BOSHClient class sets up the BOSH session and keeps track of its state.

Once the session is established, the HTML template is rendered which writes out the session state into global JavaScript variables:

var BOSH_JID = "{{ jid }}"; var BOSH_SID = "{{ sid }}"; var BOSH_RID = "{{ rid }}";

Strophe is then passed this information, along with a callback for connection events, via the attach() method:

connection.attach(BOSH_JID, BOSH_SID, BOSH_RID, onConnect);

From there on out it is business as usual for Strophe, and the session can be used exactly as if Strophe established the session itself.

Strophe 1.0 Approaches

The release of Strophe 1.0 is imminent. At this point it appears feature complete, and I am just waiting on some final feedback and testing before I wrap it up with a pretty bow.

Several people have asked about licensing, and the plan is currently to make StropheJs available under both the GPLv3 and the MIT license. This seems to work well for other JavaScript projects like jQuery. If you would prefer a different license, I’m happy to discuss it.

If you think it is still missing something or have any trouble at all, please file a bug at the Strophe project page or leave a comment.

Initially the Tigase project was about the XMPP/Jabber server development. After a while the project received a support from other developers more interested in client side development. So now we host quite a few projects related to the IM and XMPP in particular.

The main focus is put to the server development and to the web clients development. By web client I mean not just the Minichat application used by many visitors of our website but also our AJAX libraries for XMPP/Bosh communication which are used in a few bespoke projects and also our child project - Tigase Messenger.

We have been working on the Tigase Messenger for some time already and it is still not yet finished product but we think it can be demonstrated to the public. Please go to the messenger.tigase.org page, login, play with it and let us know what you think.

read more

For years, Doc Searls and his son Allen have been talking about the live web. Sadly, one of the most dynamic corners of the ‘net — the real-time developer community centered around jabber.org — has been old and static (at least when it comes to the web). That’s about to change. Today in the webteam chatroom we had a lively discussion (pardon the pun) about how to enliven the jabber.org web experience. Expect a radically dynamic new interface soon, with live chatrooms powered by speeqe, microblogging feeds, and just a few static pages for reference purposes. The design is still emerging, but I really like the ideas we’re working to make real. Join the conversation!

One thing I do everyday is group chat via XMPP. There are lots of ways to do this, via many xmpp clients. If I am on my laptop or computer then having a client works out well. I can chat to my hearts content.

Often, a problem that comes about, is if I am away, and I need to communicate via a chat room, what do I do? I could use a remote computer and a command line XMPP client or I can use Speeqe.

Speeqe is a web based chat creator, you can create and theme your own chat rooms! There are many ways to use Speeqe for various different things, but the solution to my problem, I find very useful, is that you can connect to other chat rooms on the federated XMPP network.

To do this you can use the url trick, for example:

Jabber Development Room

http://speeqe.com/room/jdev@conference.jabber.org/

Charleston Linux Users Group

http://speeqe.com/room/csclug@conference.butterfat.net/

You can just start chatting anonymously or login via a XMPP account.

This trick, and the other things you can do with Speeqe, are cool, but best of all it does not end there. Speeqe is open source!

You can use and add features to Speeqe and the possibilities become endless. :)

The neat thing is it already uses open source software. It uses Strophe, Punjab, Palaver, Apache, and Django.

It can be set up to use any XMPP server and any Multi-User chat implementation. It is very flexible.

More examples of setting up and using Speeqe are sure to come!

Look forward to the official release of Speeqe!

Speeqe is now officially an open source project. Nathan Zorn has led the project from the outset and has been working hard to prepare the first release. You can find the Speeqe code at the Speeqe project site. In addition, we’ve opened up Speeqe.com so that anyone can create accounts and rooms. There is still much work to be done, but we believe that with your help we can make the best group chat clients and services on the Web.

A Bit About The Code

The code is a mixture of Python, JavaScript, and a tiny bit of Erlang. Don’t let this frighten you, as each piece is fairly modular, and you can take whichever you need.

The Web Client

The Speeqe client is a JavaScript application that runs in standard Web browsers. It is built on top of Strophe and is almost entirely independent of the rest of the Speeqe project. The one exception is that to prevent storing passwords in cookies, we store them in session variables on the server. This means that these must be passed to and from Django, but it is pretty minor and easy to change.

This is the only piece you need if all you want is a Web based interface to already existing group chats.

The Web Site And Web App

The Web site and application are written in Python and make use of the Django framework. The Web portion essentially manages user creation, room creation, and authentication persistence for the Web client.

This piece is needed if you want to run a group chat creation and management service like Speeqe.com.

The Multi-User Chat Server

Currently Speeqe.com uses [ejabberd(http://www.ejabberd.im) and ejabberd’s modmuc to provide a local group chat service. This is where new rooms are created by the Web application and where created user accounts are homed. In addition to the stock ejabberd setup, we’ve also provided a modmuc_logspeeqe module for logging the local group chat rooms to a CouchDB database. This is of course written in Erlang.

You’ll need this piece if you plan to host group chats and want them logged.

Getting Started

Please see the setup guide to get started creating your own group chat service. If you run into any trouble or need assistance, please ask on the Speeqe mailing list.

A Bit About The License

We’ve released Speeqe under the Affero GPL license. This is a Free Software Foundation endorsed license made for network accessed services like Speeqe.

The AGPL adds a clause to the standard GPL license that requires the source code to be made available to any network user of the software or its derivatives. This means that if you start your own Speeqe-like group chat hosting service, your changes must also be available for everyone, even if you don’t distribute the code.

This license has seen increased adoption by Web application developers and is used by projects like Laconica, the software behind Identica.

Start Speeqing

We hope that the community will find Speeqe useful as a basis for even better projects, and that it will help us fulfill our vision of simple, standards-based group chat for everyone. We can’t wait to see what happens!

Please let us know what you think in the comments or on the mailing list.

Cisco’s acquisition of Jabber stands to be a significant boost for the enterprise IM (instant messaging) market and a clear sign of Cisco’s aspirations in the applications space. Cisco will now be able to extend the reach of its current IM service and expand the capabilities of its collaboration platform. It will also impact the Instant Messaging market deeply.

As we previously said, this move represents a major victory for open protocols, and more specifically for XMPP against the SIP/SIMPLE protocol in the battle for IM standards. Some have seen another sign that ‘open source’ had gone mainstream, but in this case it is much more a recognition of the value of ‘open standards’.

As several articles have stated (like for example Cisco Acquires Jabber (The Company, Not The Standard)), the acquisition of Jabber is a handy addition to Cisco's growing portfolio of enterprise-focused web communications products. It should be noted that Cisco is acquiring Jabber the company not the actual standard. Jabber is a big proponent of the XMPP protocol and already builds and supports a number of IM products based on the standard, however in essence Cisco is likely buying the expertise rather than specific products.

Others have highlighted that the move has instantly increased the acceptance of IM as there will be increased interoperability with established IM platforms from the likes of Microsoft, Google and Yahoo! (For example Cisco guns for Google, Microsoft with Jabber buy). With more businesses realising that IM is becoming an important communications tool the Cisco acquisition opens up a lot of opportunities in the market.

ProcessOne is one of the few remaining independent IM and XMPP technology providers. As Cisco will now be actively working with and promoting open IM standards to customers worldwide, ProcessOne’s offering to telco, web and enterprise customers stands to be significantly strengthened, as they will seek greater interoperability and security across IM platforms. This opens up a new exciting era for us

You can get more details on the acquisition at http://newsroom.cisco.com/dlls/2008/corp_091908.html.

Nokia today announced that the Finish company will acquire OZ communications, a Canadian IM mobile client and gateway provider.

Nokia buying OZ Communications a few days after Jabber Inc acquisition by Cisco is a sign that instant messaging battle is reaching an unprecedented level, especially among telco players.

The goal of the two operations is obviously different. Cisco wants to boost its unified communication platform. It is a move to take a bigger share of the Enterprise Instant Messaging market.

Nokia is not targetting the corporate market but indirectly the end user market through mobile instant messaging. Nokia is thus becoming a player that can act as intermediary for access to large instant messaging network on mobile (for example MSN, AOL, Yahoo!). The Finish company thus become a major player between mobile carrier (and thus users) and instant messaging networks.

This is an interesting operation, as Nokia now has a strategic position and can use this situation as an advantage to promote its own mobile service platform called OVI.

The news has been covered by ZDNET Uk: Nokia boosts comms platform with Oz purchase