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).

Reply via email to