What’s SUP?: FriendFeed’s Modest RSS Proposal

The RSS wizards at FriendFeed (a social news aggregation site) are proposing a new way to distribute and fetch RSS feeds faster. The proposal is a simple one: publishers provide a centralized RSS to inform readers which feeds have been been updated since their last visit. The benefit? Your news fast.

FriendFeed's Gary Burd and Paul Buchheit (both former Googlers) want to download your RSS feeds as rapidly as they can without taking down your servers in the process. They've proposed a workaround which will spare your servers but still fetch your site's RSS feed faster. The proposed platform: Simple Update Protocol (SUP).

Think of it this way: When you go to the movies, you don't go around to each theater to see which movies are playing and when; it would take all of your time and effort running around from theater to theater. Instead, you check the kiosk out front.

Your blog publishing system provides a RSS kiosk, or ping feed, to let FriendFeed (and potential RSS readers) know when and what has been updated since its last visit. Friendfeed doesn't have to go theater to theater to see which movie is playing. It also checks all RSSs in a domain at once, eliminating the need to download each one separately. Polling is less frequent, but more accurate. By cutting out a lot of wasted data transfer, it reduces the load and gets the relevant information directly.

How do you implement such a thing? A modified link attribute in your RSS or Atom feed informs RSS readers, like Friendfeed, the ping feed is available. Under SUP, publishers would automatically generate ping feeds using the timestamps in their database.

The benefits, according to Buchheit, include:

* Simple to implement. Most sites can add support with only few lines of code if their database already stores timestamps.

* Works over HTTP, so it's very easy to publish and consume.

* Cacheable. A SUP feed can be generated by a cron job and served from a static text file or from memcached.

* Compact. Updates can be about 21 bytes each. (8 bytes with gzip encoding)

* Does not expose usernames or secret feed urls (such as Google Reader Shared Items feeds)

FriendFeed is already test-casing; its SUP Feed is already online. An example of implementation is available using Buchheit's FriendFeed RSS link. Sample code under the Apache license and project information is available via the SUP Google Code page.

Will it catch on? It's intuitive and pretty simple in a "duh, why didn't I think of it first" way. If other RSS readers and providers (such as Wordpress, Twitter, Google Reader and FeedBurner) join FriendFeed and implement the idea, it means less used bandwidth for readers and publishers and faster RSS access all around. Sounds like a win-win to me.