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

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.

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

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.