Early developer preview: Retweeting API
Marcel Molina
experience. It's yet another example of Twitter's users discovering
innovative ways to use the service. We dig it. So soon it's going to
become a natively supported feature on twitter.com. It's looking like
we're only weeks away from being ready to launch it on our end. We
wanted to show the community of platform developers the API we've
cooked up for retweeting so those who want to support it in their
applications would have enough time to have it ready by launch day. We
were planning on exposing a way for developers to create a retweet,
recognize retweets in your timeline and display them distinctively
amongst other tweets. We've also got APIs for several retweet
timelines: retweets you've created, retweets the users you're
following have created, and your tweets that have been retweeted by
others.
- 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
Beier
Vincent Nguyen
janole
people might just continue to use the current "RT ..." convention.
Retweeting can be a way of acknowledging a tweet or disapproving a
tweet etc.
If you search for "RT" in search.twitter.com you'll see a lot of
commented retweets.
Ole
--
@janole / mobileways.de / Gravity
Josh Roesslein
Josh
David
this data to see which Twitter client/tool aids and promotes spreading
of tweets.
Josh Roesslein
Maybe it would be nice to include a parameter flag that allows us
to specify if we want retweets included in the response. With this flag set
home_timeline would act just like the current friends_timeline.
This allows us to give the user an option if they would prefer to have retweets
included or not in their home timeline.
This new api looks very cool. Good work twitter API team. :)
Josh
Josh
Sean P.
best in this regard. For example, if I had a tweet that I found,
regardless of who its from, I can retweet it, but link together the
original tweet in the same manner that we do for the replies. Thus, we
create a chain of where a retweeted message came from but also allows
us to make comments. Heck, with this direction, you can blow away the
original tweet in your tweet and insert a full 140-character comment
and with the chain, Twitter can go back to the last tweet in the chain
that isn't linked and we can assume this is the original message and
display the original above the user's tweet in the timeline, in a
similar fashion of how message boards and forums work.
Brian Smith
> Will it be possible to "comment" on the retweeted tweet? If not,
> people might just continue to use the current "RT ..." convention.
>
> Retweeting can be a way of acknowledging a tweet or disapproving a
> tweet etc.
>
> If you search for "RT" in search.twitter.com you'll see a lot of
> commented retweets.
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
Ben Hall
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
stygz
Precisely my thoughts. Just a simple "retweet_of_status_id" field on a
status update will allow users to post their own thoughts (a.k.a.
"keeping the conversation moving") and it would allow client apps to
display/link original message however they like. Then readers have
all the context they need and if they're interested they can view/
interact with the original tweet as they like.
This may seem like a trivial thing to get this excited about, but
twitter is all about the conversation and the power of social media is
the two-way communication. So why would we want a feature that
squelches the conversation and confuses sharing?
Kevin Mesiab
Neil Ellis
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
AlisonW
There are two types of retweet in my experience:
The first is the 'plain' duplication of the original tweet, with just the "RT @scnreename " on the front, and the proposed API additions serve this very well.
But many, indeed I'd argue the majority, of retweets I see are ones where the original message - often a few words and a link - has been commented upon by the retweeter, ie it is *not* a duplication. Sometimes the original is short enough that the commenter can get in with the character limit, sometimes they 'shorten' the original text to get in their comment.
There is far greater "added value" in a retweet when people add their own comment before sending it on its way. Plain re-transmission just fills up the screen.
@AlisonW
stk
1) People may find it confusing to see the original author's name in
their list, as it's not expected. I think it's better to show the
name of the retweeter, rather than the original tweeter (although a
link to the original tweet, in the form of the author's name, would be
fine and expected).
2) A larger issue with the UI will be the ability to have an option to
do one of three things:
a) use the original tweeter's text in it's entirety.
b) not use the original tweeter's text and instead, use the
retweeter's comment - or -
c) a mix of (a) and (b)
Hope this helps.
chenyuejie
I think ReTweet should be public thread chat(like reddit?), while
Reply is private chat(visible to friends)
what do you think?
> > 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
> > 3) Retweeted to me timeline
>
> > 4) My tweets, retweeted
> >http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...
Chris Babcock
Right. And this mechanism will provide a way to differentiate between
plain retweets and value added retweets.
+1 to the API team.
Chris
Beier
Say I follow userA and userB, both Retweeted a tweet from userC, whom
I'm not following. Do I see two tweets from userC from the new home
timeline? If so, then with the implied implementation it would be
confusing to users as the they are seeing the exact same tweet from
the same userC more than once. Image if there are tens of those
retweets that can fill up a whole page, will look like spam. If I only
see one instance of userC's tweet, then who gets the credit of
retweeter? userA or userB?
But overall, I like the idea that Retweet is being recognized
officially by Twitter and actually being tracked as well. It might be
a little bit confusing to users at first, but it shouldn't take them
long to adopt. I think it's better to keep it as simple as possible,
after all it's just retweet. conversations can be tracked by other
means (like @replies), If we mix RT with conversation, then it would
be too complicated for regular users to understand and developers to
present on UI
Naveen Ayyagari
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..
Rich
look for the one extra field and then we can query the other status ID
to find out the originals. This way we have to handle the entire
extra node and user node of the XML/json
Dewald Pretorius
methods.
A new breed of spammy app is going to emerge that leverages
retweeting.
One where users can say, "Search for tweets that contain these
keywords, and automatically retweet them for me on my account."
So, you're going to get Twitter accounts that simply retweet tweets
from others to fill their timelines, or to interleave them with the
remainder of their tweets that all contain affiliate links.
Currently that is not so easy to do, because you have to massage the
tweet text, i.e., insert "RT " and chop some text off if that takes
the length beyond 140 characters, not chop off part of an URL if it's
at the end of the text, etc. With the new methods all that falls away,
because attribution is now given by the "retweeted by" in the source.
No text massaging is required.
How about: "You can only retweet tweets from those you follow." Just a
thought.
Dewald
Dean Collins
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).
Dean Collins
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
Dewald Pretorius
I thought of a potential issue. It is Twitter's decision whether they
also see it as a potential issue and want to do anything about it.
Dewald
On Aug 14, 10:37 am, "Dean Collins" <D...@cognation.net> wrote:
> And as for you comment about them being spammy?
>
> 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
> +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
Dewald Pretorius
Cameron Kaiser
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." --------
Shannon Whitley
tackle this.
Unfortunately, from my view, Project Retweet uses a sledgehammer to
drive a nail. The simplest solution is going to be the best, and I
think the current changes are complicated and confusing.
I agree with some of the other comments; tracking the original tweet
id in a single field would have been sufficient
(retweet_of_status_id).
I like to comment on my retweets. Project Retweet actually increases
the number of tweets that I'll have to post (one to retweet and
another to comment).
Project Retweet encourages thoughtless copies of tweets. While that
happens anyway, there is at least a small barrier today.
It appears that too much work has already gone into this project, so
it looks like we're moving forward. With that in mind, I hope I'll be
proven wrong.
Dale Merritt
Dale Merritt
Fol.la MeDia, LLC
hansamann
assumptions that I would like to see answered. I am working on a
little retweet / relevancy app at http://groovytweets.org, currently
just for the groovy community and I am wondering how the retweet
detection I am doing (with all different formats) will change in
future.
- every tweet will be retweetable using the new API, right? If a tweet
was accepted by twitter, is is 140 chars max and using the api we can
always retweet it. No more chopping of or marking a tweet 'not
retweetable' because it is too long, right?
- to detect a message that has been retweeted, we can just check for
retweet_details in the response. So the question I have (as I am
counting the retweets to bubble up the important stuff as many
here...) is how I detect many retweets. E.g. if a tweet was retweeted
by 2 people, will I see the two original tweets in the home_timeline
and each will have on retweet_details section? Or is there one mesage
with multiple retweet_details sections? If the latter, one tweet with
multiple retweet_details is true, the API has to deliver the tweet
again if new retweets were added, as I am not able to count the total
retweets otherwise... I guess.
- RT @user message will not be converted by twitter to a new 'retweet'
by default, so we will have to support both the old retweet detection
and the new API at the same time. Old clients will stil use the RT
format...
Thanx
Sven
> 3) Retweeted to me timelinehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...
>
Mark Nutter
status update in the twitter system? In other words, if I retweet
your post, and I use the search api and look for tweets posted by me,
will that retweet show up as a search result? Is this new retweet
feature going to kill a good portion of the tweets that you might find
using the search API? I would have to imagine sites like tweetmeme
would be interested to know this. Providing an array of the people
who have retweeted a particular link would be a very handy API call to
have (without requiring user authentication). Do you plan on
including that feature if actual posts aren't being created?
stephane
results to compute some relevancy/popularity scores.
If we consider that those RTs are simple "forwards" or "likes", search
result could simply provide each tweets with its number of RTs (total
number and/or unique RT'ing user number ?) and one could argue that
there is no real need for RT's as entries in the search results.
Another nice effect to this : increasing the twitter search memory by
reducing the amount of tweets to keep in the index.
This is overall a good step, I'd just like to know how disruptive it's
going to be for apps that use twitter search API ...
@sphilipakis
www.twazzup.com
TjL
retweets are one of the biggest useless annoyances on Twitter.)
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
jim.renkel
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.
2. Is there a limit on the number of times a status update can be
retweeted? Again, curiosity, but with implications.
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?
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?
5. In the response to the statuses/home_timeline, statuses/
retweeted_by_me, statuses/retweeted_to_me, and statuses/retweets_of_me
methods, how are multiple retweets of the same status update encoded?
I far as I could see, none of the examples addressed this. Is the
status update repeated once per retweet? Or are multiple retweets
listed under one instance of the status update that was retweeted? In
the latter case, the response would presumably look like:
<?xml version="1.0" encoding="UTF-8"?>
<statuses>
<status>
...
<user>
...
</user>
<retweet_details>
... [details of 1st retweet]
</retweet_details>
<retweet_details>
... [details of 2nd retweet]
</retweet_details>
...
</status>
</statuses>
I could be wrong, but I don't think this is valid XML. I think ya need
to have another level of grouping, as in:
<?xml version="1.0" encoding="UTF-8"?>
<statuses>
<status>
...
<user>
...
</user>
<retweets>
<retweet_details>
... [details of 1st retweet]
</retweet_details>
<retweet_details>
... [details of 2nd retweet]
</retweet_details>
...
</retweets>
</status>
</statuses>
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.
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.
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?
'Nough for now. I'll probably have more as I think this through more.
Comments expected and welcome.
Jim Renkel
> Retweetinghas become one of the cultural conventions of the Twitter
> innovative ways to use the service. We dig it. So soon it's going to
> become a natively supported feature on twitter.com. It's looking like
> we're only weeks away from being ready to launch it on our end. We
> wanted to show the community of platform developers theAPIwe've
> were planning on exposing a way for developers to create a retweet,
> recognize retweets in your timeline and display them distinctively
> amongst other tweets. We've also got APIs for several retweet
> timelines: retweets you've created, retweets the users you're
> following have created, and your tweets that have been retweeted by
> others.
>
> - Creating Retweets
>
> 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 addretweetingsupport
> or create a confusing experience for that app's users. So the
>
> For those who *do* want to support retweets, we are adding a new (more
> aptly named) /statuses/home_timeline resource. This *will* include
> be supported in version 1 of theAPI. In version 2 it will go away and
>
>
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_t...
>
> 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 timelinehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...
>
> 3) Retweeted to me timelinehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...
>
> 4) My tweets, retweetedhttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...
>
> Reminder: Making requests to any of these timelines won't work yet as
> the feature has not launched.
>
> UI considerations:
> ------------------
>
jim.renkel
API, is the promised companion to my post containing practical issues.
I realize this retweeting API and UI are probably a fait a complis
(sp?), modulo addressing practical concerns that I and others have
raised, but I'll throw out my two cents worth anyhow.
In summary, I don't like this proposal very much. As someone else has
pointed out, I think it's akin to driving a tack with a sledge hammer.
I see very little wrong / missing with the current retweeting
conventions, and I think the twitter community would be better served
by addressing these problems / shortcomings that creating something
new out of whole cloth.
My biggest dislike is that there is no capability to add to the
retweet, only exactly duplicate what has already been said. Others
have said more eloquently than I could the value of being able to add
to a retweet, and I fully support pretty much everything that has been
said here.
Ya there's a problem with the length of some retweets that have been
added to, but the solutions already in place seem to be satisfactory.
Was this the real problem that twitter was trying to solve that lead
to this API?
There is value in knowing that a status update is a retweet, but that
could have been much more easily done by adding a new parameter to the
status/create method than creating a whole new method, and reporting
it's value whenever the status update is reported. AND, it could have
been done with 100% backward compatibility, at least as I understand
backward compatibility. The implications of requiring changes to
existing applications are enormous.
Ya there are currently several conventions for indicating a retweet:
RT; [unicode recycle symble]; etc. Again, a new parameter to the
status/create method solves the problem quite simply and elegantly.
AND reduces the problem with the length of retweets.
There is value in knowing who has retweeted a tweet, but there is more
value in knowing who has responded to a status update in any way. That
could have been provided as a status/responses method that I and
others have proposed many times, and would result in more value than
just being able to find out who has retweeted a status update.
I predict, as others have, that "retweebots" will proliferate and
vastly expand and complicate the spam and issues of dealing with it
that are already present.
Applications and sites that already have a retweet capability will
have to change the name of their capability, leading to user
confusion, AND implement this new retweeting scheme, leading to even
more user confusion. If there were simply a new parameter to the
status/create method, I think existing applications and sites would
jump all over it, with very little user confusion.
When I get there, I know that my site, http://twxlate.com, will
definitely implement the existing retweeting conventions (I will have
to come up with some other name for it.) and will probably, but not
certainly, implement the new API if it is really introduced
essentially as it is now. At least I'll be able to do that with less
confusion than if I had already implemented the existing retweeting
conventions.
Again, 'nough for now, but, again, I'll probably come up with more as
I think about this more.
As always, comments expected and welcome.
Jim renkel
Brian Smith
> 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.
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
Marcel Molina
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.
jim.renkel
Good catch on deleting a retweeted tweet! It was on my list of issues,
by I forgot to include it in my post.
Hopefully, the twitter folk will respond to this as fast as they added
retweet_id so ya can delete retweets! :-)
Jim
jim.renkel
Not surprisingly, your answers have raised a couple of more
questions. :-)
1. What happens if I give a retweet id number to the status/show
method? An error? The retweeted status message is returned along with
information about all of its retweets? I'm really hoping for the
second option here, and, if that is not the case currently, I would
encourage twitter to make that enhancement. It seems to me to be
natural to want information on one specific retweet, just as one can
get specific information on one specific status update.
For the next 2 questions, assume A is following B and C, that B has
retweeted a status update say two days ago, and C has retweeted the
same status update yesterday.
2. In the response to a statuses/home_timeline request for user A,
will the retweeted status update and all its retweeting information be
duplicated at the two appropriate places in the timeline, once for B
and once for C? Or will one or the other be elided?
3. If the answer to 2, above, is "the retweeted status update is
duplicated", does the retweeting information reflect the state of the
twitterverse as it exists at the time the request is made or the state
at the time the retweet was created? Specifically, will the retweeting
information for B's retweet show that C has also retweeted it, even
though C hadn't yet retweeted it when B did?
4. Assume count=20 is specified on the statuses/home_timeline request.
Does the retweeted status update and all of its retweets count as just
1 of the 20 status updates in the response (i.e., the response could
have more than 20 elements, potentially way more, but all of the
retweets of a status update would appear in one "page" of the
response)? Or does each retweet count as 1 of the 20 (i.e., the
response will have only 20 elements, but the retweets of a single
status update could be spread across many, potentially very many,
pages)? I think it would have to be the former, as "Clients may [only]
request up to 3,200 statuses via the page and count parameters for
timeline REST API methods." (Quoted from the API documentation under
"6) There are pagination limits".), and if it were the latter ya
couldn't even return all the retweet information for a status update
that was retweeted more than 3200 times (Which DOES happen.).
5. "statuses/home_timeline" is like "statuses/friends_timeline" but
with retweets. There is no method that is like "statuses/
user_timeline" but with retweets. It can be synthesized by merging the
results of statuses/user_timeline and statuses/retweeted_by_me method
requests, but only for the authenticating user: the statuses/
retweeted_by_me method does not take id and user_id parameters as the
statuses/user_timeline method does. I think there's something missing
here: if I can see any users status updates, why can't I see their
retweets?
6. There are no methods like "statuses/mentions" and "favorites" but
including retweets (Or do those methods' results now include
retweets?). I see no way at all of synthesizing these. I think these
need to be provided for completeness.
7. Similarly, I'm guessing that "statuses/friends" and "statuses/
followers" responses don't include retweets (But if a user's last
update was a retweet, what do they report? The last update that wasn't
a retweet?). Again, I don't see a way of synthesizing these, and I
think methods that do include retweets need to be provided for
completeness.
The reason for wanting the completeness is to avoid user confusion.
Users will get used to seeing retweets, when they exist, when the home
timeline is displayed, and assume that if none are displayed, none
exist. I fear that they will then make that same assumption when
mentions, favorites, friends, and followers are displayed: no retweets
displayed, ergo no retweets exist. That may or may not be correct.
'Nough for now.
Comments expected and welcome.
Answers demanded! "-)
Jim Renkel
On Aug 17, 1:56 pm, Marcel Molina <mar...@twitter.com> wrote:
> Thanks for your questions. Responses inline...
>
>
> > 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.
>
> > 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/retweetmethod provides details about
>
> No.
>
>
>
> > 5. In the response to the statuses/home_timeline, statuses/
> > retweeted_by_me, statuses/retweeted_to_me, and statuses/retweets_of_me
> > methods, how are multiple retweets of the same status update encoded?
> > I far as I could see, none of the examples addressed this. Is the
> > ...
> > </retweets>
> > </status>
> > </statuses>
>
> > 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.
> 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,
> > delete aretweetis essential! BTW, I don't see any delete capability
>
> In the absence of an obvious use case for including theretweet'sid,
>
> >> - Consuming Retweets in the Timeline
>
> >> 1) Retweets in the new home timeline
>
> >> We don't want to break existing apps that don't addretweetingsupport
> >> or create a confusing experience for that app's users. So the
> >> /statuses/friends_timelineAPIresource 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_timelineAPIresource will continue to
> >> be supported in version 1 of theAPI. In version 2 it will go away and
> >> be fully replaced by /statuses/home_timeline.
>
> >> TheAPIdocumentation for the home timeline, which includes retweets,
> >> can be found here:
>
> >>http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_t...
>
> >> 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
> >> 2) Retweeted by me timelinehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...
>
> >> 3) Retweeted to me timelinehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...
>
> >> 4) My tweets, retweetedhttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...
>
> >> Reminder: Making requests to any of these timelines won't work yet as
> >> the feature has not launched.
>
> >> UI considerations:
> >> ------------------
>
> >> Here are someearlydraft 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 toretweetit. If other's subsequentlyretweetthe same
> >> That's it for now.
>
> >> We'll be sending out more updates as we get closer to launching.
>
> >> --
> >> Marcel Molina
> >> Twitter Platform Teamhttp://twitter.com/noradio
>
> --
>
> read more »
jim.renkel
designing the code that I will use with my site (http://twxlate.com).
The statuses/retweeted_by_me method complements the statuses/
user_timeline method: user_timeline "Returns the 20 most recent
statuses posted from the authenticating user."; retweeted_by_me
"Returns the 20 most recent retweets posted by the authenticating
user.". However, with the user_time method, "It's also possible to
request another user's timeline via the id parameter.". The
retweeted_by_me method does not have this option, and I think it
should. Can this be added?
I think maybe the statuses/retweets_of_me method should also have an
optional id parameter, but I could be wrong about this.
The statuses/retweeted_to_me method also does not have an optional id
parameter, but the absence here is, I think, correct.
Comments expected and welcome.
Jim
> Marcel: thank you for the quick response to my questions.
>
> Not surprisingly, your answers have raised a couple of more
> questions. :-)
>
> information about all of its retweets? I'm really hoping for the
> second option here, and, if that is not the case currently, I would
> encourage twitter to make that enhancement. It seems to me to be
>
> For the next 2 questions, assume A is following B and C, that B has
> retweeted a status update say two days ago, and C has retweeted the
> same status update yesterday.
>
> 2. In the response to a statuses/home_timeline request for user A,
> will the retweeted status update and all its retweeting information be
> duplicated at the two appropriate places in the timeline, once for B
> and once for C? Or will one or the other be elided?
>
> 3. If the answer to 2, above, is "the retweeted status update is
> duplicated", does the retweeting information reflect the state of the
> twitterverse as it exists at the time the request is made or the state
> information for B'sretweetshow that C has also retweeted it, even
>
> 4. Assume count=20 is specified on the statuses/home_timeline request.
> Does the retweeted status update and all of its retweets count as just
> 1 of the 20 status updates in the response (i.e., the response could
> have more than 20 elements, potentially way more, but all of the
> retweets of a status update would appear in one "page" of the
> status update could be spread across many, potentially very many,
> pages)? I think it would have to be the former, as "Clients may [only]
> request up to 3,200 statuses via the page and count parameters for
>
> 5. "statuses/home_timeline" is like "statuses/friends_timeline" but
> with retweets. There is no method that is like "statuses/
> user_timeline" but with retweets. It can be synthesized by merging the
> results of statuses/user_timeline and statuses/retweeted_by_me method
> requests, but only for the authenticating user: the statuses/
> retweeted_by_me method does not take id and user_id parameters as the
> statuses/user_timeline method does. I think there's something missing
> here: if I can see any users status updates, why can't I see their
> retweets?
>
> 6. There are no methods like "statuses/mentions" and "favorites" but
> including retweets (Or do those methods' results now include
> retweets?). I see no way at all of synthesizing these. I think these
> need to be provided for completeness.
>
> 7. Similarly, I'm guessing that "statuses/friends" and "statuses/
> followers" responses don't include retweets (But if a user's last
> aretweet?). Again, I don't see a way of synthesizing these, and I
>
> read more »
twittelator
percolated up:
1. twitter as a phenomena has been driven bottom up by the users
2. forcing new paradigms on our users will result in general
unhappiness
3. presenting new paradigms as options to our users will allow happy
migration
Therefore, May I present to you, VART's : Value Added ReTweets.
OK that's a stinky name but I see the value of allowing users to do
the instant, no-thought-required new-style RT as well as the old-
fashioned edit, trim, comment and send. I think it will take a while
for users to grok that the auto retweet method preserves authorship,
and a good UI will tag it as such and allow the value of the new api
to be perceived.
Maybe an additional parameter to statuses/update that this is indeed
what's going on?
@twittelator / http://stone.com
On Aug 13, 2:52 pm, Marcel Molina <mar...@twitter.com> wrote:
> Retweeting has become one of the cultural conventions of the Twitter
> innovative ways to use the service. We dig it. So soon it's going to
> become a natively supported feature on twitter.com. It's looking like
> we're only weeks away from being ready to launch it on our end. We
> were planning on exposing a way for developers to create a retweet,
> recognize retweets in your timeline and display them distinctively
> amongst other tweets. We've also got APIs for several retweet
> timelines: retweets you've created, retweets the users you're
> following have created, and your tweets that have been retweeted by
> others.
>
> - Creating Retweets
>
>
> 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.
>
>
> 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
>
> For those who *do* want to support retweets, we are adding a new (more
> aptly named) /statuses/home_timeline resource. This *will* include
> be supported in version 1 of the API. In version 2 it will go away and
>
>
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_t...
>
> 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
> 2) Retweeted by me timelinehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...
>
> 3) Retweeted to me timelinehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...
>
> 4) My tweets, retweetedhttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...
>
> Reminder: Making requests to any of these timelines won't work yet as
> the feature has not launched.
>
> UI considerations:
> ------------------
>
> 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