in_reply_to_status_id

[Alex Payne]

All,

I'm happy to announce a minor change to the API that should have a
major impact on the Twitter community. The /statuses/update method
now takes an optional parameter: in_reply_to_status_id. As you might
guess, this allows API clients to specify which status a status to be
posted is in reply to, rather than our system assuming that it's in
reply to the last message posted by the user specified by "@username".

If your client posts statuses, please consider making use of this
feature. By convention, we'd like to continue to use "@username" at
the beginning of messages that are replies, but specifying the
in_reply_to_status_id parameter will override the guess about the
in_reply_to_status_id attribute that our system makes. Yes, this does
mean that you could post a message that appears to be a reply to Alice
while it's actually a reply to Bob; that's fine, as I'm sure there's a
use case for it out there.

We hope this addition will allow for more accurate conversations on
Twitter. I can't wait to see what you all do with it!

--
Alex Payne
http://twitter.com/al3x

[Andrew Badera]

W00T!

--
--
--Andy Badera
http://higherefficiency.net
http://flipbitsnotburgers.blogspot.com/
http://andrew.badera.us/
http://changeroundup.com/
and...@badera.us
(518) 641-1280
Google me: http://www.google.com/search?q=andrew+badera

[Kee Hinckley]

On Aug 14, 2008, at 1:37 PM, Andrew Badera wrote:
> W00T!

Took the word right out of my mouth!

[Hans Engel]

This is a really good addition, but I just discovered a bug via some
testing with cURL.

If the tweet is sent with in_reply_to_status_id set to a valid tweet ID,
but the tweet doesn't contain '@user' or something, 'in reply to user'
is still displayed on the Twitter user's profile.

If I didn't explain that right, please tell me - I'll try again :P

☂

[Alex Payne]

Yes, that's the expected behavior for the moment. As I mentioned,
we'd like application developers to populate the "@user" bit at the
start of a status that's a reply, but there are use cases in which you
wouldn't want to.

--
Alex Payne
http://twitter.com/al3x

[David Look]

how goes the problem with Yahoo Pipes? Is there a current work around for this? like perhaps running the RSS through Feeddigest and then through pipes?
thanks.dl

[Richard]

Have you considered supporting a syntax like
@username.status_id
as well
e.g.
@someone.1463635340

though, I can't remember why I thought this would be better now.

--
Richard.
friendbinder.com

[Ed Finkler]

That would be handy in that you could embed the "in_reply_to" info
within the message. I know in my app, allowing this syntax would mean
less refactoring to get in_reply_to working.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

[Ray Grieselhuber]

This is very cool, by the way. Thanks for adding it.

Are there any plans to include replies created using this method in
the feed for a user's Tweets? That would make visualizing
conversations much easier.

[Ray Grieselhuber]

Is this change related at all to the fact that many users (including
myself) can no longer see their replies, either via the web client or
the API? When will this be fixed?

On Aug 15, 2:34 am, "Alex Payne" <a...@twitter.com> wrote:

[vlb]

Finally! I've been asking for this for months!

[ironfroggy]

Will there be a way to determine, when looking at a specific reply, if
the in_reply_to_status_id was given by the client or guessed by the
system? It could be useful to know if its accurate or possibly
incorrect.

[Matthew Horspool]

Hi,

Richard wrote: "Have you considered supporting a syntax like
@username.status_id ... though, I can't remember why I thought this would be
better now."

I wouldn't use it in an app because it would use up valuable space.
However, it would still be a useful addition because it would then allow you
to reply to a specific status from the web, SMS, etc.

Matthew

[me at work]

I think this is totally awesome and great and I love you for having
implemented it. The next thing would be a way to update an old
update's in_reply_to in the API, mainly so that sites like quotably
which implement a way to fix which tweet you're replying to (sorta)
could post back updates to the user. Of course, I'd support it in a
certain implementation (but these are not for twitter, but for
quotably and just general discussion of how this API could be useful)

Changes made by the logged in user to his own tweets would happen
instantly.

Changes made by logged in trusted users to a users tweets (i.e. your
friends), or by the person the SPECIFIC TWEET is in reply to (so I
could fix, for example, a newbie friend of mine's tweet to be in reply
to the correct tweet of mine) would happen instantly, but would show
up in a user's control panel on quotably and they could review and
undo (quotably would have to store the original in_reply_to for this).

Changes made by untrusted users would go to a queue which trusted
users, the person who made the specific tweet, and the user himself
could check and approve.

Of course, those are the default settings, some users may want to have
complete control so that everything would go to a queue. I just like
the idea of crowdsourcing retro-reply-repairs.

[TCI]

Let me express my gratitude for you guys providing this. It does help
a lot and if we properly use it we can all have more cohesive and
followable conversations. Thanks a lot...
TCI

[Jason Follas]

This fills me with joy and happiness. :-)

But, seriously, I understand that it might be impossible to implement
the in_reply_to_status_id for SMS (guessing would still be appropriate
there, considering the limitations). But, it also appears that the
web interface is not providing in_reply_to_status_id when you reply by
clicking the swoosh. Was this an oversight, or is development still
in the works?

> >http://twitter.com/al3x- Hide quoted text -
>
> - Show quoted text -

[Alex Payne]

Still in the works.

--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x

[dwardu]

I’ve written a Greasemonkey script to do the job until it’s done
properly… http://userscripts.org/scripts/show/32728

Thanks.