December 2009 - Page 2 of 6 - Stay N Alive

Month: December 2009

Developers, It’s Time to Open Up Twitter’s API

Posted on by jessestay

TwitterIf you’ve read my previous post on this, you’ll notice how I re-worded the title of this article.  That’s because I’m delusional to think Twitter is going to open source their API any time soon – I’ve been requesting this for over a year now.  I think I’ve come to a new understanding that if we’re to see an open standard built around Twitter’s API, it’s going to be we, the developers, who implement this.

It won’t be Twitter.

I mentioned earlier that developers are starting to catch onto this idea.  It all started almost 2 years ago when Laconi.ca introduced their own Twitter-compatible API into their platform allowing any client library based on the Twitter platform to very simply add Laconi.ca instances to their preferred Twitter client.  Unfortunately it took 2 years for that idea to catch on.  Finally, we’re seeing some big players in this, and my predictions are coming true.  Automattic just released their own Twitter-like API into WordPress.com.  Tumblr just released their own Twitter-like API.  The problem here is that all these developers are re-inventing the wheel every time they re-produce Twitter’s API, and any time Twitter releases a new feature they are stuck re-configuring and re-coding their server code to stay up with Twitter’s new API features.  That’s fine though – this is all a step in the right direction.

The Vision

Imagine now if there were a standard that, at first duplicated what Twitter was producing on their end, but other developers could code off of.  Open Source software could be built around this standard, and now any provider would be able to easily install code that integrated well with their own environments very easily.  We’d see many more providers than just WordPress and Tumblr and Laconi.ca instances like TodaysMama Connect (of which I am an advisor) integrate this.  We’d see big brands and big companies start to implement this.

Soon Twitter will be in the minority amongst services these “Twitter clients” (like TweetDeck, Tweetie, or Seesmic) support.  The Twitter clients will no longer feel obligated to cater to just Twitter, and new layers, such as real time and meta APIs could be added to this API standard in a way that benefits the community, not a single company.  Twitter would no longer have a choke-hold on this and we would have a new, distributed architecture that any developer can implement.

The Proposal

What I’m proposing is that we work together to build an open source set of libraries and services, perhaps a gateway of some sort, all built on a standard that we set (it will most likely copy Twitter’s API at the start).  I’ve built a Google Group, called “OpenTwitter” for now, with the purpose of opening up Twitter’s APIs.  The group will have a primary focus of determining how we want to build this software, establishing documentation for such software, and attaching a completely open standard on top of all that we can modify as it makes sense.  The goal here is that the public will now control how this data gets distributed, not a single company.

But What About RSS?

The question always comes up, why not just push these clients to support RSS and rssCloud or Pubsub Hubbub?  The answer is that we’ve been trying this for too long.  It may still happen, but it’s going to take Twitter clients a lot longer to modify their code to support RSS than an open Twitter-compatible standard.  Ideally, a Twitter client, which there are many, ought to be able to quickly and easily just change the base domain of where calls are sent, and everything with the providing service should “just work”.  RSS complicates this too much.  The fact is that Twitter has taken over and we need to accept that as a fact and work with it.

The Invitation

If you can, I’d like to invite you to join our “OpenTwitter” list on Google.  Let’s get some conversations going, and get this thing off the ground.  My hope is that we can get people like Dave Winer, Matt Mullenweg, Chris Messina, David Recordon, Joseph Smarr, DeWitt Clinton, and Mike Taylor all joining this effort.  My goal is that we can even get Twitter involved in this effort – this isn’t meant to snub Twitter by all means.  The entire goal here is to build a much more open, distributed web in as simple a manner as possible.

You can join the “OpenTwitter” list here.  I’ll be posting a kickoff message there very soon.

Announcing the Winners of the Static FBML Contest

Posted on by jessestay

