statuses/replies now include mentions

[Doug Williams]

Devs,
Before today calls to statuses/replies [1] would return only tweets that were prefixed with a @username. As clients began to recognize the value in mentions of a @username anywhere in the tweet, they opted to perform a search for @username to get the superset.

Twitter agrees [2] that the definition of a reply has changed, and as such, calls to statuses/replies contain any tweets that include a mention of the authenticating user.

If your client has been using the Search API to retrieve @replies, you should begin to migrate to statuses/replies method as it now best practice.

1. http://apiwiki.twitter.com/REST-API-Documentation#statuses/replies
2. http://blog.twitter.com/2009/03/replies-are-now-mentions.html

Code on,
Doug Williams
Twitter API Support
http://twitter.com/dougw

[atebits]

Fantastic change - thanks!

On Mar 30, 5:39 pm, Doug Williams <d...@twitter.com> wrote:
> Devs,
> Before today calls to statuses/replies [1] would return only tweets that
> were prefixed with a @username. As clients began to recognize the value in
> mentions of a @username anywhere in the tweet, they opted to perform a
> search for @username to get the superset.
>
> Twitter agrees [2] that the definition of a reply has changed, and as such,
> calls to statuses/replies contain any tweets that include a mention of the
> authenticating user.
>
> If your client has been using the Search API to retrieve @replies, you
> should begin to migrate to statuses/replies method as it now best practice.
>
> 1.http://apiwiki.twitter.com/REST-API-Documentation#statuses/replies

> 2.http://blog.twitter.com/2009/03/replies-are-now-mentions.html

[Chad Etzel]

...and there was much rejoicing!
<Hooray.... />

-chad

[Alex Payne]

Something to keep in mind: our UX team has decided to represent this
feature as "@$username" on the web. If you don't have room for that
label in your Twitter app's GUI, consider an @ symbol. If you don't
like that representation, at least considering renaming "Replies" to
"Mentions" in your GUI to stay consistent with what new users will see
when they sign in to twitter.com.

That said, the new behavior is intuitive even with the label of
"Replies", so don't panic if it takes a few days (or weeks) to push
out a new version of your app with a new label in the GUI. You
shouldn't need to change any of the logic (though you may get to
remove some if you were doing vanity searches via the Search API).

If your users don't like the new behavior, it's trivial to give them
the option to filter out anything but tweets starting with
"@$username". We figured we'd err on the side of giving you more data
to work with.

Enjoy!

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

[Craig Hockenberry]

Are replies created by setting the in_reply_to_status_id with the
statuses/update method affected by this change?

There are some clients that set the id when doing things like
retweeting -- and these may or may not have a reference to a user's
screen name in them. Will these tweets continue to show up in the
statuses/replies feed?

-ch

On Mar 30, 5:39 pm, Doug Williams <d...@twitter.com> wrote:

> Devs,
> Before today calls to statuses/replies [1] would return only tweets that
> were prefixed with a @username. As clients began to recognize the value in
> mentions of a @username anywhere in the tweet, they opted to perform a
> search for @username to get the superset.
>
> Twitter agrees [2] that the definition of a reply has changed, and as such,
> calls to statuses/replies contain any tweets that include a mention of the
> authenticating user.
>
> If your client has been using the Search API to retrieve @replies, you
> should begin to migrate to statuses/replies method as it now best practice.
>
> 1.http://apiwiki.twitter.com/REST-API-Documentation#statuses/replies

> 2.http://blog.twitter.com/2009/03/replies-are-now-mentions.html

[Craig Hockenberry]

Will the individual status messages on the website continue to display
"in reply to screen_name"?

Will a message like "This tweet mentions @chockenberry" get an
in_reply_to_status_id, in_reply_to_user_id, in_reply_to_screen_name or
in_reply_to_status_id attribute set?

It sounds to me like you're not getting rid of replies so much as
making "Replies" a subset of "Mentions"...

-ch

> > 2.http://blog.twitter.com/2009/03/replies-are-now-mentions.html

[Jakk]

I've been waiting for this for so long, thank you!

On Mar 30, 8:39 pm, Doug Williams <d...@twitter.com> wrote:
> Devs,
> Before today calls to statuses/replies [1] would return only tweets that
> were prefixed with a @username. As clients began to recognize the value in
> mentions of a @username anywhere in the tweet, they opted to perform a
> search for @username to get the superset.
>
> Twitter agrees [2] that the definition of a reply has changed, and as such,
> calls to statuses/replies contain any tweets that include a mention of the
> authenticating user.
>
> If your client has been using the Search API to retrieve @replies, you
> should begin to migrate to statuses/replies method as it now best practice.
>
> 1.http://apiwiki.twitter.com/REST-API-Documentation#statuses/replies

