Posted by & filed under Tech.

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?

  • http://hans.gerwitz.com/ hans

    Maybe they’re not an infrastructure play, but an identity play. If they continue to gain traction via the @username namespace, they could stay “sticky” even if the actual messages were going through federated (but Twitter-authed) proxies.

  • Mcburton

    Why not create a bot that follows your timeline looking for commands, when it sees one it executes the logic (defined in some dsl) and then deletes the tweet with the command. Its quick, dirty, but could work.

  • http://www.shotton.com/ cshotton

    @Daniel Maybe you misunderstand how proxies work. They look like a normal API client to Twitter. And they look like Twitter to a normal API client. So neither end should see any difference from a technical or business perspective.

    But at the end of the day, I am relatively unconcerned about making money for Twitter. That is their challenge, not mine. They picked a business that is ultimately a commodity infrastructure play. That didn’t work out so well for proprietary email vendors, commercial web server products, or any number of other tools and technologies that form the underpinnings of the modern Internet. Twitter’s role in all of this will probably end up being the first implementation of what becomes a ubiquitous one-to-many messaging infrastructure. If slapping proxy software on top of their platform makes that happen faster, so be it. Users want applications, not server farms and message databases.

  • http://www.shotton.com/ cshotton

    @Ferg That’s the whole point of putting a proxy in the middle. If Twitter is too uncreative to add the features, and the client authors are too hobbled by the constraints Twitter places on them, why not enhance the service and functionality of both from the middle out?

  • Daniel

    @cshotten: “Twitter is still free to monetize its large user base as it sees fit”. Not if proxies prevent Twitter from ever seeing their users activities. The days of non-targeted adevertising are drawing to a close–Twitter needs demographic, affinity, and habit information on their users to monetize them–if proxies fog that up, Twitter’s value goes down–the more fog the lower their value. They could modify the APIs so that Twitter can allow proxies and still collect the information the need. Google has figured it out. However, as you pointed out, they should have anticipated needing that information and done this all earlier. In stead they are clinging to the direct traffic stream and, again as you pointed out, they are saturated. I thought they had biggere ideas than that simple model.

  • Ferg

    @cshotton (#10), in regards to the API: aren’t things like Twitter clients already keeping “something better from coming along”?

  • http://www.shotton.com/ cshotton

    @Daniel I think the business case for proxies has nothing to do with making money for Twitter. Twitter is trying to monetize an infrastructure platform and it will ultimately run out of steam the same way that companies who tried to monetize the HTTP infrastructure ultimately failed in the face of Apache, etc.

    Without technical barriers to entry, the only thing they have in their favor is first mover advantage. By wrapping value-add around their infrastructure, an entire for-pay economy can spring up around Twitter. Twitter is still free to monetize its large user base as it sees fit, but the cat is already out of the bag once they published Web APIs and allowed 3rd party apps to build on them.

    If I had to guess, proxies and smart clients become the way for a real ecosystem to spring up and make Twitter-like services into a platform that has apps just as rich as those that sprang up on the transaction oriented HTTP network.

  • Daniel

    The proxy idea will never work for the same reason that you’ll never see a Google proxy–not for technicla reason but for business reasons. That direct connection with the users is the key to monetization. If Twitter were to allow intermediation, they’d lose some control of and access to their user base and suffer diminished ability to monetize it as a result. For a firm struggling to find a business model as it is, that could well be death.

  • Tim Maly

    Can’t believe that Bo one has metioned this yet: Tweetie 2 for iPhone does what you want. You can specify a custom API base for a proxy service.

    So now you just need someone to make the proxy server.

  • Jeremy

    I think the big picture is missing here. The problem is that nowadays everything is done as a centralized, proprietary “web service” owned by one company, whether it’s Twitter or Google or Facebook or whatever. The problem is that Twitter is one of those things, and it will remain stupid as long as it is.

    Remember when stuff was made like email, Usenet, FTP, and yes, HTTP? Whatever happened to that?

    Trying to create some kind of “platform” out of Twitter is a dead-end. It’s proprietary, it’s centralized, it’s nonsense.

  • Nigelito

    How about the twitterbot framework http://code.google.com/p/twitterbots/

  • ohn

    Twitter is just a stupid toy for idiots with too much time and who are too full of themselves to talk about Twitter on.

    Lets be honest… the energy you just invested in this could have been spent much more wisely

  • http://dimwell.net/ Chris Brightwell

    I think that the “unfollow for 24 hours” example is a bit short-sighted. Client-side, time-aware filtering can squelch a single user for a period of time without the need to involve Twitter at all.

    And, really, this is probably a more correct solution. You don’t want to /actually/ unfollow this specific user; you just want them to shut up for a while. Ignoring them is trivial.

  • http://www.shotton.com/ cshotton

    Of course, the tragedy of this is that Twitter’s APIs kinda suck and by re-implementing them with proxies, it’s gonna keep something better from coming along for a while. But it’s a small price to pay to get around some of Twitter’s platform limitations now.

    Better is the enemy of good enough.

  • http://troygilbert.com/ Troy Gilbert

    A potentially bigger selling point of having user-definable Twitter proxies: using a private Twitter backend. So, maybe Yammer creates a Twitter API proxy for their stuff, thus you can use all of your favorite Twitter clients for Yammer… or, any of a number of open source competitors that would pop up.

    Would be great for roll your own intranet Twitter.

  • http://www.velobration.com Rob Sayers

    As long as you aren’t afraid of the console, TTYtter: http://www.floodgap.com/software/ttytter/ is a good match. It has a built-in system for writing extensions in Perl. You can filter, process, add new commands, even use it as a full twitter bot, it’s extremely versatile.

  • Foo

    What’s really weird about Winer’s complaint is that he says that Emacs was programmable, but he can’t find any programmable twitter clients, without bothering to check to see if, um, there might be one for Emacs. As in:

    http://www.emacswiki.org/emacs/TwIt

  • http://mislav.uniqpath.com Mislav
  • http://cmorrell.com Chris

    Same thing that happens if you mess up any of the current Twitter commands…

  • Michael Houghton

    @Oliver, Eric’s point still stands; if you miss off that trailing bracket or >, or accidentally delete the leading character, what should happen to the command?

    If there’s going to be a command syntax, it would be better to ask all those twitter app writers to provide a UI feature for sending a command tweet, to make sure that these things are well-formed.

  • Oliver

    @Eric, you could enforce that only commands surrounded by “{}” are executed, or something similar.

  • Eric Burke

    One problem — if you tweet a command but have some sort of syntax error that makes it unrecognizable, it will pass through and be posted as a tweet for everyone to see your mistake. :-)

  • http://www.shotton.com/ cshotton

    Sorry for forgetting to enable comments. Two very good responses that others might be interested in reading are from William Vambenepe
    http://stage.vambenepe.com/archives/1127

    and Daniel Marks
    http://www.displacedaussie.net/2009/11/my-twitter-proxy/