Beyond superfeedr awesomeness

superfeedr is one of those great web services that has bridged what interests you on the web with your lazyness to go and check it for yourself. That’s right! More seriously, you don’t have to be lazy to be quickly overwhelmed by the huge quantity of information available to you and superfeedr offers you a fantastic service by delivering information at your door step.

But as it stands, superfeedr is just the tip of the iceberg. It could do much more for you.

Resource sharing

It would be probably be interesting if you could easily share with others (contacts, aggregators, social networks, etc.) links that you find interesting. This means you would become a source of information too. In other words, it’s as if you were generating a feed of links which others could subscribe too through superfeedr. But aside from the form itself, the possibility to automatically (re)publish interesting links is probably useful.

Recommendation support

Considering the sheer amount of feeds parsed by superfeedr and the fact they know the set of feeds you are interested in, it would be quite useful to add a recommendation mechanism in place. It means analysing feeds metadata but also giving weight to feeds based on the number of subscribers they have in the system or how long they retain subscribers. Similarly it would be relevant to publishers to get metrics to monitor how people consume their resources.

A dedicated client

XMPP clients suck. They all do when you want to go beyond pure instant messaging. PubSub is just barely supported and when it is, it’s just not user friendly. Therefore, following what the guys at seesmic have done, if you want your users to enjoy your service, you need a dedicated client. They care naught for your protocol. They want information displayed in the fashion du jour. These days, you gotta look like Twitter. Maybe Process One OneChannel could be a lead.

Integrate with Wave

That one is probably just for the fun of it but Wave is quite fancy-able these days and being able to be notified via a Wave could be a very cool.

Have a mobile presence

Mobiles will be where the market is in the next coming years. New generation mobile phones can support really well HTTP and even XMPP as BuddyMob has shown for quite some time with Android. Being able to broadcast to mobile phones is a must.

Are those overall changes critical to superfeedr? It’s hard to tell. Creeping featurism is never a good idea and finding the right balance between what would make the service richer without making it obscure and without focus is always difficult. In any case, it’s a very handy service that deserves more attention. Happy feeding.

Atom and AtomPub were failed

Joe Gregorio’s AtomPub is a failure note is probably not as provocative as its title may make it sound. Joe knows more than the average lunatic out there about AtomPub considering he was co-editor of RFC 5023 and his work at Google so when he says AtomPub may have failed, one is forced to pay attention.

Joe argues that even though AtomPub hasn’t failed as technology, it hasn’t swept the inter-tubes world away as hoped probably because the rationale for creating such a protocol years back doesn’t really pan out any longer.

I share Joe’s slight disappointment at not seeing AtomPub more spread on the web but I don’t entirely agree with the reasons he puts forward:

So why hasn’t AtomPub stormed the world to become the one true protocol? Well, there are three answers:

  • Browsers
  • Browsers
  • Browsers

The world is a different place then it was when Atom and AtomPub started back in 2002, browsers are much more powerful, Javascript compatibility is increasing among them, there are more libraries to smooth over the differences, and connectivity is on the rise.

I’m kind of puzzled, browsers did exist back in 2002, didn’t they? Sure they are more standardized, Javascript is not a shameful programing language like it used to be back in the DHTML days but nonetheless, browsers haven’t fundamentally changed since then. Moreover, through all the years required to release AtomPub nothing prevented the WG in charge of it to reach out for browser vendors. I don’t remember seeing much of them during the long discussions that took place. I find therefore rather harsh to complain at browsers for the fact AtomPub isn’t spread enough. (Note to the Hybi list, don’t make the same potential mistake).

Joe also suggests that XML was overcome by the couple: HTML+JSON. That is very true and Joe acknowledges that he didn’t think this would happen but when he says:

All of the advances in browsers and connectivity have conspired to keep AtomPub from reaching the widespread adoption that I had envisioned when work started on the protocol, but that doesn’t mean it’s a failure.

Conspired? Come on Joe. XMPP certainly suffers from the priority browser vendors have made in the past years but XMPP isn’t built atop HTTP when AtomPub is. I’m sorry Joe but, if anything, the fact Javascript has now so many fantastic libraries make it even simpler to interface with any protocol based on HTTP. Browsers have everything one needs to build an application conversing through AtomPub.

I disagree with Joe’s reasoning and personally I think there is a much bigger issue here to explain the protocol’s difficulties to be a premium choice for public web services.

Let’s review some social network platforms and the way they expose their data.


Atom: Only used to view global recent changes and utter failure at actually using the format for what it’s good at. In a nutshell, everything is serialized to HTML and packed into the atom:summary element.