> 2.http://blog.twitter.com/2009/03/replies-are-now-mentions.html

[Doug Williams]

Craig,
Great questions.

The in_reply_to_status_id will be honored only if the value is a status_id that was authored by a user that is also mentioned in the tweet. Therefore, if you include a status_id for this parameter and that is either 1) invalid or 2) does not belong to a user mentioned in the tweet, the field will be discarded.

Your second question then becomes pretty intuitive when coupled with our recent change to the in_reply_to_status_id field. If this field is valid by the rules above, it will produce a "in reply to <user>" in the Web GUI.

Thanks,

Doug Williams
Twitter API Support
http://twitter.com/dougw

[Jesse Stay]

What would be a nice addition would be the ability to have a "mentions" meta tag with the Tweet stating those mentioned in the Tweet.  Those in the "mentions" meta tag don't necessarily have to be in the Tweet.  Consider this similar to Facebook's "tagging" for photos and videos, and UIs could build tagging around that without the user ever having to mention anyone in the Tweet itself.

My thought on this is that by using that method, users wouldn't necessarily have to pollute their Tweets with a user's name while trying to get their attention.  It also wouldn't take away from the 140 characters and the Tweet could focus more on content.  I'd love to see the same types of meta-tagging for hashtags and keywords describing the Tweet.

Jesse

[tweetip]

In changing our code, we've decided:

"Show my replies" becomes "Show my mentions"

but

"Reply to" is not becoming "Mention to" - it stays Reply to

otoh

having both my replies and my mentions is something users will ask
for...

hth :)

[Mike Champion]

Great, this will be a helpful change.

Any discussion of codifying Retweets in a similar way in the search
API? It seems like they are also a subset of Mentions where 1) starts
with RT 2) includes a @mention 3) rest of the content (fuzzy) matches
a previous tweet by the @mention tweeter.

-mike

[Craig Hockenberry]

Thanks for the clarification, Doug. Overall, I think this is a very
positive change. Just a little spooked that it came out of the blue
like it did - maybe next time it would be wise to give us a bit of a
heads up before deploying...

More questions:

On http://twitter.com/account/notifications, will there be new options
to control how your @replies are handled? Currently, the user can
choose:

All @replies
@replies to the people I'm following
No @replies

Does this now mean:

All mentions
Mentions to the people I'm following
No mentions

?

I can also see there being a need to filter out some of your mentions:
if you're one of those users who gets a lot of retweets, seeing "RT
@chockenberry SAID SOMETHING FUNNY" is going to get pretty annoying as
thousands of people echo what you say. Is there going to be an option
so that only replies get put into your mentions feed (statuses/
replies)?

-ch

On Mar 30, 6:38 pm, Doug Williams <d...@twitter.com> wrote:
> Craig,
> Great questions.
>
> The in_reply_to_status_id will be honored only if the value is a status_id
> that was authored by a user that is also mentioned in the tweet. Therefore,
> if you include a status_id for this parameter and that is either 1) invalid
> or 2) does not belong to a user mentioned in the tweet, the field will be
> discarded.
>
> Your second question then becomes pretty intuitive when coupled with our
> recent change to the in_reply_to_status_id field. If this field is valid by
> the rules above, it will produce a "in reply to <user>" in the Web GUI.
>
> Thanks,
> Doug Williams

> Twitter API Supporthttp://twitter.com/dougw

[Cameron Kaiser]

> I can also see there being a need to filter out some of your mentions:
> if you're one of those users who gets a lot of retweets, seeing "RT
> @chockenberry SAID SOMETHING FUNNY" is going to get pretty annoying as
> thousands of people echo what you say. Is there going to be an option
> so that only replies get put into your mentions feed (statuses/
> replies)?

I think this is a stellar idea.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- How are you gentlemen? All your base are belong to us! ---------------------

[Cameron Kaiser]

> Great, this will be a helpful change.
>
> Any discussion of codifying Retweets in a similar way in the search
> API? It seems like they are also a subset of Mentions where 1) starts
> with RT 2) includes a @mention 3) rest of the content (fuzzy) matches
> a previous tweet by the @mention tweeter.