FacebookOver on Tamar Weinberg’s blog, Techipedia, I wrote an article about how to customize your FBML Page utilizing the Static FBML app on Facebook, along with a few other techniques.  As part of the post we announced a contest.  The 2 best Facebook Pages left in the comments to integrate FBML into a tab using the Static FBML app would win.  I’m proud to announce the winners.  The winners are:

  • HyperArts Web Design – these guys did some interesting stuff with Javascript to enable loading of the different tabs without an entire refresh of the page.  One of the tabs even had a web form on it enabling you to contact them.  The overall experience, use of multiple types of HTML elements, and more, provided a full package that I thought deserved to be one of the winners.

  • Express – this is a very simple one, but very elegantly designed, and they have a very friendly welcome page on their “What’s New” tab.  I like their use of HTML, and well-designed layout.  I also really like that they used bit.ly links to enable tracking of clicks on the Page.  They link to their other outlets such as Twitter and Youtube as well.

I was very impressed with all the designs and the effort put into them.  Consistently, there are a few things that everyone, including the winners, could have done better though:  I would have loved to see you utilize FBML a bit more.  Perhaps you could utilize the tag to implement tabs to look like Facebook’s.  Or I would have loved to see and video – I don’t think any of the entrants had that.  Maybe you could use to produce a form in a pretty, Facebook-like format.  Perhaps a nicely formatted image of the owners using and could personalize it a bit.  Be sure to get to know as well so you can add comments to your tabs if you want to facilitate discussion.

Overall I’m happy to see what came out of the contest.  My hope is that you can continue this and push your Pages even further.  Get to know what you can do with FBML.  Learn what’s possible, and show me what you’ve done!

For the winners, either Tamar or I should be contacting you, but you can also shoot me an e-mail at jesse@staynalive.com and I’ll arrange to get you a copy of FBML Essentials.

If you would like help customizing your Facebook Page please don’t hesitate to contact me and arrange a consultation.  Congrats to the winners!

Just in Time for the Holidays, FriendFeed Becomes First OAuth Wrap Provider

Posted on by jessestay

presentAbout a month ago, Facebook’s David Recordon announced that Facebook was hard at work with the Open Standards Communities on a new OAuth protocol called Wrap.  The goals of the protocol seem to specifically provide a way to direct a user through the authentication process through a client-only model, removing the need for developers to do heavy server-side code to authenticate the user.  Such a model fits well for Facebook, who, through Facebook Connect, has fought to make it as easy as possible to enable developers to authenticate users via simple Javascript and HTML.  It seems Facebook is making through with its promises, by launching FriendFeed as the first OAuth Wrap provider to launch with the new protocol.

The launch comes as a test of a discussion that took place at an OAuth Wrap Community meeting at Facebook headquarters last Tuesday, where it was discussed how to enable client-only authorization of users.  In response, Bret Taylor and the FriendFeed team (I guess, according to Luke Shepard, that means there’s still a team?) produced a working prototype of the model, enabling it on their own site.  Benjamin Golub, who was responsible for FriendFeed’s API before it was acquired by Facebook, confirmed this with the comment, “FriendFeed supports OAuth WRAP now :). Great job Bret, Luke, and David!” on FriendFeed.

Screen shot 2009-12-17 at 7.58.51 PM

It’s still unclear if this API is available to developers yet, or if it was only a proof-of-concept, but it is clear FriendFeed is very likely becoming a playground for the Facebook team to try out new technologies.  This is promising in that if this continues, FriendFeed should continue to see cool new technologies applied to it way before, and even if, they even the light of day on Facebook.com.

I’m very excited to see the Facebook team pushing these new open, client-side APIs, but even more excited to see the FriendFeed team still cranking out cool new technologies, making this the second one today for the site.  It’s becoming apparent that the FriendFeed team is finally becoming accustomed to Facebook’s internal technologies and architecture, and my hope is that we will soon to see many “beautiful butterflies” come out of what they’ve been working on over the last few months.

Now, if anyone knows how we can try this thing out I’m all ears!

UPDATE: Benjamin Golub has granted my wishes!  He says in the comments: “You can try it out yourself! Register an application at http://friendfeed.com/api/register and then follow along with http://github.com/finiteloop/friendfeed-wrap-example/blob/master/friendfeedwrap.py” – hmmm…new SocialToo feature?

Twitter, It’s Time to Open Source Your API

Posted on by jessestay

