This is an interesting idea that uses email/IMAP as a transport for social message passing. It plays to the strengths of multipart email messages having a human-readable part that is as rich as possible for email client viewing (when users aren't in a social-aware application), and a machine readable part (JSON) for plugging in to the rest of the social infrastructure.

Here is their own summary of problems with this approach (from the article):

  * Not all users have a suitable email service (requires IMAP to support the
    “read it if you feel like it” model).

  * Servers tamper with messages as a normal part of existing infrastructure
    (especially mailing lists and spam filters).

  * Basic IMAP does not provide the full gamut of features required (some mail
    servers don't support all IMAP verbs).

  * Mail systems may have standard protocols, but individual implementations
    may have different performance characteristics.

Something like this doesn't NEED to work "ontop of" email though. It just needs to work LIKE email, and be decentralized, where anyone can run a "facebook like" social networking server that all know how to talk to eachother. I certainly do applaud efforts like Diaspora. If only they could actually take off. Maybe this approach of working "on top of" the existing email infrastructure will help adoption, IDK. But It seems like it will be equally as challenging to make popular. Might as well write a new protocol that is simply similar in its decentralized nature, so we dont have these issues.

Yeah, I think you could combine a number of existing services to make a network- email, twitter, HN, github, a linking service (this github profile = this twitter account) and an address book service would get you going for a dev network. The challenge would be to combine the data meaningfully, but I think the basics can be done. Plus, your address book amd email could be private services.

The protocols already exist, but who will run the servers?

Why not ISP's?

What's their incentive?

There are certain message formats which should not be tampered. PGP/MIME attachments (RFC 2015 / RFC 3156) for example, though many mime application attachments generally don't take well to being arbitrarily modified.

Doesn't mean it doesn't happen. But it shouldn't.

Yeah. Try looking at an email before it goes into Microsoft Exchange via SMTP, then compare it to the same email that Exchange then goes on to expose via IMAP. They bare no resemblance.

GPG/PGP keys were the greatest missed opportunity for social networks. For example widespread acceptance of gpg/pgp would have been a great way to reduce spam.

About ten years ago I had two customers who liked us to all encrypt all email. It was easy to do and fairly transparent - strange that this never caught on, at least in my experience.

"Why Johnny still can't encrypt" http://chariotsfire.com/pub/sheng-poster_abstract.pdf

The best way to push the adoption of GPG is through a HTML5 crypto API that would include it. A social network or email service that doesn't work in the browser would be inaccessible from cyber-cafés or from work (two of the most popular accesses to the web in developing countries).

I usually try to avoid sweeping generalisations, but in this case... I just can't see any use at all for crypto communication where the end-points are not secure.

Or increase privacy and/or authentication of posts/messages.

From https://github.com/tpurtell/socialbar/blob/master/chrome/con... :

    //fallback for running in chrome
    function md5(str) {
        return "e4d909c290d0fb1ca068ffaddf22cbd0";
    }

Huh?

  $ echo -n "The quick brown fox jumps over the lazy dog." | md5sum
  e4d909c290d0fb1ca068ffaddf22cbd0  -

It seems to be a commonly used example md5 sum.

Seems like the md5 function is only used to fetch a gravatar image (see ssb.js):

https://secure.gravatar.com/avatar/e4d909c290d0fb1ca068ffadd...

What's even stranger is that : https://www.google.fr/search?sugexp=chrome,mod=17&source...

Seems like there is nothing new under the sun.

http://xkcd.com/221/

I wondered where I had seen the name of Monica S. Lam (one of the co-authors) before. Turns out she's one of the co-authors of the Dragon Book.

I think this could be a part of the solution to the 'replace email' theme by PG[1].

Since their API abstracts the email sending/receiving details away AND gives specific tags to work with [SHARE, LIST, GET, WAIT], one could for example write a TO-DO app or maybe a bug tracker that notifies and updates when a mail with a specific tag comes in.

As I understand it, the problem with building smart mail clients is that there is no standardised format that all clients will agree upon. Using this API circumvents the problem, as the mail client does not actually perform any actions. Using this API's capabilities for "smart" mail clients instead of "social" apps could be interesting.

[1] http://paulgraham.com/ambitious.html

It seems that one doesn't have much of a social network without the "friend discovery" and "stalking" aspects that this paper ignores. While e-mail based clients for private exchange of personal data among friends would certainly be welcome, it wouldn't quite serve the same role as facebook.

Haha far out, I've had an index card on my wall for the best part of this year that says "Email client as social network". D'oh!

I thought about this as well but decided to drop the idea, because I wasn't interested enough in email to learn about the underlying technologies.

You beat me to thinking of the idea and not doing it first! I had only been thinking about this for the prior week.

You know, you could both still do it. Or you could just build on the work that's been done for you. Looks like nobody's committed for nearly a year.

Edit: http://mobisocial.stanford.edu/news/2011/07/build-stuff-with...

I would've thought you'd want it the other way around, ie. integrate email into your decentralised social network. It'd certainly make spam easier to detect, and email easier to filter.

I gave the idea of decentralized social network some thought after reading about facebook chat monitoring. Imho, privacy is becoming such a big concern that i think this is what the next generation of social networking will be like. Being able to store your profile data in your own cloud account on dropbox or google drive would be pretty neat. Perhaps something more sophisticated with its own data provider model and a protocol. Sounds like a neat startup idea.

How is this going to mix with the user's other email? I certainly wouldn't want to see all the Mr. Privacy messages in my mail client and while I can easily setup a filter, many users would not be able to do that.

end to end GPG encryption also seems like required feature. Then your details really are secure from all the intermediate parties.

It automatically sets up a separate folder and routes all Mr. Privacy messages (there is a specific format for these) into that folder. If you wanted to see them, you could. But normally, they wouldn't crowd your inbox.

Storage space is not really a big problem with most major mail services offering >5 GB, but I wonder where all the static content would be stored, and how it gets updated when there is a change (eg. user profile picture). Surely, one wouldn't store those outside the mailbox?

Why not just send them as an attachment to a "Profile Picture Changed" event message? Then clients can delete the old attachments when they get the new.

They could integrate with the storage / media service provider of your choice i.e. Dropbox, iCloud, YouTube, Flickr... Etc!

As the authors have noted, there is no way to invalidate content. So those drunk posts cannot be certainly deleted from your friends's feed. Personally I don't see a big problem with this, but it definitely needs to be addressed.

I hope they add encryption to it. Intermediate SMTP servers are untrust worthy.

If you built a client on top of email, you could add PGP encryption as part of the service. Getting and accepting friend requests performs the key exchange handshake needed and voila! encryption. There's some nuances here that would need to be addressed, but nothing particularly showstopping.

Governments/ISP/School/Company could ban obvious encrypted SMTP message.

Encryption should be done in a obfuscated handshake way. That's what this paper lacks (and this really matters.)

Also if you have your own IMAP/SMTP server running, you should really think about some kind of TOR-like relay network to hide your server IP.

Good idea - we've been doing something similar for groups/companies with just the header data of email. The Datahug.com API allows developers to build on top of the email social graph.

we are gonna miss all the good stuff from recommender system.

This paper is two years old. Presumably if anything was going to come of this idea, it would have happened by now.

What's the point of posting such an old PDF as it were new? To a site with the word "News" in its name? It's interesting, yes, but it's misleading too.

I guess I'd say It's valid if people weren't already aware of it.

I wasn't aware of it, and I'm actually building it.