One thing that I want from protocols is several reference implementations. And some of those libraries instead of full applications.<p>But indeed, XMPP (like BuddyCloud here uses) sounds like a good idea for a social aggregation protocol.
I'm not sure. Sometimes, protocols just simply do not evolve fast enough to support really innovative user behavior. For example, IMAP is a great email protocol, but GMail demonstrated a very long time ago that labels are a lot more powerful than folders (especially when you have a wide array of filters to choose from). An API that relies only on a single party (i.e. a company) makes it easier to evolve and provide better functionality while protocols are much more stagnant. Who knows what we'll expect of "social" protocols in 5-10 years? And a better question to ask may be: what's easier to upgrade to with mass adoption -- a new version of an API, or a new protocol?
'Last week Twitter told 3rd party client developers to essentially fuck-off.'<p>Twitter's subtext being 'we don’t want your clients using our API and diluting our ability to advertise'.<p>While neither of these statements are true, the concept of offering a protocol instead of an API is an interesting one. Though, the quote "open protocols are basically a gentleman's agreement" does indicate a similar issue to the one that's being projected onto Twitter.<p>As shantanubala says, upgrading a protocol with mass adoption could be very difficult, this can then cause issues when you want to offer new services, or deprecate certain calls as they may be too complex at scale.<p>Coordination definitely seems to be a huge issue when dealing with these open social networks. If a security issue is found in a server which can leak information, how long would it take for every server to be patched? I think a good example for this is to ask how many WordPress blogs get hacked because they're running on old copies of the code?