XMPP PubSub aka “death by a thousand cuts”
Well, ok, not quite that dramatic – but for sure the final 20% is going to turn the last of my beard gray before the year ends.
Lately Nathan and I have been battling subtle bugs in Tigase (which Artur and Bart have been great at fixing), subtle bugs in our code (oh yea, even there! ;) ) and the usual other 30 distractions as the team delivered the beta version of the new site.
With this latest round of tweaks we are very close to calling it “shipped”:
- We turned on thenode that delivers the public timeline data (or what others call the “firehose”) and that is now sending Atom payload events to it’s subscribers,
- We are seeing a more stable auto-refresh of the timelines (well, more stable after this last tweak)
- We can now dial the BOSH timeout up or down to find that sweet spot for load management
- The Tigase team delivered a great new feature: Server Monitoring which I’m hoping we can wire into our infrastructure for much more accurate stats
All in all it’s been a really crazy couple of weeks – but man is this stuff fun!
So I’m hoping that the XMPP community allows us a bit of boasting as we have a XMPP PubSub system running “in the wild”. I’m sure there are others out there, but so far they have been rather quiet on how things are done or they have quietly gone away. We are working on an architecture article for the Seesmic Developer’s site that goes into more details on how and why.
Special thanks to Jack for taking the time to review how we structured our Atom payload — hopefully it’s less messy now :)


21. December 2008 at 14:31
The XMPP Pubsub firehose sounds cool.
How to subscribe it ? Would it be possible for Seesmic to publish directly to a Pubsub user node (of an “external” server) on her behalf ?
Also, are you aware of the Content-Based Pubsub System which is basically a tracking system. I don't know Tigase but AFAIK there's no implementation of this capability yet. But it might interest you. :)
21. December 2008 at 14:55
Anyone can subscribe to it by sending me an email with the JID you want to use. We are doing the subscriptions manually just to allow me to keep track of a contact email in case something changes or I need to “break” the system.
The pushing of an item to another PubSub node is called chaining and I know they (the XMPP spec folks) are working on something to cover it – but yes, technically any valid JID can be used as the target and PubSub nodes are valid JID's
We briefly thought of using Content-Based subscriptions to allow the subscriber to control various details like format (Atom, RSS, Json) and also language (all, English, French) but quickly put that back into the “future” column when we discovered that it's not well implemented on either the Client or Server side :( and the last thing we want to do is bolt on a partially implemented feature to PubSub until we have more time to evaluate how.
21. December 2008 at 15:44
totally awesome.
21. December 2008 at 19:31
The XMPP Pubsub firehose sounds cool.
How to subscribe it ? Would it be possible for Seesmic to publish directly to a Pubsub user node (of an “external” server) on her behalf ?
Also, are you aware of the Content-Based Pubsub System which is basically a tracking system. I don't know Tigase but AFAIK there's no implementation of this capability yet. But it might interest you. :)
21. December 2008 at 19:55
Anyone can subscribe to it by sending me an email with the JID you want to use. We are doing the subscriptions manually just to allow me to keep track of a contact email in case something changes or I need to “break” the system.
The pushing of an item to another PubSub node is called chaining and I know they (the XMPP spec folks) are working on something to cover it – but yes, technically any valid JID can be used as the target and PubSub nodes are valid JID's
We briefly thought of using Content-Based subscriptions to allow the subscriber to control various details like format (Atom, RSS, Json) and also language (all, English, French) but quickly put that back into the “future” column when we discovered that it's not well implemented on either the Client or Server side :( and the last thing we want to do is bolt on a partially implemented feature to PubSub until we have more time to evaluate how.
21. December 2008 at 20:44
totally awesome.