2009-07-21
Twitter, @replies and in_reply_to
benw:
Existing conversation trackers don’t work with this. The
@@replies get left out of threading tools. That’s a shame, but that’s the reality of new behaviour. It takes time to be recognised and supported. That as much as anything is why I’ve documented@@here, as a reference and explanation for you to use as you advocate the practice, and to encourage everyone to settle on the@@syntax in preference to the many that currently circulate.
There’s a reason that conversation trackers don’t get @@replies, but it’s quite longwinded to explain. However, since Ben has a fairly longwinded explanatory section to his post, and because I’ve wanted to get this down anyway, what the hell; let’s go with it.
Once upon a time Ev invented Twitter. And people saw it was good, and started using it, and as Ben says, came up with what became formalised as a way of replying to a named user: @replies. (I’d love to know where that convention started, by the way. Presumably some web forums, but which, and when? Not that anyone is likely to care enough to dig through terabytes of text to establish it. Anyway.)
And Twitter saw that their users were doing this, and that it might be useful to make it clever, so they started marking up @user with links to twitter.com/user. Furthermore, they came up with a heuristic: if a post started @user (or, in Perlish,
if $post =~ m/^\@user/
except Twitter’s front end is in Ruby, but it’d be similar) then you’d assume that the person was replying to user’s latest post.
All well and good, except… when it wasn’t true. So, some time last year (again, I don’t care to trawl; someone else might) Twitter added the “swoosh” link to the web interface. Clicking this didn’t just populate the post field with @user at the front: it set a bit of metadata saying “this post I want to create is an reply to this exact post ID here”. Technically, and unsurprisingly, this is the in_reply_to field.
There’s rules attached to this, both from the front end and from third-party clients via the API, though. For the in_reply_to argument to be honoured, the post must start with the @user the in_reply_to post is by. In fact, it has to match the regular expression above. Add a space? Add the letters “RT” or the recycle symbol? No in_reply_to metadata for you, buddy.
It also means that if you come to see a post that you want to reply to and just put @user without using the swoosh, or your client has a brainfart and drops the in_reply_to argument, your post also lacks the in_reply_to metadata. The upshot? Anyone coming along more than, say, a day later to your post has no idea which of @user’s posts you’re actually responding to. If you’re lucky it’ll be clear. If not, well, tough. “This was the previous behavior and was changed because of user complaints over false positives.” WONTFIX.
So, what have we learnt?
- in_reply_to is a relatively late change to Twitter
- in_reply_to is only available if you start your post @user
- in_reply_to is reliant on the user and client explicitly responding to a post
- in_reply_to is absent for retweets, @@replies, and the like
- in_reply_to is implemented as is because Twitter believe false negatives are better than false positives
