Never doubted my preference to be in the CREATING side...

This is the approach that so many new social nets are taking and then struggle to "convert" users. OTOH, "flipping some switches" to enable social features in someone's email client would probably be more straightforward for the majority of email users.

Besides, the "augmented email" would actually be a transitional model to "educate" the users into the distributed social net. After that, changing the underlining protocols to be a better/faster/cheaper ones would be natural for the techies and transparent to the average user.

> If you aren't subscribed to a source when it sends something out, you will never see that thing, even if you subscribe later

Well, from my POV, this is actually a benefit: I get the power to choose if the "new" friend gets to see all my history or not. As you later suggest, syncing wouldn't be a big problem anyway...

Email would serve as a notification/status passing protocol and the actual content would be served by the "embedded" web server.

The imap+content servers could ofcourse be hosted in owned hardware/domain or provided as an ISP service.

Edit: to add more info on my approach: The content/web server would also host the UI to access/use your social net. I'm thinking of a SquirrelMail plugin as a first attempt, or a GUI overhaul shifting the primary focus to the social net aspect. The regular email functionality could also be present through a classic looking SquirrelMail interface, so the user can conceptionally separate the email "stuff" from the social "stuff" if he/she needs it.

  - embedded in every page so the user logs in whenever he/she wants
  - always shown so a single click starts the process
  - keyboard-friendly by using Tab to navigate to the input boxes
  - Javascript-less friendly, so to be able to log in without JS 
   and not having to "bypass" my beloved NoScript
  - big-styled (as the rest of the webapp) so to be tablet/finger friendly.

The popup/dropdown login form is certainly cool and space-saving, but I couldn't come up with an implementation that satisfies me...

There are not many good examples of privacy violation up to now, but as more individuals participate and share info, the "problem" may rise.

You know, when "talking" with your friends, you actually want to do just that: talk with your friends. It is rather unsettling to know that most probably there are "eyes" that may watch over your info. These eyes are not FB's or Google's (they just want to sell things).

My examples may not be the best...but I do know that day by day, I feel that I lose hold of my data :(

OK, I understand what you are driving at. I still am a little confused by the concept where you willingly post "your data" into the essentially open ether, then lament that action.

How about not posting it to Facebook in the first place? It seems that the implied contract with posting data into public places is that the data is in fact public.

What you propose is interesting, but I'm not sure it provides even basic security-by-obscurity. The keys would either have to be so overly distributed to your friends that they essentially become public. Or the data stream has the same message encrypted over and over again, which makes the size of the data grow exponentially (and also most likely makes it easier to crack).

The public key is used for encryption, not decryption, so anybody can have it...To read a message I send you, you use your private key. The message will be encrypted by me using your public key. So, any friend can send me a message but only I can read it. If more friends are to be able to read the same message, the string must actually include an instance of the message, encrypted with the "other" friend's key.