3 ms·

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 hav

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 16y ago
> 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...