IMAPSN: a spec for building social networking clients using SMTP and IMAP.(imapsn.github.com)
imapsn.github.com
IMAPSN: a spec for building social networking clients using SMTP and IMAP.
http://imapsn.github.com/2010/imapsn-client.html
13 comments
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.
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.
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.
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.
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.
- 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.
- 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.
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).
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).
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.
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.
> 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...
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...
Actually, I think Ashton Kutcher can buy a server to deliver 10M emails per day. The idea that somebody else should pay to deliver your marketing is the anomaly; distributed protocols just return to the old status quo.
The Aston Kutcher use-case is more appropriate for twitter.
IMAPSN relationships are reciprocal and the target use cases involve actual friends. To avoid backlogs of status updates the relationship has statuses of asleep, neglected, and active which can affect the list of message recipients.
Friend of friend is addressed by a few constraints on comments.
So far, every successful social network has initially underestimated the ultimate scope of its use.
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?
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?
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?