API: MediaWiki offers an API to expose and manipulate data which isn’t based on AtomPub but follows quite obviously the same design considering the document’s nature of a wiki. Note that the API supports several output formats but none of which is Atom.


Atom: As far as I can tell, Facebook doesn’t offer any support for Atom.

API: Facebook has its own API which doesn’t really map well to AtomPub even though it’s quite often simple CRUD operations.


Atom: Twitter exposes friend’s timeline as Atom feeds and does it well. Their API doesn’t support it however.

API: Twitter’s API is also not based on AtomPub.

Atom: No support for Atom.

API:’s API doesn’t use AtomPub, well considering they don’t even use Atom itself, it kind of make sense.


Atom: Available but not officially supported as per the documentation.

API: Orkut’s API is based on OpenSocial which if I’m not mistaken isn’t based on AtomPub.


Atom: Not from  the public website as far as I could tell.

API: MySpace’s API is based on OpenSocial too, thus not based on AtomPub.


Atom: Offers Atom feeds for a wide range of their data from their website.

API: Flickr has its own API not based on AtomPub and doesn’t output to Atom.

Google’s various API

Atom: Extensive support for it.

API: Extensively based on AtomPub even though no public support for the AtomPub service document which kind of limits service discovery.

I’m not trying to point fingers at those services, most of them came to life way before AtomPub became seriously defined (and maybe Tim Bray was right to warn the WG it was taken too long) so it’s not really a surprise it’s not used. In most cases though exposed APIs could be mapped to the protocol as well as the Atom format but obviously that would require major and fundamental architectural refactorings which make little economical sense.

It’s worth noting that some services have hard times even exposing data without degrading their values. Atom is a well-defined protocol that offers a simple view on web semantics. Used well, it offers a fantastic ground for mashup of organized and structured data. This is added value I’m wondering if mentioned social network platforms are willing to propose. In some respects Yahoo Pipes might not have to exist if Atom and AtomPub were properly used. Atom is so much more than pure serialization format. Atom can be serialized to JSON and still be Atom. Atom offers a real path to build powerful and meaningful social graph of distributed data.

Ultimately, data is money and I assume it’s a technical issue as much as an economical one. It’s easy to help building the piping for interoperability but it seems harder to actually open up the tap of data.

That being said, as Joe says:

There is still plenty of uses for AtomPub and it has quietly appeared in many places.

Atom and AtomPub aren’t dead but are probably less visible than one might have hoped, used in more traditional places and I suggest you follow Peter Keane to get a feel for it.

Ubikod: Here I come

Today is my last day at Ipsis as I’m joining Ubikod starting from Monday to become a senior software developer.

Ubikod is a young but enthusiastic company that is geared toward the future as they’re leading the way of social network for the Google Android platform through BuddyMob.

The team is passionate and has gathered quite a great knowledge of the platform. On top of that they’re using foxy technologies like XMPP for their platform and I’m excited about getting my hands on.

Things are looking great.

Is XMPP for the web ready?

A discussion started recently on the Jabber social mailing-list about the current state of XMPP support at Facebook. If you don’t remember the idea of a XMPP network for Facebook I’d say it’s rather normal considering they talked about it back in May 2008 and nothing has really happened since then. The discussion has quickly drifted toward the difficulty XMPP knows to really make it big and you can sense some despair within the community.

It seems there are several reasons for this.

First and foremost, XMPP is rather poorly integrated within browsers. Today you have to be part of the browser if you want to succeed. Perhaps the response will come from the rather brilliant lib Strophe. Strophe uses BOSH to connect to XMPP services since Javascript doesn’t offer much access to the low level socket connection object. I hope in the future browsers will offer a built-in XMPP API that can be accessed from Javascript allowing to avoid using BOSH.

Second of all, we need big players to start accepting to let go and start entering Jabber federations so that interoperability actually works. I assume companies have yet to find a way on how they can exercise control over the data they might expose through XMPP whilst finding a way to monetize them.

Third I’d say there is a critical lack of PR around XMPP as an added value to the business. To be honest there is the same issue with AtomPub in my opinion. Both are fantastic technologies but they don’t sell by themselves and I find there is a lack of support from companies to support them. SOAP might have been a crap technology but it was backed up by large businesses that were competing with each other (for the worse one might argue).

Finally, and to me this is the most critical reason, XMPP doesn’t integrate well with the web in general. From the browser side as I suggested above to the fact that it’s rather hard to combine web application with jabber ones. Its definitely doable but requires some careful attention to your architecture. Jack Moffitt argues it’s not XMPP’s fault. It’s quite true as a protocol but I believe it’s not really the right way to invite web developers to push it one step further if you blame them for doing it wrong.

