FriendFeed is an example of a new type of aggregator where multiple data types, or streams, for a user can be bought together. The difference between this new type of aggregator and the standard RSS feed-reader type of aggregator is that the later does a good job of supporting a set of formats that are almost standard, while the new aggregators such as FriendFeed are building in app-specific support.

The disadvantages of this model are that only the selected applications can participate in the aggregator and network, a disadvantage to smaller providers and a position that would only cement the place of the more popular services. In addition, service-specific API support would not scale very well, as every API update and nuance would have to be tracked, maintained and debugged.

A very important issue is how feed and data types should be standardized to allow all application providers to participate in aggregator ecosystems such as FriendFeed, rather than just the 41 selected and supported.

The 41 services provided are just feeds, be it plain descriptive XML or RSS or Atom or some variation thereof, they are effectively feeds of varying data types. They can be easily broken down into the different categories and hence data types - such as link feeds, content feeds, image feeds, event feeds etc. etc. Currently each application API developer implements what they feel is a good format for an API (and often poorly) and it is often very different to what similar applications provide.

With generic feed standards, either through the use of Microformats or the use of defined namespace extensions, it would level the field so that any application or service can participate rather than those that are popular amongst the digerati. Imagine if the earliest news feed readers only supported a set of 41 sites? So you wouldn’t even be able to subscribe to your own blog, let alone the blog of a friend or colleague.

For some reason, outside of content feeds (blog RSS feeds), the other formats have developed in a sporadic and non-standard manner. The standardization of feeds around data types has almost reached a point of becoming an urgent priority, as the mechanisms that previously worked well in defining standard formats broke down with the new types of shared media.

FriendFeed recognize the problems and have commited to supporting the Media RSS standards, but Bret from FriendFeed also said that opening up the aggregator could result in more noise and spam which would drive away users. I believe that the problem may be overstated, and a subscription-based model effectively results in pure, chosen content.

Either way, the next messaging or photo sharing application being built should be able to build an API based on a standard spec for each data type. While there are plenty of new standard format efforts (and new efforts seem to launch every other day), there hasn’t been a best practice decision made by the key influencers (eg. FriendFeed - a bigger stream aggregator) and developers to force the issue.

This could be solved by a large-scale web services proxy, but it would be better if format proxying was only an interim solution.