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?
I totally get where you are coming from. Of course protocols don't move fast. And sometimes we as implementors have to deal with people whose sole goal in life is upholding the sanctity of a protocol to the detriment of it's users.
The real point that I was trying to get across is that when you build your house on somebody else's API you have no guarantee. With a protocol, that company can go away and others will fill it's place.
In designing an open social network, buddycloud (the company) should be able to go bust, have our servers fail, be raided by the police... whatever. buddycloud (the open social network) and anyone who uses the protocol for their servers or clients can just keep on doing social-network-things.
What a preposterous notion! You mean I can send messages to another person on the internet that doesn't use the same service as me? Without requiring billions in ad revenue to pay for one central hub that monitors and controls it all?
Seriously, give me an example of ONE company that's made money off such a crazy scheme. It sounds communist or something. Now if you'll excuse me I'm running out of CompuServe minutes.
Let me put it this way: after the massive MySpace exodus a while back, it was clear that people don't mind switching services as long as a large portion of their friends switch as well. I admire what you guys are doing a lot, but I'd love to see some way for buddycloud to evolve over time without causing version conflicts in the different clients and servers who may be running different versions. I guess my main point is that a single point of failure is also a single point of success since there are much fewer moving parts.
Most API-related problems are business related, not technical. Twitter could decide to use a protocol but that does little to prevent it from pulling or limiting access via the protocol when it wants and as it wants.
I think a good example is this: Google Talk may use the Jabber protocol, but most users don't care or know. The protocol itself isn't what matters -- Google's market proliferation matters more than the protocol. Similarly, even if Twitter or another company used open protocols, the alternatives would have to provide a better service on top of the open protocol to actually convert people or make the protocol a useful component of the service itself.
'Last week Twitter told 3rd party client developers to essentially fuck-off.'
Twitter's subtext being 'we don’t want your clients using our API and diluting our ability to advertise'.
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.
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.
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?
But indeed, XMPP (like BuddyCloud here uses) sounds like a good idea for a social aggregation protocol.