IMAPSN: a spec for building social networking clients using SMTP and IMAP.
1–10 of 14 posts
Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.
#2Interestingly, 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.
Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.
#3This, 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?
Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.
#4I'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?
Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.
#5I 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.
Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.
#6I'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…
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.
Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.
#7- 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.
Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.
#8- 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. Ash…
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.
Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.
#9- 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. Ash…
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).
Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.
#10- 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. Ash…
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.