- Creating Retweets
The API documentation for creating retweets can be found here:
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweet
Reminder: Making requests to /statuses/retweet won't work yet as the
feature has not launched.
- Consuming Retweets in the Timeline
1) Retweets in the new home timeline
We don't want to break existing apps that don't add retweeting support
or create a confusing experience for that app's users. So the
/statuses/friends_timeline API resource will remain unchanged--i.e.
retweets will *not* appear in it.
For those who *do* want to support retweets, we are adding a new (more
aptly named) /statuses/home_timeline resource. This *will* include
retweets. The /statuses/friends_timeline API resource will continue to
be supported in version 1 of the API. In version 2 it will go away and
be fully replaced by /statuses/home_timeline.
The API documentation for the home timeline, which includes retweets,
can be found here:
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_timeline
Take a look at the example payload in the documentation. The original
tweet that was retweeted Thanks appears in the timeline. Notice the
embedded "retweet_details" element. It contains the user who created
the retweet as well as the date and time the retweet occurred.
2) Retweeted by me timeline
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweeted_by_me
3) Retweeted to me timeline
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweeted_to_me
4) My tweets, retweeted
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets_of_me
Reminder: Making requests to any of these timelines won't work yet as
the feature has not launched.
UI considerations:
------------------
Here are some early draft design mockups of how retweets might appear
on the Twitter website (don't be surprised if
it doesn't look exactly like this). They are presented just as an
example of how retweets can be differentiated visually.
http://s.twimg.com/retweet-dev-mocks-7-aug-09.png
Things to note:
1) It was important for us that retweets are easily differentiated
visually from regular tweets. If someone you follow retweets a tweet,
the original tweet will appear in your timeline whether you follow the
author of the original tweet or not, just as it currently does when
users use the "RT" convention. Seeing a tweet in your timeline from
someone you don't follow without being told it was shared from someone
you *do* follow could be confusing. So we're encouraging developers to
be mindful of this confusion and make retweets stand out visually from
regular tweets.
2) The retweeted tweet shows the username of the first of your
followers to retweet it. If other's subsequently retweet the same
tweet, the retweet should only appear once in a user's timeline
That's it for now.
We'll be sending out more updates as we get closer to launching.
--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio
This new api looks very cool. Good work twitter API team. :)
Josh
I expect that if this change is made, many people will retweet and then
reply to add their own commentary. But, this raises an issue: If I retweet
something and then reply to it, will the reply to the retweet show up for
all my followers? Right now the reply would only show up for followers that
were also following the original author, but that does not match the
intentions of a user that is doing a retweet-then-reply.
How are you going to present retweets in the SMS interface?
I don't see how the proposed UI answers the question "Why am I am seeing
this tweet when I'm not following this guy?" Is the "retweeted by" line
going to list only people I'm following, or is it going to list ALL people
that retweeted the message? From the way it is worded, it looks like it is
the latter (all people), but it would be more useful if it was the former.
Regards,
Brian
Could we have an extension to the search API so that I could search
for a term which has been tweeted?
Scenario:
I want to know how many times a particular term has been included in a
retweet which I can then aggregate to see how many times it has been
retweeted as a total.... I know it's similar to TweetMeme, but they
are links - I want terms :)
What do you think?
Thanks
@Ben_Hall
I do like the way a lot of this grows organically. This is great
functionality
and will save a lot of data mining :-)
ATB
Neil
Right. And this mechanism will provide a way to differentiate between
plain retweets and value added retweets.
+1 to the API team.
Chris
I think the ReTweet concept is more complex than the model in the
Retweet API described. While twitter has always been a keep it simple
service, I think you will find many users wont use this new
functionality if they can't use it the way they do currently (with
additional comments)..
I think somehow a hybrid of simple rebroadcasting and commenting on
the rebroadcast would be powerful enhancement to the Twitter service.
Being able to track retweets is very cool, but being able to track
what people say about the content they are redistributing is where the
power of social communication lies, it drives the conversation forward
by engaging more users..
I'm not sure of the name of it but we had one at BarCampNYC that did as
you described for anyone who used the hashtag BCNYC5
Regards,
Dean Collins
Cognation Inc
de...@cognation.net
+1-212-203-4357 New York
+61-2-9016-5642 (Sydney in-dial).
+44-20-3129-6001 (London in-dial).
If you are not following them whats your problem?
Eg. Ford might want to set up a twitter account that RT a posts about anyone who mentions Ford in their tweets. Whats your problem with that?
Of course it could get publicly commandeered like the 'Skittles' experiment this year but that's not Twitters problem, and it's certainly not 'your' problem.
Regards,
Dean Collins
de...@MyTwitterButler.com
+1-212-203-4357 New York
+61-2-9016-5642 (Sydney in-dial).
+44-20-3129-6001 (London in-dial).
-----Original Message-----
From: Dean Collins
Sent: Friday, August 14, 2009 9:34 AM
To: 'twitter-deve...@googlegroups.com'
Subject: RE: [twitter-dev] Re: Early developer preview: Retweeting API
There are lots of apps that capture this information already.
I'm not sure of the name of it but we had one at BarCampNYC that did as you described for anyone who used the hashtag BCNYC5
Regards,
Dean Collins
Cognation Inc
de...@cognation.net
+1-212-203-4357 New York
+61-2-9016-5642 (Sydney in-dial).
+44-20-3129-6001 (London in-dial).
-----Original Message-----
From: twitter-deve...@googlegroups.com [mailto:twitter-deve...@googlegroups.com] On Behalf Of Dewald Pretorius
Sent: Friday, August 14, 2009 9:31 AM
To: Twitter Development Talk
Subject: [twitter-dev] Re: Early developer preview: Retweeting API
Not a fan of this. In TTYtter, for example, I have keyword searches running
for topics I am personally interested in, and some of those tweets I will
retweet even though I don't follow the people who made them.
I see your point, but I think this would be unnecessarily restrictive to the
vast majority. As it is, I'm sure there are already bots that do things
like that, and the RT methods would at most be another way to facilitate it.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- "I'd love to go out with you, but I need to clean my toilet brush." --------
1) This change/addition would be great IFF retweets were then NOT part
of replies/mentions. I've got a script that checks for mentions and
then emails me them, and RTs are just clutter.
2) I would MUCH RATHER see something done about being able to follow a
conversation, i.e. I give you a status ID, and you show me all the
messages related to it (all the messages in the 'conversation chain'
before or after it.
This has been a long-standing wish causing many people to try to
create their own hackish workarounds because really it has to be
supported in the API.
3) It would be nice if someone RTs a message and someone 'favorites'
it, the favorite goes to the original author. OTOH then we get into
"Well is this a 'value added' RT?" and then "Does 'HAHAHA THIS MADE ME
LAFF' count as 'value'?" but at least for "straight" RTs, it would at
least bring some value to having this in the API.
I realize that not everyone will benefit from every API change, but
focusing on something like RTs (which definitely have lots of fans and
lots of detractors) instead of conversation threads (which people have
been requesting for longer than RTs have even been 'a thing' and which
I've never heard anyone be against and can't imagine what an argument
against would even look like) is confusing to me.
My 2¢
TjL
It is important to be able to un-retweet. I would also like to know how it
is done.
> 8. If a protected user retweets a status update of a non-protected
> user, will the protected user always / sometimes / never be listed as
> a retweeter of the public user's status update?
>
> 9. Conversely, if a non-protected user retweets a status update of a
> protected user, will the protected status update always / sometimes /
> never be included in the various timelines of the non-protected user?
Protected users' activities should never be disclosed to people outside
their list of approved followers. The privacy advantage of the current "RT
@foo" convention is that the reader never knows if @foo actually said what
was retweeted unless @foo approved him as a follower.
Here's another sticky issue, related to that: What happens when a user posts
a tweet, and then a bunch of people retweet it, and then the user deletes
the tweet? The original poster doesn't want to be associated with the
message anymore and would rather that message not exist. But, the
re-tweeters expect to have an archive of everything they retweeted.
Regards,
Brian
On Mon, Aug 17, 2009 at 10:31 AM, jim.renkel<james....@gmail.com> wrote:
>
> I have both practical and philosophical concerns and questions with
> this proposal. Since I'm a little late in commenting on this, some of
> these have already been raised. Where I know that is the case, I'll
> keep it short, but include it to show my support (or not) of the
> issue.
>
> This post contains practical issues. A companion post will contain
> philosophical issues.
>
> 1. When a retweet is created it is assigned an ID number, just like a
> status update. Are retweets and status updates numbered from the same
> sequence of numbers, or separate ones? I mainly ask out of curiosity,
> but there are some implications as shown below.
Tweets and retweets are currently numbered from the same sequence of numbers.
> 2. Is there a limit on the number of times a status update can be
> retweeted? Again, curiosity, but with implications.
No.
> 3. In the UI, if a status update is shown that has been retweeted, are
> all retweeters of the update listed, or, e.g., just ones that I
> follow? If all retweeters are listed, what if the status update was
> retweeted, say, 1,000 times? 10,000 times? If just retweeters that I
> follow are listed, can I somehow see a list of all the retweeters?
The UI concern of indicating who has retweeted has been addressed,
though it isn't displayed in the sample screenshot. It is collapsed
into a count of the total number of retweets with a summary after a
certain threshold.
> 4. The response to the status/retweet method provides details about
> the retweet that was created. Does it also include details on previous
> retweets of the status update?
No.
"Is the status update repeated once per retweet?" Yes.
> 6. Each XML retweet_details "section" takes around 100-200 characters
> to encode. If a response that includes retweet_details only returns
> retweets for those I follow, if I have 20 retweeted status updates
> each with, say, 20 retweets, that's 20*20*100=40000 plus characters
> required for the response. Even if the response only includes 1
> retweeted status update, but it has been retweeted 10,000 times (Not
> unheard of! And IMHO it's more likely to happen once this is deployed
> and folk start writing "retweebots"), that's 1*10000*100=1000000 plus
> characters. I think there's a problem here that needs to be addressed.
Here you are trading off payload size with number of network calls.
Rather than exposing IDs pointing to the author of the retweet and the
tweet that is retweeted, we've opted to include the data inline. More
pathological scenarios involving retweetbots are mitigated with a
combination of measures outside the purview of the platform team.
> 7. If retweets and status updates are numbered from the same sequence
> of IDs, then presumably statuses/destroy can be used to delete a
> retweet. If retweets and status updates have separate ID sequences,
> then I don't see any way to delete a retweet. I think the ability to
> delete a retweet is essential! BTW, I don't see any delete capability
> in the proposed UI.
In the absence of an obvious use case for including the retweet's id,
we were omitting it. Deleting the retweet via the API is a very
reasonable use case. Thanks. We'll add a 'retweet_id' to the
retweet_details section.
> 8. If a protected user retweets a status update of a non-protected
> user, will the protected user always / sometimes / never be listed as
> a retweeter of the public user's status update?
>
> 9. Conversely, if a non-protected user retweets a status update of a
> protected user, will the protected status update always / sometimes /
> never be included in the various timelines of the non-protected user?
Security/visibility concerns are the same as with any status update.