Yes, but it seems TMTOWTDI with RTs because I've also seen "xyzpdq (via
@omglol)", "retweet @omglol: xyzpdq", etc. There's too much variation in
syntax.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- You've got to have a gimmick if your band sucks. -- Gary Giddens -----------

[Chad Etzel]

On Mon, Mar 30, 2009 at 10:58 PM, Cameron Kaiser <spe...@floodgap.com> wrote:
>
>> Great, this will be a helpful change.
>>
>> Any discussion of codifying Retweets in a similar way in the search
>> API? It seems like they are also a subset of Mentions where 1) starts
>> with RT 2) includes a @mention 3) rest of the content (fuzzy) matches
>> a previous tweet by the @mention tweeter.
>
> Yes, but it seems TMTOWTDI with RTs because I've also seen "xyzpdq (via
> @omglol)", "retweet @omglol: xyzpdq", etc. There's too much variation in
> syntax.

"TMTOWTDI"
??????????????????????

There are only a few standard conventions I've seen for retweet structures:
(presented in regex-ish form)

^RT [@]?user[:]? .*$

^Retweet(ing)? [@]user[:]? .*$

^.* \((via )?[@]?user\)$

Now, those are only the first level retweets.. this doesn't take into
account the recursive retweets. In any case, I think it wouldn't be
too hard to sniff out the retweets.

-Chad

[Cameron Kaiser]

> > Yes, but it seems TMTOWTDI with RTs because I've also seen "xyzpdq (via
> > @omglol)", "retweet @omglol: xyzpdq", etc. There's too much variation in
> > syntax.
>
> "TMTOWTDI"
> ??????????????????????

There's More Than One Way To Do It

... I imagine there's not a big Perl crowd on this list. *le sigh*

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- Intel outside -- 6502 inside! ----------------------------------------------

[Chad Etzel]

On Tue, Mar 31, 2009 at 12:33 AM, Cameron Kaiser <spe...@floodgap.com> wrote:
>
>> > Yes, but it seems TMTOWTDI with RTs because I've also seen "xyzpdq (via
>> > @omglol)", "retweet @omglol: xyzpdq", etc. There's too much variation in
>> > syntax.
>>
>> "TMTOWTDI"
>> ??????????????????????
>
> There's More Than One Way To Do It
>
> ... I imagine there's not a big Perl crowd on this list. *le sigh*

Ah, of course... I had never seen it in acronym form before, and I was le tired.
AH MOTHERLAND!
-chad

[Jesse Stay]

On Mon, Mar 30, 2009 at 10:33 PM, Cameron Kaiser <spe...@floodgap.com> wrote:

> > Yes, but it seems TMTOWTDI with RTs because I've also seen "xyzpdq (via
> > @omglol)", "retweet @omglol: xyzpdq", etc. There's too much variation in
> > syntax.
>
> "TMTOWTDI"
> ??????????????????????

There's More Than One Way To Do It

... I imagine there's not a big Perl crowd on this list. *le sigh*

I got it - how young is this list? I'm only 31, but I guess that's old these days.  Perl's much more widely used than people think, I think.  Anyone noticed the YAML::Syck messages in SMS from Twitter lately?

Jesse

[swggy]

Sorry - not quite getting this (I hope). I wrote a twitterbot. Are you
saying that you are suddenly replacing the way 'http://twitter.com/
statuses/replies.json' works? That any reference to the 'bot's name
_anywhere_ in someone's message will now generate a reply message to
the 'bot where before it only got messages that _started_ with its
name? Because that could be a problem.

The type of messages that would have a 'bot's name in the middle are
ones that talk about the 'bot, not ones that are formatted to ask it
for info. As a result, the 'bot would reply to anyone who was - say -
retweeting by telling them their message was improperly formatted.
That's going to get vary irritating very quickly, and the 'bot is
going to get the blame - which isn't fair, since Twitter is the one
making this change, and the 'bot is only following the original API
spec.

I'm with Craig on this one - if you're going to make changes of this
nature, you need to run it past your users first - and do so far
enough in advance that they can make their changes.

(Unless my understanding about the change is all wrong - which is
entirely possible - in which case I apologize!)

Also, I see Alex is talking about @$username - is that documented
somewhere? I didn't find it when I went looking in the REST API doc
(or the search doc either, for that matter).

[Cameron Kaiser]

> Also, I see Alex is talking about @$username - is that documented
> somewhere? I didn't find it when I went looking in the REST API doc
> (or the search doc either, for that matter).

