Over a few months we've noticed that, as many others probably have, a fair amount of conversation about our tweets takes place in the blogosphere, outside of the Twitterverse. One of our goals for the upcoming Christmas break is to look at integrating conversation aggregation, tweet wise, into our web site, so that our site shows not only our postings, but the conversation taking place around those postings.
While some would say there's a need for Twitter to communicate with blogs when they're mentioned on Twitter, I suppose we're selfishly focused on the other side of this conversation, the one about tweets. We'd like to see a few API developments and changes to this end. 1.) We realize this comes up somewhat frequently, but while the statuses/show method indicates whether a tweet is in reply to another tweet, this is less than desirable for conversation aggregation as we're looking at it. When a tweet is posted with an in_reply_to attribute, we think it'd be nice to either see the original status also given an element to indicate each post in_reply to it, or given a new API call which shows this information (statuses/conversation perhaps?) which could function much like statuses/retweets. In conjunction with in_reply_to, this information, while it serves some selfish purposes of our own, could allow for some powerful threaded discussion aps. Threaded discussion applications (while a few exist, from what we could tell even the best left something to desire, but perhaps we missed some) for Twitter could revolutionize the already-usefulness of the tool, as a tweeter who sees and responds to a small branch of the discussion on the web would currently have a lot of footwork to do to uncover the larger discussion, if there was one, and would be limited primarily to following the upstream to a source due the the complications of ferreting out each branch of the discussion. The meta discourse could come alive. In the short term we'll probably use the twittoaster API to achieve this functionality, but we imagine they're making a lot of search calls and probably using more resources than necessary for something that should be pretty simple on Twitter's end. 2.) It'd be nice to see an API call which, similarly, allows each tweet to store the URLs of any pages which link to it, and report their links through the API call. I think this functionality in high enough demand that plugins for most blog packages would show up fairly quickly that parse any status links and report the linking URL through the API to Twitter. The big problems seem to be: - pages linked successfully but then disappearing - sites spamming the API Both of these could be mitigated by continually checking the pages to see that a link is maintained, but that'd be a huge hit on the servers. So, some alternatives with pros and cons: - Just like spam, crowdsource it. If a site posts links you don't like to your tweets, mark it as spam and all comments from the root folder or subdomain are blocked from connecting your tweets, enough reports and the site may be blocked from commenting on anyone. - Require login credentials to post. This would make the feature less useful because it might deter some well-meaning participants, but it'd also require a spammer to jump through more hoops and would be easier to source their talk-backs to the account and already established spam/ account control methods. - Let a third party, like backtype.com, have partnership-level access with the data, which would help them immensely with what they do, in exchange for providing some of the maintenance work (checking for dead links, links that no longer link to the tweet, possibly spam-detection algorithms).
