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!
On Thu, Aug 14, 2008 at 1:34 PM, Alex Payne <a...@twitter.com> wrote:
> 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!
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
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.
On Thu, Aug 14, 2008 at 4:10 PM, Hans Engel <en...@engel.uk.to> wrote:
> 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
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
On Thu, Aug 14, 2008 at 4:13 PM, Alex Payne <a...@twitter.com> wrote: > 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.
> On Thu, Aug 14, 2008 at 4:10 PM, Hans Engel <en...@engel.uk.to> wrote:
> > 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
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.
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.
On Aug 15, 2:34 am, "Alex Payne" <a...@twitter.com> wrote:
> 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!
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:
> 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!
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.
On Aug 14, 1:34 pm, "Alex Payne" <a...@twitter.com> wrote:
> 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!
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.
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.
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
> 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!
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?
On Aug 18, 6:04 pm, TCI <ticoconid...@gmail.com> wrote:
> 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
> Alex Payne wrote:
> > 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!
On Tue, Aug 19, 2008 at 5:42 AM, Jason Follas <jfol...@gmail.com> wrote:
> 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?
> On Aug 18, 6:04 pm, TCI <ticoconid...@gmail.com> wrote: >> 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
>> Alex Payne wrote: >> > 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!
> 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!
|
