Mashup Camp IV Day 1: AOL and Feed Mashups

Since sponsors are allowed to propose sessions, AOL proposed a session on feed mashups where they gave a short presentation/demo of their new customizable portal page (comparable to Netvibes or iGoogle) that also includes Mgnet, a way to do what they refer to as mashing up feeds, although it appears to be feed aggregation and filtering. Maybe that’s a good question: when does aggregation and filtering (which are basically functions of a feed reader) become a mashup? It appears that some of the interactive “mix & share” functionality is similar to the “share this” functionality in Google Reader, where you can set certain posts (or even a whole folder/collection of third-party feeds) to become part of a new, customized feed that can be shared with others.

The cool part is a set of APIs (both REST and RPC) that allow this functionality to be accessed programmatically rather than interactively:

• Manage users’ bookmarks and feed subscriptions, organized by tags or folders
• Retrieve feed articles
• Apply chained operations (sort, trim, html) during feed processing

This allows aggregated feeds to be accessed in an application as a URL, create a mixed feed from a folder or tag, or dynamically create a synthetic feed from several feeds. This makes it similar to Yahoo Pipes for feed manipulation, but with a bit more flexibility.

AOL also seems to  be providing the only t-shirts at camp, since there’s no official Mashup Camp t-shirt this time; having scored a t-shirt, I’ve fulfilled my home obligations and can relax. 🙂

The session turned into an interesting discussion about widget standards, including how IBM and BEA are both supporting Google gadgets in their portals, making it somewhat of a de facto standard. Even the AOL guys admit that a standard widget format (even if it’s not theirs) is valuable, and they also support Google gadgets.

We also discussed how the difficulties with authentication for feed subscribers is part of what’s inhibiting adoption by businesses, particularly for delivering any sort of secure information to customers outside the firewall, such as a feed of transactions from your financial institution. AOL is using OpenID as a provider (every AOL username also corresponds to a set of OpenID credentials), but isn’t accepting OpenID — this seems to be the way that a lot of sites are going, which is not going to work until they all start accepting as well as providing credentials: providing OpenID credentials without accepting them is little better, in my opinion, than implementing a proprietary credentials scheme. One attendee pointed out, with some head-nodding around the room, that the dream of OpenID may actually be better than the practice since most people don’t want a single point of failure for their online credentials: you might use OpenID for all the logins that don’t contain any sensitive information so as to have a single signon around the web, but are unlikely to use it for financial and other critical sites.

I think that feeds are becoming more important in general, and also are going to start making some significant inroads within enterprises, as I saw at the recent Enterprise 2.0 conference. Inside the firewall, the credentials issue gets much easier, but there’s a much bigger cultural gap to using feeds as applications.