I believe XMPP has tremendous potential but it’s still has some way to go before it finds its place.

XMPP and IronPython 2 using headstock, bridge and Kamaelia

I am glad to announce that IronPython 2 is now capable of running my XMPP
Python library: headstock.

.NET has already an excellent XMPP SDK called agsXMPP that is a native
.NET/C# framework. However I’m a Python developers at heart and I had
started quite a while ago writing my own XMPP library in Python using the
most excellent Kamaelia framework (designed for concurrency).

For a while IronPython had severe shortcomings that prevented it running
simple Kamaelia applications. Today I was able to run a simplechat demo
using a vanilla IP2 on Windows with only one single modification to the
logging module (thanks Seo). To be honest I didn’t expect it to go through

The chat demo is simple enough but means more complex examples using XMPP
PubSub will work as well (they are all based on the same framework).

Now this isn’t production ready or anything. For instance the TLS support
is broken (hopefully something easy enough to fix) so you won’t be able to
connect to Google Talk for now.

Moreover I’m not sure the code is that fast considering how I had to
simulate an incremental XML parser atop System.Xml (this allows for a
XML stream to be parsed without requiring the full document or even
fragment to be read first).

This is a great news for me because it means I’ll be able to move ahead
with more work using IronPython 2.

Geolocalization and microblogging

I’ve been working recently with Adrian Hornsby who’s been interested in using the microblogging example I had setup to demonstrate headstock, amplee and some ideas about microblogging in general. Today Adrian asked me how to add some gelocalization information to a message flowing through the system. It took me just a couple of hours to implement it so that now you can push a message like: GEO text [lat,long] through your IM client. This will tell the demo to add a georss:point element to the generate atom entry which will eventually lead to a Google map to be displayed in the web page mapping the atom entry.

Notifixious – A notification platform

I’ve recently registered to Notifixious home page, a notification platform that integrates XMPP natively. Though the application is not looking as polished as one might hope it already provides interesting features.

Overall I think any work towards better notification system is the right idea. We need better ways to notify people or get notified about relevant piece of information. From a technology’s perspective transport protocols (well at the application’s level) already exist to perform the task of carrying the information, they are namely HTTP and XMPP. However there is still quite a large gap to fill about what to carry exactly. Notifixious doesn’t solve that gap per se but offers at least a good base for playing around with some floating ideas. For instance I’ve introduced today the Notifixious’s crowd to LLUP which has been initiated and carried on for a few years now to answer that specific problem. Perhaps it’ll make it way through.

Update: The guys at Notifixious just posted a message about how PubSub is heavily used by their service.

Maintenance and time zone

I have recently subscribed to the excellent Good Reads network and today I went to it only to see a message saying:

The system is down for maintenance as of 00:51 PDT.
It’ll be back shortly.

That’s okay, I mean it’s not such an essential website in my life that I have to get connected to it. I’ll visit it back. That being said I realised that if you plan on creating the next social network that everyone speaks about [1], make sure that you do your maintenance on a per-time zone basis. It’s cool to wait night in the USA to be the as little disruptive as you can but the rest of the World might not appreciate being put off in such fashion.

Of course scheduling maintenance based on a time zone means your infrastructure is designed to support it. Well, you said you wanted to be the next D.
[1] I don’t believe that’s something Good Reads is after mind you.

Release day: bridge, headstock and jlib

I’ve decided to make an official release of a few of my currently most active projects so that it’ll be easier for anyone to try out. So today I’ve released:

  • bridge 0.3.6: Simple library for handling XML. This one is just a fix release and won’t break any of your application if you were using it.
  • headstock 0.2.0: XMPP library using Kamaelia and bridge. My main focus on this release was the support of PubSub.
  • jlib 0.1.0: Python library of PyQt4 widgets to add XMPP to your applications. This one is rather new and still pretty limited but it’s already fun to use.

There you go, neither headstock nor jlib are considered to be production ready but are stable enough in terms of design and implementation so that you may already start playing with them. I hope you’ll have fun.

jlib preview – PyQt4 library for XMPP

I’ve been recently working on a library called jlib that providing PyQt4 objects and widgets that can be integrated to a PyQt4 application. In other words jlib is not a new Jabber client but a toolbox to enjoy the benefit of XMPP. The XMPP work is performed by headstock, jlib only glues headstock to PyQt4 through the use of signals/slots.
jlib is not ready yet but here is a preview of a few widgets I’ve already started working on. Ultimately my main interests is in creating a decent toolbox of widgets centered towards XMPP PubSub.