

IMAPSN: a spec for building social networking clients using SMTP and IMAP. - jkantz
http://imapsn.github.com/2010/imapsn-client.html

======
lzimm
I've actually been thinking a lot about this kind of stuff lately. In fact, I
think when you start to think about a person's email address as more than just
"an address where you send them email", and rather, as a globally unique,
completely ubiquitous address to connect with them in general, there are a lot
of really interesting applications you can build around it that completely
supplant existing protocols.

Given that they're explicitly about people in particular, personal web pages,
social networks and distributed code reviews are kind of the tip of the ice
berg. How nice would it be to have a structured project management protocol
that operates over email, but allows people to hook up whatever client they
want to interpret it, allowing them to work in a way that best suits them?

~~~
sfard
You know at the end of Kanye's runaway track where there's two minutes of
heavily distorted vocals. I think that's a strong analog for what you're
seeing here. Essentially he's using his globally-identified voice in that
track to send messages beyond just lyrics. If project management protocols are
his passion, then this distortion effect is email.

~~~
srccode
I've really been thinking about this a lot, and maybe if they had something
called "wofin" and pitch it then we can sit back and enjoy the margin.

------
bitdrift
I was also thinking about something similar a while back until I discovered
oStatus (<http://www.ostatus.org>) and its related projects (ActivityStreams,
PubSubHubbub, Salmon, etc). While I think an implementation over SMTP could
work quite well, I think using PubSubHubbub has a reasonable advantage in that
doesn't require app developers to use ports other than standard HTTP ports (80
& 443). This isn't a big deal for major websites, but part of the advantage of
having a truly distributed social network is that even the little guys can
join the game--which means it should be as easy as setting up something like
say, WordPress.

------
hypest
Interestingly, just yesterday this very idea came to my mind. I imagined one
more core component though: a content server (think: web server).

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.

------
extension
_\- scaling into friend-of-friend territory will cause email traffic to grow
very quickly and needs limits (namely comment visibility has to stay in the
friend circle of the original message)

\- messages are pushed instead of pulled, which is a waste because not every
status update from every friend will be read._

A rapid scan of the site did not reveal any solutions to these problems, which
are indeed huge problems. Ashton Kutcher can't send ten million emails a day.
Social needs to be built on a pull protocol.

~~~
bitdrift
Actually, push and pull in the case aren't all that different. Using a
reflector address, the system could send a single message to each server.

Ideally each server has more than one user and if a distributed system looks
anything like our current email infrastructure, there are would only be a
handful of large service providers, each with millions of users.

Of course, there might be thousands of followers also using smaller providers,
but sending a few thousand emails is not a big deal (and not that much
different from a few thousand providers pulling from a central hub).

~~~
extension
Presumably the value of building on existing not-particularly-well-loved
protocols would be that only a small part of the stack needs to be extended.
If you have to extend mail servers to support discoverable multicast
endpoints, at that point you might as well just make a new protocol from
scratch.

Another big problem with push, besides the overhead, is that everything is
transient. If you aren't subscribed to a source when it sends something out,
you will never see that thing, even if you subscribe later. That might
possibly be acceptable for status updates, but definitely not for blog posts,
photos, and other permanent content.

Of course, there are various request or sync schemes that could address this
problem but anything like that would push this whole idea into Rube Goldberg
territory as far as I'm concerned.

~~~
hypest
> _you might as well just make a new protocol from scratch_

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...

------
moe
This, at a glance, looks to be conceptually head and shoulders above diaspora.
Even despite the imap-abuse, which I don't think is a good idea here.

However, unlike diaspora he's at least tackling the problem from the right
angle (protocols).

But regardless of system design, the more interesting question remains: Who is
going to fund the implementation of such a system?

