One of the main confusions and criticisms about the retweet API was
around what happens when a given tweet is retweeted multiple times.
The explanation was that developers need to do their own retweet
collapsing. If N people retweet a given tweet, you'd get N instances
of that same tweet in the appropriate retweet timeline and the home
timeline. You would then have to do your own internal book keeping
about whether that tweet had already come in. If it hadn't you'd
display it for the first time. If it had you'd update the already
displayed tweet.
Asking developers to collapse retweets in timelines is onerous,
complicated and confusing. We're not going to do it that way. We are
going to add a resource that gives you all retweets for a given tweet.
In timelines you will get only the first retweet. You can then request
all retweets for that tweet at any time to get up to 100 retweets that
have been created for it.
Here is the documentation for the new resource, statuses/retweets:
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets
Sincere apologies if you've already written collapsing logic for
retweets. Beta releases are beta releases and I think the retweet API
is a lot better without the onerous collapsing requirement.
To give you some ideas of how you can use the API to display retweets,
here is a recent mock up of one of the potential UIs for the retweets
timeline on twitter.com:
http://a1.twimg.com/example-retweet-ui-18-sep-09.png
If you've got questions, find bugs, or have any kind of feedback, get
in touch via the dev mailing list, send an @reply to @twitterapi or
jump into the #twitterapi IRC channel on irc.freenode.net.
--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio
Asking developers to collapse retweets in timelines is onerous,
complicated and confusing. We're not going to do it that way. We are
going to add a resource that gives you all retweets for a given tweet.
In timelines you will get only the first retweet. You can then request
all retweets for that tweet at any time to get up to 100 retweets that
have been created for it.
In this example, how did you retrieve the number and names of people that
retweeted? Did you have to issue a separate request to statuses/retweets for
every single tweet in the timeline? I am concerned about how this affects
(mobile) clients on slow and/or expensive connections. Also, how will this
interact with the API rate limiting?
I would like to present the names and count of all *friends* (people the
user is following) that re-tweeted the tweet. This is a much more useful
metric than the total number of strangers worldwide that retweeted it
(especially when you consider re-tweeting spammers). It seems like this will
be impossible if more than 100 people re-tweeted the tweet. The old design
was much better in this respect.
In particular, now how can we answer the question "who do I need to
un-follow to stop get this tweet out of my timeline"?
There's a potentially serious problem with tying the display of the retweet
with the first time it is retweeted. Let's say one of your friends ("Ae")
retweets something on a Friday night. Then a bunch of your friends tweet
through the weekend. Then, 50 of your other business associate friends show
up for work on Monday and retweet the same thing Ae re-tweeted on Friday
night. You will likely not even realize that your business associates are
interested in that retweet when you show up for work on Monday, unless you
scroll page through all those weekend tweets to the time Ae retweeted them.
With the old design, the client could handle this in a much smarter way.
Will there be an increase in the API rate limits when this change is made?
AFAICT, this new feature increase the number of requests my client makes per
"refresh" substantially for many of my users. The increase in the number of
requests seems to be a killer because of rate limiting.
I would love to be included as a tester of this in the web UI. I am
@BRIAN_____ and @GOROGOROmobi.
Regards,
Brian
The nice thing about being an API client is that you can, of course, change
how the tweet is presented. In fact, that is exactly my plan for TTYtter to
change retweets so that they come from the person who RTed it, not the
person being RTed (who appears appended).
Still, I'm sort of with Dewald and others that I'm really having a hard
time seeing what the RT API buys, and I can see quite a few things that the
old "manual" way does better.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Smile! God loves you! ------------------------------------------------------
The small benefit to us humans is that clients may be more able to
present tweets as a threaded conversation if they understand that
discreet tweets are, in fact, part of a conversation. The large benefit
to Twitter and corporations is that they can more easily track social
behavioral patterns (== more finely targeted marketing and advertising
and ROI calculations).
Fortunately, it's all opt-in. Unfortunately, it's all opt-in.
I'm with the others, though, that IMHO retweets should not be deleted if
an original retweet (or one up in the chain? dunno) is deleted.
Possibly it's only in there because this (having "gaps" in tweets
brought about by deleted tweets) breaks the programmatic ability to
follow a thread. Not sure.
Joseph Cheek
jos...@cheek.com, www.cheek.com
twitter: http://twitter.com/cheekdotcom