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...
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.
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 :(
Hey HNers,Social networks have proved that people can and will communicate online, sharing bits of their lives with their friends. Facebook with its millions of users is the modern and most successful example!I would like to propose a possible improvement of the privacy-related issues that arise from the central design of such networks:Use something along the lines of public key (PK)...