AFAICT there are only two ways to provide that basic feature:
(!) A centralized service like Facebook that manages the identity network. Any centralized organization is most likely ultimately going to exploit the fact that they own the network for their own gain, financial or otherwise.
or
(2) A decentralized service based on the similar cryptographic math as bitcoin, where every user gets one token representing their identity, and some sort of way to propagate changes to their identity signed by that token to everyone they are connected to and this needs to be accomplished in such a way that you can always re-establish the links to your friends in the network to be able to sync data.
I can't even begin to imagine how you'd develop the latter into a form that would be usable and therefore adoptable by the average person.
- tried-and-tested public key cryptography techniques
- using e-mail as a buffered delivery mechanism (everyone has an e-mail account that can store plenty of messages until they're next on-line)
- borrowing the typical DVCS copy-the-whole-repo approach so you've got distributed back-ups
- writing a native client for whichever platforms you wanted to support.
If someone wants to make money off it, come up with a neat physical way to connect something personal but memorable to keys of sufficient complexity to encrypt everything robustly: mobile app, USB device, whatever.
The only obvious limitation is physical bandwidth and storage capacity, which would make copy-the-whole-repo unsustainable if people kept sharing lots of photos/multimedia content but their friends don't want to "download" all of it. How much this will matter as data storage and communication network capacity increases is anyone's guess.
In the meantime, if you were willing to accept a delay you could have a request/reply system to fetch larger items, or someone could charge a modest sum of real money to people who want to use an actual centralised escrow-like system that is always available to their friends even when they're not on-line. The system doesn't need to be able to see into any content, just to act as a more real-time substitute for the default buffered transmission via e-mail.
PS it will be completely F/OSS, most likely GPL depending on contributor consensus.
But yeah, you've hit the nail right on the head. Obviously, my will fall into your (2) category, so we've got some major usability and cryptographic hurdles to tackle. But please rest assured that the solutions exist and that I've got most of them hammered out in my mind - the rest just require a little brainstorming and puzzle solving.
PS it will be completely F/OSS, most likely GPL depending on contributor consensus.
With #2 you'd still need trusted sources that can verify that a person i found via johndoe@acme.com or +1 (914) 555-1212 is in fact the owner of that email or phone number.
The rest is overthink.