Of course it isn't a fundamentally flawed idea. At least, from a technical perspective.
Email is a distributed social network. It just doesn't define very many types of actions or objects.
You can create "messages" and then you can "send" them. The user sees the guts of the message -- the "from", "to", "subject" and "body" portions, mainly.
As far as I know, nobody has extended the standard email formats and protocols to support new message types that have caught on lately. Actions like "Post photo", "Tag photo", "Take a special action defined by this third party which should be displayed like so when rendered in a 'feed'".
This seems like mostly a matter of agreeing on some new types of messages and some suggested ways of handling and displaying them.
I'm not saying this has to be built on top of existing email protocols -- it's really just independent sites exchanging messages of some sort. But email is a good working example to point at today.
The hard part is getting adoption, and getting different implementations to interoperate. Once you dive into this, you find a huge soup of different projects working on different pieces of the puzzle. Some of these projects have a future, others do not. It's going to take some time for this to shake out, and for the developers to resolve issues with bringing this stuff together.
As far as I know, nobody has extended the standard email formats and protocols to support new message types that have caught on lately. Actions like "Post photo", "Tag photo", "Take a special action defined by this third party which should be displayed like so when rendered in a 'feed'".
This is a very cool and exciting idea but my feeling is that email clients are hard to code because they're full desktop applications. Even standard email clients are hard to get right - building a social network version (with encryption) would be quite a challenge.
The rewards could be nice though - such as being able to use mailinator or mixmaster for anonymity.
Gmail is an email client. Facebook is now, too. So are the default 'mail' applications for Android and iOS. And let's not leave out Emacs :)
The challenge of email (which comes with its advantage of being ubiquitous today) is its plethora of standards documents one must read and respect if one wants to make a serious go of developing software that will work well with most of its corner cases.
I'd hazard a guess that none of the examples you gave were easy to code :-) Also, I'd argue that Gmail and Facebook type clients are non starters as its hard to do meaningful encryption in Javascript since you always must trust the server.
But if you disagree, please write one - I'd be a very willing beta tester and would even be keen to help in a limited way.
I'm not saying it'd be easy to just sit down and code one weekend! But really, are we expecting the "federated social web" people are talking about to be much easier to code than email software? We want it to do much more stuff, so it'll probably be harder.
Also, I think it's implicit that you trust your server. It's other people's servers you've got to worry about.
I just thought of another potential challenge - SMTP limits. I think Gmail limits you to sending 40 messages per day for instance. This sucks if you have >100 friends.
Those limits are imposed by existing email software. The real underlying challenge you are getting at is dealing with spam. And that would be just as much a challenge with any distributed social network too, for more or less the same reasons.
Email did this badly from the start, because it started in a much more trusting world of people who did not spam one another. Authentication features were added later, but there was no requirement to use them, which limits their effectiveness.
Perhaps for a project starting fresh now, this can be handled better?
I should add that the trickiest bits aren't the apps that could "run on top of" a distributed social network like photo tagging or games. It's setting up the social graph those apps use. How do you add a friend? How do you accept or reject a friend request? What sort of authentication and other security features should everyone understand and support? There are proposals for solving these issues but getting it a) secure and b) widely agreed upon and supported would be a Good Thing.
Actually, there were some fundamentally flaws in the particular version of a distributed social network that diaspora started with. They imagined a network of web servers that would each host a piece of diaspora and that each of these would provide secure sharing. That system pretty much requires trusting all the server-providers because the decryption happens on the servers.
Email is a distributed social network. It just doesn't define very many types of actions or objects.
You can create "messages" and then you can "send" them. The user sees the guts of the message -- the "from", "to", "subject" and "body" portions, mainly.
As far as I know, nobody has extended the standard email formats and protocols to support new message types that have caught on lately. Actions like "Post photo", "Tag photo", "Take a special action defined by this third party which should be displayed like so when rendered in a 'feed'".
This seems like mostly a matter of agreeing on some new types of messages and some suggested ways of handling and displaying them.
I'm not saying this has to be built on top of existing email protocols -- it's really just independent sites exchanging messages of some sort. But email is a good working example to point at today.
The hard part is getting adoption, and getting different implementations to interoperate. Once you dive into this, you find a huge soup of different projects working on different pieces of the puzzle. Some of these projects have a future, others do not. It's going to take some time for this to shake out, and for the developers to resolve issues with bringing this stuff together.
A lot of this work has been going on without a lot of fanfare. See for example http://indiewebcamp.com/ or http://www.internetidentityworkshop.com/
Naturally, it couldn't hurt to bring a lot more help into these efforts.