Alex means it as a pattern, i.e., "@doctorlinguist", "@al3x", etc.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- He who Laughs, Lasts. ------------------------------------------------------

[Cameron Kaiser]

> > Also, I see Alex is talking about @$username - is that documented
> > somewhere? I didn't find it when I went looking in the REST API doc
> > (or the search doc either, for that matter).
>
> Alex means it as a pattern, i.e., "@doctorlinguist", "@al3x", etc.

And, of course, I meant e.g., where @GrammarGirl can't see me.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- "I am Dyslexic of Brog. Fesistence is rutile. You will be asmilsilated." ---

[Doug Williams]

I'm going to combine a number of responses here so please bear with me:

@Mike:
I have heard no internal discussion of making retweets a feature, but that could simply be the result of freshman ignorance. As you point out in your post, the filtration of retweets from the timeline is one such instance where it would make sense. Regarding the change at hand, we feel the consensus from the user and developer community is that returning more data is a win. So, our current answer to the filtration of retweets is for applications to do that client side as desired.

@Craig:
We're learning here so one idea I need to keep in mind is transparency. Thank you for the feedback.

I've pinged the UX team and they said the copy around the @reply option in Settings will be updated within a week. Moreover, the migration from @replies language to mentions will be similar to the example you provided.

@Steve:
Your understanding of the change and its effect on your bot are correct. Differentiating between tweets that start with your bot's username and those with mentions buried within is trivial. So, as with Mike and Craig's filtration idea, transformation and manipulation of the data will have to be client-side.

Alex's mention of "@$username" is simply noting that the Web's GUI [1] has a tab labeled "@username" where it used to be "Replies". This request was for client developers, pushing them to work toward standardization of the user experience.

1. http://twitter.com/home

Regards,

Doug Williams
Twitter API Support
http://twitter.com/dougw

[Iain Dodsworth]

Superb update Doug, having all mentions of your username picked up via
replies/mentions is a real improvement which, from the TweetDeck
experience, has led to a marked increase in the use of @usernames in a
more conversational style. More importantly, it has also enabled/
encouraged the use of multi-user targeted tweets which IMO has
improved the utility of twitter.

I've stripped out the now redundant search API call from the replies
column and will be pushing out a new TweetDeck release (with some
interesting developments :)) later on this week.

Iain

[Peter Maurer]

> The in_reply_to_status_id will be honored only if the value is a status_id
> that was authored by a user that is also mentioned in the tweet.

Given the fact that we do have "in_reply_to_status_id" as a separate
meta data field to indicate a reply, I wonder why you guys require the
tweet to include the recipient's screen name. After all, tweets _are_
limited in length. I'm sure you thought long and hard about this, and
I'd be interested in some background information, if you don't mind,
Doug. Did you choose this path for user experience reasons only, or is
there also a technical reason?

All in all, I really like the new "Mentions", but I do wonder if a
separate "Replies" twitter.com section/API call, which doesn't require
mentioning of the recipient, would be worthwhile. That way, we'd have
even more data to play with. :)

Peter.

[Matt Sanford]

Hi all,

One thing to keep in mind when thinking about any meta-data
fields is that they are invisible via SMS. Some features that's ok for
(like the exact status it was a reply to) but the text of the message
itself should have enough context to be clear to the recipient. "@user
yes, I'll marry you" would make sense on SMS, just "yes, I'll marry
you" could be awkward :)

Thanks;
— Matt Sanford

[Cameron Kaiser]

[Charset WINDOWS-1252 unsupported, filtering to ASCII...]

>
> Hi all,
>
> One thing to keep in mind when thinking about any meta-data
> fields is that they are invisible via SMS. Some features that's ok for
> (like the exact status it was a reply to) but the text of the message
> itself should have enough context to be clear to the recipient. "@user
> yes, I'll marry you" would make sense on SMS, just "yes, I'll marry
> you" could be awkward :)
>
> Thanks;

> _ Matt Sanford

