"... Not just cut 'n' paste: cool mashup features like synchronization and single-point identity management (so you don't have to tell Facebook and Twitter what you're doing, you can just enter it in one place) ..."
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.