IMAPSN: a spec for building social networking clients using SMTP and IMAP. • Hacker News Board

Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.

#11

Post by srccode » Wed, Nov 24, 2010, 11:40 PM UTC

sfard wrote: post #6

lzimm wrote: post #4

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…

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.

Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.

#12

Post by extension » Thu, Nov 25, 2010, 6:46 AM UTC

bitdrift wrote: post #9

extension wrote: post #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. 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…

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.

Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.

#13

Post by extension » Thu, Nov 25, 2010, 6:52 AM UTC

jkantz wrote: post #10

extension wrote: post #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. 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.

So far, every successful social network has initially underestimated the ultimate scope of its use.

Re: IMAPSN: a spec for building social networking clients using SMTP and IMAP.

#14

Post by hypest » Thu, Nov 25, 2010, 8:38 AM UTC

extension wrote: post #12

bitdrift wrote: post #9

Earlier quoted context omitted.

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…

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 sou…

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