>
> On Mar 31, 2009, at 07:03 AM, Peter Maurer wrote:
>
> >
> >> The in_reply_to_status_id will be honored only if the value is a
> >> status_id
> >> that was authored by a user that is also mentioned in the tweet.
> >
> > Given the fact that we do have "in_reply_to_status_id" as a separate
> > meta data field to indicate a reply, I wonder why you guys require the
> > tweet to include the recipient's screen name. After all, tweets _are_
> > limited in length. I'm sure you thought long and hard about this, and
> > I'd be interested in some background information, if you don't mind,
> > Doug. Did you choose this path for user experience reasons only, or is
> > there also a technical reason?
> >
> > All in all, I really like the new "Mentions", but I do wonder if a
> > separate "Replies" twitter.com section/API call, which doesn't require
> > mentioning of the recipient, would be worthwhile. That way, we'd have
> > even more data to play with. :)
> >
> > Peter.
>
>

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- I am the mother of all things, and all things must wear a sweater. ---------

[sujamthe]

I love this feature. For a brandname like @bofa_help having @replies
in the start or body is all the same.
But for a personal brand, it is different as there are many stray
shoutouts like @ellentheshow.

We will bucket them as two different category for our clients, though
standard twitter clients may call them all as mentions.

Buts this is a great feature, adapting to our usage, thanks!

best,
Sudha

On Mar 30, 6:04 pm, Alex Payne <a...@twitter.com> wrote:

> > 2.http://blog.twitter.com/2009/03/replies-are-now-mentions.html

[Dossy Shiobara]

On 3/30/09 8:39 PM, Doug Williams wrote:
> If your client has been using the Search API to retrieve @replies, you
> should begin to migrate to statuses/replies method as it now best practice.

OMG! It's like Christmas, in March!

Thanks, Twitter Oompa-Loompas!

--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[Joshua Perry]

This hasn't been said but I'm assuming this is only for tweets from this
point forward, as I don't see any tweets from the past that "mention" my
username...

Doug Williams wrote:
> Devs,
> Before today calls to statuses/replies [1] would return only tweets
> that were prefixed with a @username. As clients began to recognize the
> value in mentions of a @username anywhere in the tweet, they opted to
> perform a search for @username to get the superset.
>
> Twitter agrees [2] that the definition of a reply has changed, and as
> such, calls to statuses/replies contain any tweets that include a
> mention of the authenticating user.
>

> If your client has been using the Search API to retrieve @replies, you
> should begin to migrate to statuses/replies method as it now best
> practice.
>

> 1. http://apiwiki.twitter.com/REST-API-Documentation#statuses/replies
> 2. http://blog.twitter.com/2009/03/replies-are-now-mentions.html

[Doug Williams]

Peter,
When the in_reply_to_status_id is set, the Web GUI appends the "in reply to <user>" to the tweet. Therefore, we want to confirm that status_id is owned by a user mentioned in the tweet before accepting the in_reply_to_status_id. This constraint permits a less confusing user experience by ensuring the tweet is indeed a reply to the status provided in the parameter.

Thanks,

Doug Williams
Twitter API Support
http://twitter.com/dougw

[Peter Maurer]

Thanks for explaining, Matt and Doug! I can appreciate your desire to
keep this simple and unambiguous, and the SMS notifications argument
is indeed a very compelling one. To be honest, I simply forgot about
SMS integration, because I'm using a dedicated client on my phone.
*feels sheepish*

(I'm still laughing out loud about the "yes, I'll marry you" example,
BTW. Rhetorical genius.)

[Martin Dufort]

And is this available now via the JSON API interface because,
according to my tests, I do not see any "in the middle of a tweet
mentions" being reported by the API.
Thanks - Martin

On Mar 31, 1:33 pm, Joshua Perry <j...@6bit.com> wrote:
> This hasn't been said but I'm assuming this is only for tweets from this
> point forward, as I don't see any tweets from the past that "mention" my
> username...
>
>
>
> Doug Williams wrote:
> > Devs,
> > Before today calls to statuses/replies [1] would return only tweets
> > that were prefixed with a @username. As clients began to recognize the
> > value in mentions of a @username anywhere in the tweet, they opted to
> > perform a search for @username to get the superset.
>
> > Twitter agrees [2] that the definition of a reply has changed, and as
> > such, calls to statuses/replies contain any tweets that include a
> > mention of the authenticating user.
>
> > If your client has been using the Search API to retrieve @replies, you
> > should begin to migrate to statuses/replies method as it now best
> > practice.
>
> > 1.http://apiwiki.twitter.com/REST-API-Documentation#statuses/replies

> > 2.http://blog.twitter.com/2009/03/replies-are-now-mentions.html

[Doug Williams]

Martin,
I'm not seeing the problem with statuses/replies.json you are reporting. For which account are you missing data?

