ID of Replied To Status?
1 view
Skip to first unread message
Adam Stiles
Feb 29, 2008, 8:08:49 PM2/29/08
to Twitter Development Talk
When I reply to another Twitter user, the web interface displays an
"in reply to" link pointing to the status update I replied to. See:
http://twitter.com/ajstiles/statuses/765078470
I'd like to be able to track replies (the message replied to) via the
API but the original message ID is not included anywhere except the
HTML version of a status. See:
http://twitter.com/statuses/show/765078470.json
The replies API method only tracks replies to me, but not my replies
to others. Any way to do this?
Adam
"in reply to" link pointing to the status update I replied to. See:
http://twitter.com/ajstiles/statuses/765078470
I'd like to be able to track replies (the message replied to) via the
API but the original message ID is not included anywhere except the
HTML version of a status. See:
http://twitter.com/statuses/show/765078470.json
The replies API method only tracks replies to me, but not my replies
to others. Any way to do this?
Adam
Alex Payne
Mar 1, 2008, 3:48:36 PM3/1/08
to twitter-deve...@googlegroups.com
Yup, it's on our to-do list of things to add to the API. We're
focused on stability until after SXSW (see other threads going on this
group) but I have a stack of API improvements that I'll be getting to
once we get back.
focused on stability until after SXSW (see other threads going on this
group) but I have a stack of API improvements that I'll be getting to
once we get back.
--
Alex Payne
http://twitter.com/al3x
djvdm
Mar 30, 2008, 6:50:04 PM3/30/08
to Twitter Development Talk
Is there an approximate go live date for this functionality? We are
working on an application that would require tracking direct messages
back to the original message sent by our application to a twitter
user. We anticipate going live with this app in the next two weeks
(approx. April 11th) and this addition would help greatly in
simplifying what we want to achieve.
We would rather not rely on the user to send back an ID which we would
need to supply in the message because, well ... they are lazy and/or
forgetful. An ID (either a twitter message id that we could chain or
one we supply) would be necessary to update the original message
information and track all responses related to it. So if we can
anticipate when this type of functionality will be going live, we can
make a design decision as to which way to code, at least short term.
BTW, this will be a serious business application that could go live
with several thousand users who belong to a few groups we are
currently negotiating with, and has a tremendous potential to grow
exponentially if successful with these groups.
Thanks,
Doug
On Mar 1, 4:48 pm, "Alex Payne" <a...@al3x.net> wrote:
> Yup, it's on our to-do list of things to add to the API. We're
> focused on stability until after SXSW (see otherthreadsgoing on this
working on an application that would require tracking direct messages
back to the original message sent by our application to a twitter
user. We anticipate going live with this app in the next two weeks
(approx. April 11th) and this addition would help greatly in
simplifying what we want to achieve.
We would rather not rely on the user to send back an ID which we would
need to supply in the message because, well ... they are lazy and/or
forgetful. An ID (either a twitter message id that we could chain or
one we supply) would be necessary to update the original message
information and track all responses related to it. So if we can
anticipate when this type of functionality will be going live, we can
make a design decision as to which way to code, at least short term.
BTW, this will be a serious business application that could go live
with several thousand users who belong to a few groups we are
currently negotiating with, and has a tremendous potential to grow
exponentially if successful with these groups.
Thanks,
Doug
On Mar 1, 4:48 pm, "Alex Payne" <a...@al3x.net> wrote:
> Yup, it's on our to-do list of things to add to the API. We're
Alex Payne
Mar 30, 2008, 6:56:09 PM3/30/08
to twitter-deve...@googlegroups.com
I'll try to make the in_reply_to_user_id and in_reply_to_status_id attributes available as soon as possible for status objects returned by our API. Please note that these will only be available for status objects, not direct messages, as we don't track replies to direct messages.
djvdm
Mar 30, 2008, 7:13:05 PM3/30/08
to Twitter Development Talk
Appreciate the very speedy reply!!
Unfortunately, we will need to use the direct messages because the
information going back and forth will be confidential. Is there any
possibility of adding this functionality for direct messages in the
future? That would greatly expand the capabilities for business
applications. Would you have any suggestions of how we may do this
using the current API, other than relying on the user to send back our
supplied ID in their response? We'd like to avoid that, and also avoid
using too many apps to work around this.
Again, thanks for the speedy reply,
Doug
Unfortunately, we will need to use the direct messages because the
information going back and forth will be confidential. Is there any
possibility of adding this functionality for direct messages in the
future? That would greatly expand the capabilities for business
applications. Would you have any suggestions of how we may do this
using the current API, other than relying on the user to send back our
supplied ID in their response? We'd like to avoid that, and also avoid
using too many apps to work around this.
Again, thanks for the speedy reply,
Doug
Alex Payne
Mar 31, 2008, 2:04:45 AM3/31/08
to twitter-deve...@googlegroups.com
Is your primary goal to track which direct messages were sent by your
application, or to track the chain of direct message replies?
application, or to track the chain of direct message replies?
--
Alex Payne
http://twitter.com/al3x
djvdm
Apr 1, 2008, 5:34:40 PM4/1/08
to Twitter Development Talk
It would be to track the chain of direct messages back to the original
direct message, kind of like revisions to a document.
Doug
On Mar 31, 2:04 am, "Alex Payne" <a...@al3x.net> wrote:
> Is your primary goal to track which direct messages were sent by your
> application, or to track the chain of direct message replies?
>
>
>
> On Sun, Mar 30, 2008 at 4:13 PM, djvdm <dougvandemot...@gmail.com> wrote:
>
> > Appreciate the very speedy reply!!
>
> > Unfortunately, we will need to use the direct messages because the
> > information going back and forth will be confidential. Is there any
> > possibility of adding this functionality for direct messages in the
> > future? That would greatly expand the capabilities for business
> > applications. Would you have any suggestions of how we may do this
> > using the current API, other than relying on the user to send back our
> > suppliedIDin their response? We'd like to avoid that, and also avoid
> > > API. Please note that these will only be available forstatusobjects, not
> > > > > > HTML version of astatus. See:
direct message, kind of like revisions to a document.
Doug
On Mar 31, 2:04 am, "Alex Payne" <a...@al3x.net> wrote:
> Is your primary goal to track which direct messages were sent by your
> application, or to track the chain of direct message replies?
>
>
>
> On Sun, Mar 30, 2008 at 4:13 PM, djvdm <dougvandemot...@gmail.com> wrote:
>
> > Appreciate the very speedy reply!!
>
> > Unfortunately, we will need to use the direct messages because the
> > information going back and forth will be confidential. Is there any
> > possibility of adding this functionality for direct messages in the
> > future? That would greatly expand the capabilities for business
> > applications. Would you have any suggestions of how we may do this
> > using the current API, other than relying on the user to send back our
> > using too many apps to work around this.
>
> > Again, thanks for the speedy reply,
>
> > Doug
>
> > On Mar 30, 6:56 pm, "Alex Payne" <a...@al3x.net> wrote:
> > > I'll try to make the in_reply_to_user_id and in_reply_to_status_id
> > > attributes available as soon as possible forstatusobjects returned by our
>
> > Again, thanks for the speedy reply,
>
> > Doug
>
> > On Mar 30, 6:56 pm, "Alex Payne" <a...@al3x.net> wrote:
> > > I'll try to make the in_reply_to_user_id and in_reply_to_status_id
> > > API. Please note that these will only be available forstatusobjects, not
> > > direct messages, as we don't track replies to direct messages.
>
> > > On Sun, Mar 30, 2008 at 3:50 PM, djvdm <dougvandemot...@gmail.com> wrote:
>
> > > > Is there an approximate go live date for this functionality? We are
> > > > working on an application that would require tracking direct messages
> > > > back to the original message sent by our application to a twitter
> > > > user. We anticipate going live with this app in the next two weeks
> > > > (approx. April 11th) and this addition would help greatly in
> > > > simplifying what we want to achieve.
>
> > > > We would rather not rely on the user to send back anIDwhich we would
>
> > > On Sun, Mar 30, 2008 at 3:50 PM, djvdm <dougvandemot...@gmail.com> wrote:
>
> > > > Is there an approximate go live date for this functionality? We are
> > > > working on an application that would require tracking direct messages
> > > > back to the original message sent by our application to a twitter
> > > > user. We anticipate going live with this app in the next two weeks
> > > > (approx. April 11th) and this addition would help greatly in
> > > > simplifying what we want to achieve.
>
> > > > need to supply in the message because, well ... they are lazy and/or
> > > > forgetful. AnID(either a twitter messageidthat we could chain or
> > > > one we supply) would be necessary to update the original message
> > > > information and track all responses related to it. So if we can
> > > > anticipate when this type of functionality will be going live, we can
> > > > make a design decision as to which way to code, at least short term.
> > > > BTW, this will be a serious business application that could go live
> > > > with several thousand users who belong to a few groups we are
> > > > currently negotiating with, and has a tremendous potential to grow
> > > > exponentially if successful with these groups.
>
> > > > Thanks,
>
> > > > Doug
>
> > > > On Mar 1, 4:48 pm, "Alex Payne" <a...@al3x.net> wrote:
> > > > > Yup, it's on our to-do list of things to add to the API. We're
> > > > > focused on stability until after SXSW (see otherthreadsgoing on this
> > > > > group) but I have a stack of API improvements that I'll be getting to
> > > > > once we get back.
>
> > > > > On Fri, Feb 29, 2008 at 5:08 PM, Adam Stiles <a...@stilesoft.com> wrote:
>
> > > > > > When I reply to another Twitter user, the web interface displays an
> > > > > > "in reply to" link pointing to thestatusupdate I replied to. See:
> > > > information and track all responses related to it. So if we can
> > > > anticipate when this type of functionality will be going live, we can
> > > > make a design decision as to which way to code, at least short term.
> > > > BTW, this will be a serious business application that could go live
> > > > with several thousand users who belong to a few groups we are
> > > > currently negotiating with, and has a tremendous potential to grow
> > > > exponentially if successful with these groups.
>
> > > > Thanks,
>
> > > > Doug
>
> > > > On Mar 1, 4:48 pm, "Alex Payne" <a...@al3x.net> wrote:
> > > > > Yup, it's on our to-do list of things to add to the API. We're
> > > > > focused on stability until after SXSW (see otherthreadsgoing on this
> > > > > group) but I have a stack of API improvements that I'll be getting to
> > > > > once we get back.
>
> > > > > On Fri, Feb 29, 2008 at 5:08 PM, Adam Stiles <a...@stilesoft.com> wrote:
>
> > > > > > When I reply to another Twitter user, the web interface displays an
>
> > > > > > http://twitter.com/ajstiles/statuses/765078470
>
> > > > > > I'd like to be able to track replies (the message replied to) via the
> > > > > > API but the original messageIDis not included anywhere except the
> > > > > > http://twitter.com/ajstiles/statuses/765078470
>
> > > > > > I'd like to be able to track replies (the message replied to) via the
> > > > > > HTML version of astatus. See:
m1k3y
May 9, 2008, 6:14:19 AM5/9/08
to Twitter Development Talk
Just to clarify, would this involve the addition of an
in_reply_to_status_id parameter to the "update" call?
Seems like that would:
a) save you a lookup to get the user's latest status_id - which I'm
guessing is how you're populating that currently.
b) enable people to then reply to a specific tweet, rather than it
just implicitly be the latest of that user.
c) stop the false-positives you see, where people aren't actually
replying to someone, but starting a conversation. ie by passing an
in_reply_status_id of NULL
d) make threaded services like http://quotably.com more useful.
Apologies in advance if I'm missing something obvious here.
Mike
in_reply_to_status_id parameter to the "update" call?
Seems like that would:
a) save you a lookup to get the user's latest status_id - which I'm
guessing is how you're populating that currently.
b) enable people to then reply to a specific tweet, rather than it
just implicitly be the latest of that user.
c) stop the false-positives you see, where people aren't actually
replying to someone, but starting a conversation. ie by passing an
in_reply_status_id of NULL
d) make threaded services like http://quotably.com more useful.
Apologies in advance if I'm missing something obvious here.
Mike
Alex Payne
May 9, 2008, 5:22:53 PM5/9/08
to twitter-deve...@googlegroups.com
Indeed, that's the plan.
--
Alex Payne
http://twitter.com/al3x
m1k3y
May 9, 2008, 8:31:29 PM5/9/08
to Twitter Development Talk
Excellent. Look forward to it!
On May 10, 7:22 am, "Alex Payne" <a...@twitter.com> wrote:
> Indeed, that's the plan.
>
>
>
> On Fri, May 9, 2008 at 3:14 AM, m1k3y <mp.hi...@gmail.com> wrote:
>
> > Just to clarify, would this involve the addition of an
> > in_reply_to_status_id parameter to the "update" call?
>
> > Seems like that would:
>
> > a) save you a lookup to get the user's latest status_id - which I'm
> > guessing is how you're populating that currently.
>
> > b) enable people to then reply to a specific tweet, rather than it
> > just implicitly be the latest of that user.
>
> > c) stop the false-positives you see, where people aren't actually
> > replying to someone, but starting a conversation. ie by passing an
> > in_reply_status_id of NULL
>
> > d) make threaded services likehttp://quotably.commore useful.
On May 10, 7:22 am, "Alex Payne" <a...@twitter.com> wrote:
> Indeed, that's the plan.
>
>
>
> On Fri, May 9, 2008 at 3:14 AM, m1k3y <mp.hi...@gmail.com> wrote:
>
> > Just to clarify, would this involve the addition of an
> > in_reply_to_status_id parameter to the "update" call?
>
> > Seems like that would:
>
> > a) save you a lookup to get the user's latest status_id - which I'm
> > guessing is how you're populating that currently.
>
> > b) enable people to then reply to a specific tweet, rather than it
> > just implicitly be the latest of that user.
>
> > c) stop the false-positives you see, where people aren't actually
> > replying to someone, but starting a conversation. ie by passing an
> > in_reply_status_id of NULL
>
Reply all
Reply to author
Forward
0 new messages