twitter.pngWith the recent launch of a “Twitter API” by both Automattic (WordPress.com) and Tumblr, it is evident that developers have a need to implement similar APIs, on similar platforms, reducing the effort to retrieve data from multiple platforms in a single client.  With Tweetie, for instance, you can simply change a single URL to “WordPress.com” or “Tumblr.com” or “Identi.ca” and immediately be receiving updates from your friends on those services, and even post back to those services.  I argue this approach is very closed though, as for each and every implementation of a “Twitter API” (which ironically has nothing to do with Twitter), the developers need to completely re-invent the wheel and copy what Twitter has done based on documentation of Twitter’s own API to access its data.  Readwriteweb even went to the extent of calling this approach “open”.  There’s nothing open about it.  Each developer implementing their own “Twitter API” (and especially calling it such) is blatantly ripping off Twitter’s API to do so under no license whatsoever and Twitter’s just standing back and watching.  I think it’s time Twitter releases their API under an Open Source license to relieve this mess and protect their IP.

Open Sourcing APIs is nothing new.  Of course, Google, with OpenSocial, did it and even standardized their own API for “containers” to easily implement the same API across multiple sites.  All the code was provided for developers to do this and we quickly saw sites such as MySpace, Hi5, Orkut, and others all implement the same standard, reducing the code needed to port an app from platform to platform.

Facebook did the same with their platform.  A little known fact is that any developer can go to http://developers.facebook.com/opensource.php and download the Facebook Open Platform, along with many other very useful open source tools.  Immediately they have access to enable FBML, FBJS, and other aspects of the Facebook API to developers on their own sites, standardizing the Facebook platform amongst sites that implement it.  Bebo was one of those who took up Facebook on this offer.  Others can too.

What we need now is a standardized platform for sharing micro-content.  Some have proposed RSS do this, which is fine with me, but since developers already have apps built on Twitter which this would go with it makes sense to also enable a standardized platform for developers to code on for these types of apps.  Such an open-sourced code-base would enable developers to not have to change their code to enable access to similar sites beyond just Twitter.  Twitter right now is a closed platform, plain and simple.  With the exception of OAuth, they are based on a proprietary API, do not support open content protocols, and even their real-time stream is proprietary.

A good step for Twitter would be to open source this API.  Enable sites such as WordPress, Tumblr, Status.net, and others to easily integrate it into their own platformse without the need to re-invent the wheel.  Put it under an open license, and then your IP remains protected.  Until that point  developers are going to continue ripping off Twitter’s API, and Twitter’s IP slowly starts to go down the drain.  I’d love to see Twitter take a lead in this process – it took Facebook just about 6 months to open source their API.  Why haven’t we seen this yet from Twitter?

Or are they the next Compuserve?

FriendFeed Launches Status Update Sync to Auto-update Facebook

Posted on by jessestay

friendfeed-logo.jpgDespite all the “FriendFeed is dead” arguments the naysayers have been pushing, a new, pretty significant update was pushed by the FriendFeed team today into production.  The update belongs to FriendFeed’s App on Facebook, and now imports every update users post on status update services they import into FriendFeed as status updates on Facebook.  This means if you are importing your Twitter feed onto FriendFeed, and have installed the FriendFeed app on Facebook, all your Twitter updates will now automatically import as status updates onto Facebook.  Not only that, but it supports Google Chat status updates, Plurk updates, Identi.ca updates, and potentially any status update service supported by FriendFeed.

This move goes head-to-head with services like Twitter’s own Facebook app, which, as one of the very first Facebook Platform apps, automatically posts Twitter updates to users’ profiles.  The idea also, to me, suggests that the FriendFeed team will be releasing more updates around this in the future.  For instance, it now makes sense that FriendFeed begins to enable preferences around which services auto-populate into Facebook, and perhaps even a “post to Facebook” checkbox next to the already-existing “post to Twitter” checkbox when you post an update on the service.  FriendFeed also, very soon, needs to integrate Facebook Connect so that their Facebook integration (which is bound to happen) is much tighter and works better with the Facebook environment.  This is based on a Facebook app, which in my best guesses the FriendFeed team should be integrating into their existing FriendFeed app on Facebook – it’s inevitable at this point.  When this happens it makes sense to add even more updates to their Facebook integration, further growing the service.

The skeptics have all been pushing that FriendFeed won’t grow because the FriendFeed team is no longer working on the product.  I think this pretty much debunks that theory, even suggesting more updates are to come.  As I said before, FriendFeed’s just fine – it won’t be going away any time soon, and I think this proves my point even further.