

The API is Dead. Long Live the Protocol. - imaginator
http://buddycloud.com/cms/content/api-dead-long-live-protocol-aka-avoid-being-screwed-closed-social-networks

======
bergie
One thing that I want from protocols is several reference implementations. And
some of those libraries instead of full applications.

But indeed, XMPP (like BuddyCloud here uses) sounds like a good idea for a
social aggregation protocol.

------
shantanubala
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?

~~~
imaginator
(I'm the author of the post)

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.

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

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

------
x5315
'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?

------
api
"X is dead" is a sure-fire indicator of vapidity.

~~~
msie
Now I'd like to see a response from 'protocol'!

