Highly recommend this post by Marc Canter, it’s filled with ideas. Much the same as my thinking. I have a post planned for tomorrow or Sunday that should blow out some assumptions about identity and federating these micro-blogging services. Low-tech, worse is better, re-use what’s already out there, as Marc says it’s all happening now, and I’m loving the way it’s turning out.
More movement in micro-blogging!
Recall that Gnip is a ping syndicator, sort of weblogs.com on steroids. Not the simplest of APIs, but apparently quite powerful. I tried to get some code running with it, but hit a hard wall that I couldn’t get past. No matter, others are successfully adapting to Gnip.
I just read this announcement on Twitter from Eric Marcoullier pointing to a TechCrunch piece. Eric says: “It’s official: Twitter is pushing to Gnip and Gnip is pushing it the fuck out to everyone!” But this is kind of contradicted in the TC piece, which says you can only get updates from users you specify. You can’t connect up on the same (firehose) basis that Summize was connecting before they were acquired by Twitter (earlier this week).
Like I said: So much movement. (There’s more coming.)
One thing’s for sure is that being open to developers is very much a competitive issue. This is why two-party systems work in technology and one-party systems stagnate. Why, when Netscape dominated browsers nothing moved, and it was fun while Microsoft and Netscape were competing, and why we returned to stagnation when Netscape folded, and why it’s once again interesting now that Firefox is flourishing. Same thing in the competition betw Twitter and identi.ca.
When I talked with Evan Prodromou yesterday he said they would open up their XMPP back-end to anyone and everyone without limits. Now it’s up to them to make good on that, and this shoudl give Twitter the incentive to go all the way with Gnip. BTW, Gnip should be agnostic, they should work with identi.ca as well as with Twitter.
Recall that identi.ca is an open source Twitter-like “micro blogging” service. When it appeared, earlier this month, I wrote: “First thing –> looking for an API.” I wanted to see an implementation of the Twitter API, so that all the code that I had written for Twitter would automatically work with identi.ca.
Being compatible with Twitter is the developer-friendly thing to do, it means we will only have one code base to maintain. It’s good for users, because they have choice, they can use either Twitter or identi.ca, and not have to make a choice on tools. It’s good for identi.ca because they instantly get a base of apps that work with their service. I’d argue that it’s even good for Twitter, because it helps to solidify a standard with them as the market leader. The second guy into a market sets the standard, by ratifying the API designed and deployed by the first to market, who is in this case, obviously, Twitter. Had identi.ca blazed their own trail and made an API that did what Twitter’s did, but was gratuitously incompatible, everyone would have suffered. Too often in the tech business, this is what happens, even though it’s such a disrespectful and non-optimal thing to do.
Yesterday I got an email from Evan Prodromou at identi.ca saying that they had implemented the Twitter API; he asked if I would test my apps against their implementation. I did, and I’m happy to report that I was able to run all my code, unmodified, except for substituting identi.ca/api where ever twitter.com appears in an address. That’s what I call compatible! It all “just worked” (so far, knock wood, I am not a lawyer, Murphy-willing, etc).
So we can check a very important item off identi.ca’s to-do list. Next items: 1. Allow any developer to hook into the full flow of identi.ca through XMPP, and 2. Demonstrate interop across a federation of identi.ca deployments.
See also: The docs for the “Twitter-compatible API.”