Posts tagged ‘pubsubhubbub’


Did Google Reader just turn on full PuSH support?

Jesse claims the answer is yes.

This is a test to find out for myself.

Update: It worked!  If your blog is PubSubHubbub enabled any new posts will show up in Google Reader immediately instead of taking the usual 20-30 minutes.  Now you have more incentive than ever to get PubSubHubbub support on your blog!

 5 comments

Updated PubSubHubbub plugin for WordPress MU

I just updated my PubSubHubbub WordPress plugin to work with multi-user installations of WordPress and also verified that everything still works with version 2.9.1 of WordPress. If you haven’t installed the plugin yet, I encourage you to check it out.  It’s the fastest and easiest way to realtime enable your WordPress blog. I’ve now had over 1,200 downloads of the plugin and I’d be stoked if you added it as well. You can grab the latest version at:

http://wordpress.org/extend/plugins/pubsubhubbub/

As always, please let me know if you have any issues with the latest version.

If you’re curious what I changed, it turns out one of the secrets to making your plugin MU compatible is to register any of the settings you want to use.  This forum entry proved to be the solution I needed.

If you have no idea what I’m talking about, this post about PubSubHubbub is a good place to start.

Hope you’re having a fantastic weekend.

 4 comments

If only we lived in an ideal world

After my last post on the importance of IP addresses, I emailed a few friends I respect for feedback.  I’m glad I did because there’s an important aspect I neglected to address.  Brett Slatkin made this comment:

The post makes sense. What I’d focus on in part is that reputation based on IP is fundamentally broken, which is why email sending with SMTP and feed fetching through polling are both fundamentally flawed. We need better protocols that use client tokens (like OAuth) to do rate limiting instead of using just IP addresses.

I hope this would be obvious, but neither SendGrid nor SuperFeedr are optimal solutions.  Let me be more blunt.  In an ideal world, neither company would have reason to exist.

I also understand that as an entrepreneur you have to dream big while also realizing that significant change usually doesn’t happen overnight.  One day we may all drive Tesla’s, but that doesn’t mean we can do away with our gas stations quite yet.

I’m a firm believer that companies should focus on solving the problems that exist today while being ready to adapt as better solutions get adopted.  For the sake of completeness, here’s the missing footnote to my last post:

The ideal solution to the problem of polling feeds is PubSubHubbub.  The ideal solution for accessing authenticated APIs would be for parties to use token based authentication like OAuth or WRAP.  And as Isaac Saldana mentioned in the comments, the ideal solution for email reputation would be widespread adoption of DKIM which moves the reputation to the domain instead of the IP address.

Those are the ideal solutions.  Too bad we don’t live in an ideal world.

 4 comments

Head to head: PubSubHubbub vs. rssCloud

Today I was honored to write my first guest post for TechCrunch in an attempt to give a detailed comparison of PubSubHubbub and rssCloud both from a technical and business perspective. I’m pretty sure I can now lay claim to one of the geekiest posts to ever make it onto TechCrunch.

The post was titled RSSCloud Vs. PubSubHubbub: Why The Fat Pings Win and was really a follow up to my previous post on The Protocols Powering the Real-time Web.  If you’re arriving here for the first time from TechCrunch, that post is a good place to start.

As a reminder, you can add PuSH support to your own blog by downloading my WordPress plugin for PubSubHubbub.

I can’t tell you how incredibly exciting it is for me to be a part of something that I believe will be the future of the web.

 3 comments

The protocols powering the real-time web

In the past few weeks there has been a lot of discussion around the rise of the real-time web, including posts from TechCrunch, GigaOm, ReadWriteWeb and Scoble.   A lot of the talk has been around Twitter, Facebook, Friendfeed, OneRiot and of course Google.  You don’t have to be a genius to figure out that real-time is the future of the web.  I believe there is a huge need for the tech community to develop new protocols that will power this fundamental shift in how web apps work.

The problem is our existing protocols are request driven instead of event driven.  The web we know and love wasn’t built with real-time in mind.

Tim O’Reilly sent a tweet from OSCON08 that really captures the essence of the polling problem:

On monday friendfeed polled flickr nearly 3 million times for 45000 users, only 6K of whom were logged in. Architectural mismatch. #oscon08

At EventVue we have a dedicated server that does little more than poll for new blog posts from attendees.  We have a few tricks to reduce the pain, but we’re still polling thousands of blogs every hour even though 99% of them haven’t added any fresh content since the last time we checked.  With blog posts, people are used to having a small delay before they show up in Google Reader or other services.  We’re not so forgiving when it takes 30 minutes for a tweet to show up in a client application, even though getting real-time data from twitter using polling is virtually impossible.

So what is the solution?

Some people have said that XMPP holds the answer, but how many developers do you know who have set up an XMPP server before?  Right.  Me too.  XMPP may be a viable transport method but I think we’d be better off using something that is simpler and more familiar to developers.

Another prominent response to the polling problem is the Simple Update Protocol (SUP) that was proposed by Paul Buchheit from Friendfeed.  SUP is certainly an improvement over our current protocols, but what frustrates me is that it only reduces polling instead of eliminating it altogether.  It may make sense for FriendFeed, but it’s not something I would add to my blog.

My favorite approach is PubSubHubbub that was proposed by Brad Fitzpatrick and Brett Slatkin from Google.  PubSubHubbub might have a horrible name, but the protocol is exactly what we need to fix our polling problems.  It’s lightweight, simple to understand and built on top of basic HTTP.

PubSubHubbub is a simple extension to ATOM that uses webhook callbacks to deliver practically instant notifications between servers when a feed is updated.  The protocol is decentralized and free.  Anyone can run a hub.  Anyone can be a publisher or a subscriber.  I like that it eliminates polling altogether and is incredibly simple to implement.  I took a stab at writing the PHP client library and was able to take it from protocol spec to code in less than 2 hours.

If you’re interested, you can check out my PubSubHubbub PHP library and download and install the PubSubHubbub WordPress plugin I wrote as well.

It’s worth mentioning the role that Gnip plays in all of this.  Gnip has been leading the charge against the evils of polling.  I’ve been a big fan of their service and have written before how they helped EventVue.   But at the end of the day, the winning technology shouldn’t be in the hands of one company — it should be open and distributed.   Open protocols don’t eliminate the need for Gnip.  Trusted hubs like Gnip will play an important role in handling the flow of data between publishers and subscribers.  Companies will pay good money to off-load that work, and Gnip is already at the center of that opportunity.  I’d love to see Gnip embrace the open protocols that are being developed and lead the drive for adoption of PubSubHubbub in particular.

I’m excited about PubSubHubbub for a few reasons.  First, it opens the door for a whole new range of real-time applications that simply aren’t possible today.  It’s also a chance for me to contribute to solving a really big problem and an opportunity for me to get in on the ground level of something I believe is going to be huge.  I wasn’t able to contribute to the design of HTTP or sit in on the conversations that led to the development of the RSS protocol.  But one day I’m going to be able to brag that Online Aspect was the very first blog on the web to support PubSubHubbub.   And for a geek like me, that’s pretty cool.

 28 comments