We need: A programmable Twitter client
Unix had a shell language. DOS had a batch language. Lotus 1-2-3 had its macro language. Emacs is a programming tool as much as it is a text editor. We have gotten out of the habit of making programmable end-user products, but they are still just as important today as they were a couple of decades ago.
Every few weeks Scoble and I have an hour-plus conversation about what’s on each of our minds. The last few years it’s been all about Twitter of course, just like everyone else (or so it seems).
Lately our conversations have been ending up in the same dead-end.
Seems all good ideas begin and end with a phrase like: Of course they’ll never do it.
The “they” in the conversation is Twitter Corp, of course.
But we kept talking, and Scoble re-stated an idea that he’s been promoting publicly called SuperTweets, which was more or less exactly the idea for RSS enclosures, which led to podcasting. I didn’t need to pitch anyone to make that one happen, so those were happier times.
In our dead-end brainstorming I think we’ve been making an incorrect assumption, that all would be good if Twitter would just become an extensible metadata platform, allowing any developer to latch any data they wanted on any tweet, with Twitter storing at least a pointer to the data with the tweet, if not the actual data.
Now I think this was incorrect, because it assumed there would be client developers who are creative or brave enough to work with one another without waiting for Twitter to tell them where to go. I actually think the developer space around Twitter has been so scared of Twitter Corp for so long that even if they knew exactly how to turn the market upside-down they’d never risk pissing off the mother ship. So I think there’s virtually zero percent chance of any disruptive stuff coming from the developers. And without disruption, TwitterSpace will remain moribund and stuck.
Unless…
Of course you’ve read the title of this post so you know what I’m going to say. :-)
What if there were a relatively simple and low-power programming language built into a Twitter client that allowed power users to build their own little apps on top of Twitter. User interfaces for grouping tweets, or flowing groups of ideas to two places, Twitter and somewhere else. So that the bits that end up on Twitter are coherent and useful to people who don’t use the client, but somehow more useful to those who do.
And on the reading side, I want to add features that not everyone will want, but perhaps more people than just myself. And I don’t want to have write a whole client just to have those features.
For example, it’s been about two years since I first asked for an “unfollow-with-timeout.”
Use-case: Someone is live-tweeting a conference I don’t care about and hogging up all my bandwidth. I want to unfollow them for just a day. Now I don’t think the client guys are going to implement this anytime soon, but it’s the kind of feature a few hundred people would kill for.
I’d also like a “block-with-timeout” feature.
Shouldn’t have to block someone to remove a single tweet from view. Can’t tell you how many times I’ve blocked people just to get a turd they sent to me out of my @replies tab.
So I suspect the answer to Scoble’s void is we need a programmable Twitter client.
PS: I’m sure some or most of the comments will be from people who say they don’t need one. Okay maybe they can skip the comment because I know that most people don’t want this, at least until someone ships a script that they can’t live without. :-)
