Expanding on “twitter with a brain”

Chuck Shotton recently made a compelling case (“Twitter with a Brain“) for Twitter tools to allow the user to change the protocol endpoint. That is, instead of always going to twitter.com, you can tell your Twitter client to send all requests to myTweetInterceptor.me.com. Why would you do this? You should read his blog entry, but in short his point is that the intermediary can add all kinds of new features that neither the Twitter client nor Twitter itself support. As always in computer science, a new level of decoupling adds opportunities for extensions (and breakage too, of course).

I fully agree with what he writes and I would very much like to see his call to action answered. In fact, I want more than what he is asking for. So here is my call to action:

1) It’s not just Twitter

Why just Twitter? This should be true for any client using any protocol. Why not also the APIs for the various Google and Yahoo services? The APIs for the other social networks beyond Twitter? For shopping sites like Amazon and EBay? Etc. And of course to all the various Cloud providers out there. Just because I am using the Amazon EC2 API it doesn’t mean I necessarily want the requests to go straight to Amazon. Client tools should always make the endpoint configurable, period.

2) It’s not just the clients, it’s also (and especially) the third party sites

Chuck’s examples are about features that the Twitter clients could provide but don’t, so an intermediary would be an easy way to hack support for them (others presumably include modifying the client – if open source -, writing a plug-in for it – it there is such mechanism -, or running a network interceptor on the local client – unless the protocol is encrypted-).

That’s nice and I’d love to see this, but the big deal for me is less with clients and more with third party sites. You know, all these sites that ask for your Twitter login/password. Or those that ask for your GMail/Yahoo account info to retrieve a list of your contacts. I never grant these requests, but I would consider it if they allowed me to tell them what endpoint URL to use. For example, rather than using my Twitter login to go straight to twitter.com, they would use a login/password that I create and talk to twitterIntermediary.vambenepe.com. The requests would be in the exact same shape as what they send today to Twitter, just directed to another URL. There, I could have a proxy that only allows some requests (e.g. “update twitter background image” but not “send update”) and forwards them using my real Twitter credentials. Or, for email accounts, I could have a proxy that allows requests that read my address book but not those that read my mails. The goal here is not to add features, it is to delegate trust in a fine-grained (and audited) manner. This, to me, is the burning need, rather than a 3rd place to implement Twitter lists.

I would probably write these proxies using a PaaS platform like the Google App Engine. Or maybe even Yahoo Pipes. I have long struggled to think of use cases for which Yahoo Pipes hits the sweetspot, and this may well be it. Especially if people write modules to handle specific APIs (e.g. a “Twitter API” module that shows all operations and lets you enable/disable them one by one in a pipe). The one thing missing would be a way for a pipe to keep a log of its invocations, for auditing.

You want access to my email and social network accounts? Give me the ability to filter you requests and you’ll get access. If it’s blind trust you want, I am afraid I have a very limited supply.

[Note: I wanted to add this as a comment on Chuck’s blog, but he doesn’t seem to allow them: “go start your own blog and/or shut up and eat your vegetables” is his recommendation. Since I already have my own blog, I guess I don’t have to eat my vegetables if I don’t want to. I just hope my kids don’t learn about this rule or they’ll be blogging in no time.]

[UPDATED 2009/11/30: WRT to Chuck’s request, it looks like it’s being done already. But no luck with the third party sites so far, which is what I most want to see.]


Filed under Automation, Everything, Google App Engine, Implementation, Mashup, PaaS, Portability, Protocols, Security, Social networks, Twitter, Yahoo

6 Responses to Expanding on “twitter with a brain”

  1. I think the idea of using Google App Engine (or the equivalent — a Tomcat server somewhere) is a perfect fit for implementing quick and easy-to-deploy proxy “modules”. It should even be possible to stack several of them (a la Pipes) to get desired mix/match functionality for your Twitter proxy.

    I’ve got lots of the necessary code already implemented in my GAE version of a rssCloud server. It would make an interesting collaborative project to turn it into an open Twitter API platform and see what happens.

    (Interestingly, it’s only a small step from proxy to basic Twitter server…)

  2. Daniel

    While I think the idea has significant merit, it removes contact with Twitterees from the head Twitterer, Twitter itself, and therefore has the potential to limit their advertising business model as the system works now. If Twitter re-factors their system so that they can monitor and and measure activity through proxies that don’t directly go to their endpoint, then they can preserve their potential to monetize their user base which is, after all, what most internet business models are about in some form or another. As it stands now, Twitter gains nothing and loses a lot with proxies.

  3. Daniel: proxies may or may not be good for Twitter itself, but there is (almost) no way for them to stop them. It’s in the hands of people writing apps that call the Twitter API. It’s their choice whether to hard-core the Twitter endpoint URL or not.

    As to whether or not such proxies would be good or bad for Twitter, it’s not obvious in my mind. You could also say that all the Twitter clients are bad for Twitter too because they take eyeballs away from twitter.com where they could be fed advertising. But what would Twitter be today w/o them.

  4. Pingback: William Vambenepe — Taxonomy of Cloud Computing Benefits

  5. Pingback: William Vambenepe — Don’t tell Facebook what you like, tell Twitter

  6. Pingback: William Vambenepe — Integration patterns for social data: the Open Social Data Bus