At @al3x's request, I have decided to start a conversation on this topic here.
At issue is the recent /statuses/replies API change that occurred two days ago. The result of the change causes any "manual replies" to not have an "in reply to" link associated with the tweet, whereby "manual" I mean any tweet reply that does not set the "in_reply_to_status_id" parameter. Before the API change, if a client (including the web interface) did not specifically set the "in_reply_to_status_id" parameter, the tweet would still have an "in reply to" link, but it would simply point to the latest tweet (at that point in time) of the person that the tweet is replying to. After the API change, this is no longer the case. If a user does not specifically click on a reply swoosh in the web interface, and instead manually types "@al3x", for example, the tweet does not have an "in reply to" link. I consider this a very bad change. First of all, this completely breaks existing client behavior. I have seen this issue manifest itself with Twitterrific, Twhirl, the web interface, and most likely all other clients, because up to now they have either been oblivious to the "in_reply_to_status_id" parameter or they have been banking on the fact that not setting it causes the tweet to link to the latest tweet of the other twitterer. Additionally, I don't think all Twitterers who use the web interface realize that they need to click the reply swoosh in order to get the "in reply to" metadata, because earlier in Twitter's life, the "in_reply_to_status_id" parameter was nonexistent, and it was usually faster to manually type "@al3x" rather than to click the reply swoosh. I would submit that breaking existing behavior is something that should not be done willy-nilly. However, disregarding the pre- existing behavior argument, there is a more significant argument for the earlier behavior. With the earlier behavior, the "in reply to" link, even though it may not necessarily point to the exact tweet that the person is replying to, it still gives a rough context of the conversation. After the API change, there is *no* context *whatsoever*. Some context, even if it's incorrect, is better than no context at all. Even if the "in reply to" link is incorrect, it gives an upper bound to a possible tweet that is being replied to. There is an implicit practical lower bound (people usually don't respond to tweets that have been made 3 months ago). Without the "in reply to" link, the upper bound is lacking. Consider years down the road when someone wants to follow the conversation, it will be easier to figure it out the conversation with a rough context. I appreciate the need for Twitter to want to only link tweets so that exact conversations can be followed. However, I believe the former behavior has merit as well, and it's a little dismaying that Twitter's "product folks decided otherwise", without seemingly considering the effects of the API change. I would hope that Twitter would make an API change so that both are possible. Perhaps roll back to the previous behavior, but instead include another parameter with query responses that specifies whether the "in reply to" link is exact or whether it's only approximate. In fact, you might have three possible values for this parameter, one which specifies an exact link, one which specifies an approximate link, and one which explicitly specifies that no link should be made at all. The user can decide whether to eliminate context (because he's starting a new conversation), but the *default* should fall back to approximate context, not no context at all. Another change that would be most welcome in alleviating this problem is for individual tweet pages to always display five tweets: the exact tweet being targeted, and two tweets before and two tweets after, so that if the context is only approximate, the viewer does not have to go to that Twitterer's profile page in order to find the exact tweet context. (Better yet would be to have pagination available on individual tweet pages.) Please consider making a change on this very soon, because given existing user and Twitter client assumptions, the current API is making it very aggravating to follow conversations that are not exact, and there surely are many of these "approximate" conversations.
