A few months ago Dave Winer posted the subscriptions harmonizer RFC which had the following problem statment and goals

Here's a new Web Service for people who use aggregators and have more than one computer. The problem: I subscribe to a feed at home but my aggregator at work doesn't know about it, and vice versa. This document is an RFC, and a roadmap for deployment.

Goals 

1. The solution should work equally well for any aggregator. It should be possible, for example to use NetNewsWire on a Mac at home; Radio UserLand on a Windows machine at work; or AmphetaDesk on a Linux laptop. The subscriptions of each should be harmonized without the harmonizer knowing what app is talking to it.

2. It should rely as little as possible on the centralized component. I will operate a prototype service at Harvard, but it will be limited to 1000 users, and each user will only be able to harmonize 100 times per day. The protocol will be openly specified and clonable. I'm only trying to solve the technological problem, not the economic one.

I didn't like the proposed solution for a number of reasons, the main one being that it required a centralized server that was outside my control. However I had expected some adoption of this proposal by various aggregators and blogging tools but there wasn't much of a ripple caused by Dave's RFC. 

A few weeks ago Steve Tibbet launched a discussion on the RSS Bandit messageboard on subscriptions harmonizers. He also checked-in some code which I finally got around to reviewing and modifying today. The discussion revolved around how best to synchronize feeds in a way that gives users choice and flexibility. We settled on four approaches, three of which are currently checked in.

1. BLOG STORAGE: Many users of news aggregators also have a blog which exposes APIs for remotely editing the blog using tools like w.bloggar. Also such blogs usually have a way to store and display a blogroll such as the one on the right hand side of my blog. Since this infrastructure already exists it makes sense for users to be able to use their blog as the host for uploading/downloading their feed list. In fact, the feed list on my blog was posted from RSS Bandit and there is currently code checked in that allows syncing of blogrolls with dasBlog. I interacted with my blog using this web service.
   
   
2. SYNDIC8: During the discussion,  Bill Kearney who runs Syndic8 pointed out that there already exists hosting for blog rolls as well as an APIs for programmatically interacting with these blogrolls from the web. This is an example of blogroll on Syndic8. I was going to code the feature to enable syncing of blogrolls between RSS Bandit and Syndic8 this morning but the site was down.
   
   
3. FTP: This is self-explanatory. One can use an FTP server as the sync location for uploading/downloading one's blogroll.
   
   
4. UNC file path: Similarly self-explanatory. A network file share could also be the location of the synchronization point from the blogroll.
   

Below is a screenshot of the remote storage configuration tab.

ISSUES WE'VE COME UP AGAINST

• Steve and I debated on whether the blogroll should be automatically synced with the remote site on startup and shutdown or whether this should be only done when directed by the user. Steve sees this feature as being akin to a mail server like Exchange and a client like Outlook in which case it should be automatic. I tend to avoid adding features to RSS Bandit that involve automatic downloading unless specified by the user. In all likelihood the compromise will be a flag that indicates whether syncing should be done automatically or not which will be off by default.

• OPML which is the format used by aggregators for storing blogrolls is rather poor when it comes to storing the kind of state users would find useful in asynchronizing application. I for one am more interested in making sure that my aggregator at home can tell my aggregator at work which stories I've read so it doesn't mark items I saw at home as unread than I care about keeping the list of feeds I am subscribed to in sync.All this information is already stored in the file format used by RSS Bandit and it is unfortunate that users of news aggregators have to use a handicapped format like OPML instead. To make this feature useful it is likely that OPML either has to evolve or be replaced. Clemens Vasters, the lead developer of dasBlog, would prefer that I evolved the OPML I use by adding namespace based extensions for the information I deem pertinent (stories that have been read, refresh rate, etc) than creating a new format from scratch. I will start working on what this could look in the next few days and hopefully dasBlog & RSS Bandit will support these extensions in some way by next week.