Doug Williams
Twitter API Support
http://twitter.com/dougw

[sujamthe]

Doug,

I second Mike's suggestion to codify RTs. I have clients who want to
track RTs for two scenarios:

1. To find their brand influencers, as to who did the rts as they are
their brand advocates. It would be helpful to get to this in a quick
ap - track rts by person, how many rts of same content. I am gathering
this manually or by loading tweets from the search API into an overall
social media metrics tool and then massaging the data. Ideally I would
like to automate this to connect to the internal marketing engine.

2. This is also powerful for companies trying A/B testing of messaging
using RTs. Again tracking which rts echoed more and who give it the
bump up and times when it worked best.

I seem the lonely voice here as my needs are for building out
enterprise apps or rather integration of twitter into the enterprise.

best,
Sudha

Sudha Jamthe
http://tmeet.me and unnamed twitter apps for Intuit, Network World.

[Doug Williams]

The API is not able to support retweets as a feature until the main Twitter.com site offers some notion of retweets as a feature. As evidenced by the recent shift from @replies to mentions, Twitter does listen to the users' behavior to drive site changes. We obviously recognize the large number of users adopting retweets as a way to share good content. For now, though, retweets must be found through client-side parsing.

Thanks to all for the lively discussion on this thread. It has been valuable.

Doug Williams
Twitter API Support
http://twitter.com/dougw

[Martin Dufort]

Doug: I've rechecked everything and it seems the problem was on my
side. Sorry for the false report - Martin

On Apr 2, 5:40 pm, Doug Williams <d...@twitter.com> wrote:
> Martin,
> I'm not seeing the problem with statuses/replies.json you are reporting. For
> which account are you missing data?
>
> Doug Williams

> Twitter API Supporthttp://twitter.com/dougw

[Nick Arnett]

On Thu, Apr 2, 2009 at 4:29 PM, Doug Williams <do...@twitter.com> wrote:

The API is not able to support retweets as a feature until the main Twitter.com site offers some notion of retweets as a feature. As evidenced by the recent shift from @replies to mentions, Twitter does listen to the users' behavior to drive site changes. We obviously recognize the large number of users adopting retweets as a way to share good content. For now, though, retweets must be found through client-side parsing.

Thanks to all for the lively discussion on this thread. It has been valuable.

I'd like to point out, if it isn't already obvious, that this is part of a larger issue that many of us are probably expecting Twitter to someday tackle -- another kind of trend monitoring, similar to the various counters of explicit retweets and those that count what I call implicit retweets -- services like @twurlednews (mine) and @twitturly.

The more that people retweet, the more our timelines will be cluttered with redundancy.  As retweeting become easier and more standardized, it is an increasingly valuable source of intelligence, but it will also create problems that Twitter and this community will have to/get to solve.

In other words, consider the problems and opportunities that codifying retweets will create - I suspect that some API features will make sense to offer at the same time, providing summary data that makes it easy for clients to avoid all that redundancy.

Nick

[Andre Muller]

A big issue of the client side filtration of retweets is that the
server side pagination is lost...

I think Twitter Search API should add a parameter for replies...

Thank's Twitter is a great app!

André Luiz Müller

On Mar 31, 3:24 am, Doug Williams <d...@twitter.com> wrote:
> I'm going to combine a number of responses here so please bear with me:
>
> @Mike:
> I have heard no internal discussion of making retweets a feature, but that
> could simply be the result of freshman ignorance. As you point out in your
> post, the filtration of retweets from the timeline is one such instance
> where it would make sense. Regarding the change at hand, we feel the
> consensus from the user and developer community is that returning more data
> is a win. So, our current answer to the filtration of retweets is for
> applications to do that client side as desired.
>

[Matt Sanford]

Hi André,

    Search does have this feature, query for to:username to see the old replies behavior.

Thanks;

  — Matt Sanford / @mzsanford

[Andre Muller]

Thanks Matt

I thought it was only for direct messages... :)

By the way, is there a way to filter (exclude) the direct messages?

Tks!

André Luiz Müller

[Abraham Williams]

Direct messages are private and therefore not included in Search results. Search only includes public tweets.

--
Abraham Williams | Hacker | http://abrah.am
@poseurtech | http://the.hackerconundrum.com
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, WI, United States

[Andre Muller]

I could swear I saw my direct messages in a result list of
search.twitter.com in my tests this week...
Testing again they're not there... :(

But the way the API bring the replies is fine for me!

Thanks Abraham