Dave Winer made this post on his rssCloud Blog today and it started the gears grinding. In it, he suggests the need for a “programmable” Twitter client. Specifically, he offered up the idea of a Twitter client with a scripting engine in it that would allow certain types of logic to be triggered on behalf of the Twitter user without having to involve Twitter or a reprogrammed client.
The example he used was wanting to un-follow a particular user for a day, then re-follow them automatically. It’s certainly possible to build this sort of functionality into an existing Twitter client, but I’d like to suggest something easier than herding all of the Twitter client authors in this direction. Specifically, rather than having the scripting support built into a Twitter client, why not just ask Twitter client authors to allow their clients to be pointed at alternate hosts that implement the Twitter APIs besides Twitter’s own servers?
This would allow us to implement Twitter “proxies”, so that even the most basic of Twitter clients could take advantage of all sorts of extra features and functionality that might get wrapped around those APIs. Using Dave’s example, here’s how it might work:
User configures their copy of UberTweet (a fictitious Twitter client) to use APIs at www.spiffyubertweet.com. Now when they use their client, all of the calls will pass through the Twitter proxy at www.spiffyubertweet.com, where all sorts of magic can happen. In the simplest implementation, the proxy just passes all calls to Twitter and all responses back to the calling client with no mods or changes. The fun comes when the proxy starts paying attention to the content of the tweets.
Suppose that the user wants to un-follow “pottymouth” for 24 hours. Why not send a tweet like:
<unfollow pottymouth for 24 hours>
The proxy would catch that tweet, parse out the syntax inside the <>, and issue the necessary API calls to unfollow pottymouth. Then it would queue up a task for 24 hours later to re-follow pottymouth for the requesting user.
Twitter never sees the tweet. The client author had to make an utterly trivial modification to their client, and the user can suddenly reap the benefits of whatever services the proxy author chooses to insert into the pipeline. Proxies could allow all sorts of external meta data to be associated with a tweet, for example. Or you could envision Twitter proxies that performed all sorts of analysis on tweets and followers and return reports to users. The opportunities are endless and it requires virtually no work on either end of the existing Twitter ecosystem beyond allowing expert users to specify a Twitter API proxy in their Twitter client’s preferences.
There are several client-side scripting engines that support acting as both a client and a server and they are fully capable of implementing the Twitter APIs, even if most are only pass-through calls. The only thing holding this up is finding a popular Twitter client author that is interested in adding this tiny modification to their code. Any takers?
