Many things on a modern desktop are most useful if they can easily be shared with different people or over different devices: calendar information, notes, music, photos, contacts, your entire desktop.
One aspect of sharing is to give the user a clear picture and control over what is shared and with whom. A design for that is here: Design/SystemSettings/PrivacyAndSharing
Another aspect of sharing is that it is often necessary to have an account on some remote system or web server to upload things you want to share, and it would be good to share this account information in the desktop, e.g. google account information to get both your gmail mail and your google calendar contents. This would require somebody writing the "Web Accounts" panel, which would integrate Telepathy accounts, libsocialweb accounts, and possibly Evolution ones too.
Finally, the nautilus-sendto redesign needs to be completed.
For the 'web accounts' part, DavidZeuthen
For the 'Empathy/Telepathy' part, GuillaumeDesmottes
For the Rygel/DLNA parts, ZeeshanAli
For the Vino/Vinagre parts, DavidKing
Various technologies are available that allow sharing of various things on a local network, or by exporting them to a central server, and they are used in various modules: avahi, rygel, gnome-user-share, vino, snowy.
Work on a unified control panel for these various sharing technologies has not been started.
A library providing a unified storage for account settings already exists (libaccounts-glib), complete with Qt bindings too. It is used in Maemo6 (harmattan), and the Telepathy account manager storage has been modified to support it as well. It is an unencrypted settings storage based on sqlite, using D-Bus for change notifications. Account settings are grouped by section, according to the service type they refer to, and the various services on an account can be individually enabled/disabled.
Password storage could be delegated to the GnomeKeyring, or to the (SSO service from MeeGo), which provides an optionally encrypted storage for user credentials and a plugin-based authentication functionality that avoids exposing passwords to client applications. The credentials storage resides on an encrypted loop partition which can be mounted and unmounted according to hardware keys or user interactions, also depending on installed plugins. The SSO daemon and the plugins are written in Qt, and client libraries exist for both Qt and Glib based applications.
How to Help