I've been doing something similiar to this. Here's what I'm finding working with lots of different 3rd party sites ...
- not every site has an API or RSS so you have to CUT+PASTE :(
- even sites with API's have poor documentation (code, txt) so it can be difficult to use
- posting data (say to twitter,flickr ) is way easier than extracting via an API/RSS
- no company(ies) want(s) their hard-won user data to be used commercially (check the legal agreements) so while you can integrate each site requires permission - yuk!
- solve the password & authorisation problem for each 3rd party site
- abstract an API to talk to each service (eg: as Perl does to databases in the DBI module)
- support the most popular sites that people use first (flickr, twitter, Facebook, MySpace etc)
- constrain the features you want to support for each 3rd party site (eg: notifications by friends in twitter, or flickr. New books suggested in http://www.librarything.com)
- keep up with changes made to each service, handle bugs, quirky code
- synchronise 3rd party added data and client side added data (the "add in 1 place" bit mentioned). This means being able to either/or add data at the client or get the data the user added at the 3rd party site as well and somehow sychronise them
- you need tools to extract, manipulate RSS/ATOM feeds. A boon because you don't need API's
- using your abstracted API be able to message various different services
and here's the hard bit depending on the service. Do you want to send everyone on Twitter a photo update if you have entered 20 flickr photos?
- you need to capture store, query, link check and update the various links, metadata and information that message generates.
- layering of data. Intelligent hierarchies of data that be queried by other
- flexible presentation layers that can export variety of data formats web pages as to XML, RSS files, mobile phone SMS, etc.
- flexible presentation layer(s) that can support different levels of information from a complete archive of past posts to their titles or individual tags
- metadata ... support things like tags, microformats at a per document level and be flexible enough to allow for more formats that arise.
In all this I can't help think that maybe just solving a few little problems might be a better starting point and if you do so make sure it's the open web and not some roach motel that sucks up data instead of allowing data to flow.