[twitter-dev] Re: Purposed method: friendships/show
Hey Chad, thanks for your feedback.
Thought experiment: Put aside the currently proposed response body for
the moment. How would you unambiguously express the following/followed
by relationship?
Marcel Molina
Twitter API Team
http://twitter.com/@noradio
On Jun 9, 10:23 am, Chad Etzel wrote:
> Thanks for adding the extra verbiage.
>
> However, I'm still not clear how to decipher the exact relationship
> given the data. In the example, is Bob following Jack? ...or is Jack
> following Bob?
>
> -Chad
>
>
>
> On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams wrote:
> > Thanks, Chad. I've augmented the usage notes section to explain the
> > rationale behind the denormalized and redundant data.
> > Thanks,
> > Doug
>
> > On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel wrote:
>
> >> Taking a look at the json return example:
> >> {"relationship": {
> >> "source": {
> >> "id": 123,
> >> "screen_name": "bob",
> >> "following": true,
> >> "followed_by": false,
> >> "notifications": false },
>
> >> "target": {
> >> "id": 456,
> >> "screen_name": "jack",
> >> "following": false,
> >> "followed_by": true,
> >> "notifications": null }
> >> }
> >> }
>
> >> In the "source" object (i.e. for "bob"), "following" is true. Does
> >> this mean that Bob is following Jack, or vice-versa?
>
> >> Knowing that, the other 3 following/followed_by value meanings can be
> >> properly inferred. Some clarification on the page would help.
>
> >> -Chad
>
> >> On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams wrote:
> >> > That makes things difficult. Permissions are now public.
> >> > Thanks,
> >> > Doug
>
> >> > On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel wrote:
>
> >> >>
> >> >> Access Denied
>
> >> >> You don't have permission to look at Twitter REST API Method:
> >> >> friendships
> >> >> show.
> >> >>
>
> >> >> :)
> >> >> -Chad
>
> >> >> On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams
> >> >> wrote:
> >> >> > We discussed the need to deprecate the and
> >> >> >
> >> >> > elements [1] a few weeks back. We have begun work on the
> >> >> > friendships/show
> >> >> > method as mentioned in the notice. The method is slightly out of our
> >> >> > conventional design, so we are soliciting opinions on its fitness for
> >> >> > general use-cases. Please peruse the purposed method's documentation
> >> >> > [2]
> >> >> > and
> >> >> > let us know what you think.
>
> >> >> > 1. http://groups.google.com/group/twitter-development-talk/browse_frm/th...
>
> >> >> > 2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
> >> >> > Thanks,
> >> >> > Doug
[twitter-dev] Re: Purposed method: friendships/show
Thanks for the suggestion Chad.
What do others think of
{"relationship": {
"source": {
"id": 123,
"screen_name": "bob",
"notifications": false },
"target": {
"id": 456,
"screen_name": "jack",
"notifications": null },
"source_follows_target": true,
"source_followed_by_target": false
}
}
versus
{"relationship": {
"source": {
"id": 123,
"screen_name": "bob",
"following": true,
"followed_by": false,
"notifications_enabled": false },
"target": {
"id": 456,
"screen_name": "jack",
"following": false,
"followed_by": true,
"notifications_enabled": null }
}
}
On Tue, Jun 9, 2009 at 10:41 AM, Chad Etzel wrote:
>
> Hi Marcel,
>
> Welcome to Twitter, btw (if I'm allowed to say that).
>
> One unambiguous way might be:
>
> {"relationship": {
> "source": {
>"id": 123,
>"screen_name": "bob",
> "notifications": false },
>
> "target": {
>"id": 456,
>"screen_name": "jack",
> "notifications": null },
>
> "source_follows_target": true,
> "source_followed_by_target": false
> }
> }
>
> This also eliminates redundant data.
>
> Btw, http://twitter.com/@noradio doesn't quite work as a link :)
>
> -Chad
>
> On Tue, Jun 9, 2009 at 1:33 PM, Marcel Molina wrote:
> >
> > Hey Chad, thanks for your feedback.
> >
> > Thought experiment: Put aside the currently proposed response body for
> > the moment. How would you unambiguously express the following/followed
> > by relationship?
> >
> > Marcel Molina
> > Twitter API Team
> > http://twitter.com/@noradio
> >
> > On Jun 9, 10:23 am, Chad Etzel wrote:
> >> Thanks for adding the extra verbiage.
> >>
> >> However, I'm still not clear how to decipher the exact relationship
> >> given the data. In the example, is Bob following Jack? ...or is Jack
> >> following Bob?
> >>
> >> -Chad
> >>
> >>
> >>
> >> On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams wrote:
> >> > Thanks, Chad. I've augmented the usage notes section to explain the
> >> > rationale behind the denormalized and redundant data.
> >> > Thanks,
> >> > Doug
> >>
> >> > On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel
> wrote:
> >>
> >> >> Taking a look at the json return example:
> >> >> {"relationship": {
> >> >> "source": {
> >> >> "id": 123,
> >> >> "screen_name": "bob",
> >> >> "following": true,
> >> >> "followed_by": false,
> >> >> "notifications": false },
> >>
> >> >> "target": {
> >> >> "id": 456,
> >> >> "screen_name": "jack",
> >> >> "following": false,
> >> >> "followed_by": true,
> >> >> "notifications": null }
> >> >> }
> >> >> }
> >>
> >> >> In the "source" object (i.e. for "bob"), "following" is true. Does
> >> >> this mean that Bob is following Jack, or vice-versa?
> >>
> >> >> Knowing that, the other 3 following/followed_by value meanings can be
> >> >> properly inferred. Some clarification on the page would help.
> >>
> >> >> -Chad
> >>
> >> >> On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams
> wrote:
> >> >> > That makes things difficult. Permissions are now public.
> >> >> > Thanks,
> >> >> > Doug
> >>
> >> >> > On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel
> wrote:
> >>
> >> >> >>
> >> >> >> Access Denied
> >>
> >> >> >> You don't have permission to look at Twitter REST API Method:
> >> >> >> friendships
> >> >> >> show.
> >> >> >>
> >>
> >> >> >> :)
> >> >> >> -Chad
> >>
> >> >> >> On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams
> >> >> >> wrote:
> >> >> >> > We discussed the need to deprecate the and
> >> >> >> >
> >> >> >> > elements [1] a few weeks back. We have begun work on the
> >> >> >> > friendships/show
> >> >> >> > method as mentioned in the notice. The method is slightly out of
> our
> >> >> >> > conventional design, so we are soliciting opinions on its
> fitness for
> >> >> >> > general use-cases. Please peruse the purposed method's
> documentation
> >> >> >> > [2]
> >> >> >> > and
> >> >> >> > let us know what you think.
> >>
> >> >> >> > 1.
> http://groups.google.com/group/twitter-development-talk/browse_frm/th...
> >>
> >> >> >> > 2.
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
> >> >> >> > Thanks,
> >> >> >> > Doug
> >
>
--
Marcel Molina
Twitter API Team
http://twitter.com/noradio
[twitter-dev] Re: Purposed method: friendships/show
Good point about pending requests for protected accounts and the opportunity
to get parity.
My inclination is rather than overloading following and followed_by that we
potentially introduce a 'pending' attribute that is either true or empty.
Similarly we could add a 'blocked'/'blocked_by'.
These additional attributes sway me toward going with the
representation that (redundantly) specifies the values of each
attribute with the source and target sections as encoding this
information in 'source_has_a_pending_request_for_target' and
'target_has_a_pending_request_for_source', etc start to get somewhat
unwieldy.
On Tue, Jun 9, 2009 at 4:29 PM, jim.renkel wrote:
>
> It seems from the examples, but not explicitly stated anywhere, that
> the values of the following and followed_by items are booleans,
> implying that a user either is or is not following another user.
>
> While at first blush that seems true, I think in reality the situation
> is a little more complicated, especially if you consider protected
> users.
>
> I would propose that these items be enumerations, with the following
> values and meanings:
> - "yes": user A, say, is following user B;
> - "no": user A is not following user B, has not requested the
> relationship, and is not blocked from doing so;
> - "pending": user A has requested to follow (protected) user B, but B
> has not yet accepted, rejected, or blocked the request; and
> - "blocked": user A requested to follow (protected) user B, but B
> blocked the request.
>
> What I'm looking for here is parity, if you will, between the data and
> facilities that are available to the twitter.com web site and to API
> users. This is one place where there was not parity, and we have the
> opportunity to now get it.
>
> Comments expected, welcome, and appreciated.
>
> Jim Renkel
>
> On Jun 9, 1:13 pm, Damon Clinkscales wrote:
> > If you're going to redefine the way that follow information is
> > returned, I believe that it should include the effect of "protected"
> > accounts on both sides of the follow equation.
> >
> > Thanks,
> > -damon
> > --http://twitter.com/damon
> >
> > On Tue, Jun 9, 2009 at 10:52 AM, Marcel Molina
> wrote:
> > > Thanks for the suggestion Chad.
> > > What do others think of
> > > {"relationship": {
> > > "source": {
> > >"id": 123,
> > >"screen_name": "bob",
> > >"notifications": false },
> >
> > > "target": {
> > >"id": 456,
> > >"screen_name": "jack",
> > >"notifications": null },
> >
> > > "source_follows_target": true,
> > > "source_followed_by_target": false
> > > }
> > > }
> > > versus
> >
> > > {"relationship": {
> >
> > > "source": {
> >
> > > "id": 123,
> >
> > > "screen_name": "bob",
> >
> > > "following": true,
> >
> > > "followed_by": false,
> >
> > > "notifications_enabled": false },
> >
> > > "target": {
> >
> > > "id": 456,
> >
> > > "screen_name": "jack",
> >
> > > "following": false,
> >
> > > "followed_by": true,
> >
> > > "notifications_enabled": null }
> >
> > > }
> >
> > > }
>
--
Marcel Molina
Twitter API Team
http://twitter.com/noradio
[twitter-dev] Re: Purposed method: friendships/show
Though, it should be mentioned, w/r/t/ to pending follow requests and
blocks, you'd only get a value for those attributes for authenticated
requests where the source user is authenticated.
On Tue, Jun 9, 2009 at 5:22 PM, Marcel Molina wrote:
> Good point about pending requests for protected accounts and the
> opportunity to get parity.
> My inclination is rather than overloading following and followed_by that we
> potentially introduce a 'pending' attribute that is either true or empty.
> Similarly we could add a 'blocked'/'blocked_by'.
>
> These additional attributes sway me toward going with the
> representation that (redundantly) specifies the values of each attribute with
> the source and target sections as encoding this information in
> 'source_has_a_pending_request_for_target' and
> 'target_has_a_pending_request_for_source', etc start to get somewhat unwieldy.
>
>
> On Tue, Jun 9, 2009 at 4:29 PM, jim.renkel wrote:
>
>>
>> It seems from the examples, but not explicitly stated anywhere, that
>> the values of the following and followed_by items are booleans,
>> implying that a user either is or is not following another user.
>>
>> While at first blush that seems true, I think in reality the situation
>> is a little more complicated, especially if you consider protected
>> users.
>>
>> I would propose that these items be enumerations, with the following
>> values and meanings:
>> - "yes": user A, say, is following user B;
>> - "no": user A is not following user B, has not requested the
>> relationship, and is not blocked from doing so;
>> - "pending": user A has requested to follow (protected) user B, but B
>> has not yet accepted, rejected, or blocked the request; and
>> - "blocked": user A requested to follow (protected) user B, but B
>> blocked the request.
>>
>> What I'm looking for here is parity, if you will, between the data and
>> facilities that are available to the twitter.com web site and to API
>> users. This is one place where there was not parity, and we have the
>> opportunity to now get it.
>>
>> Comments expected, welcome, and appreciated.
>>
>> Jim Renkel
>>
>> On Jun 9, 1:13 pm, Damon Clinkscales wrote:
>> > If you're going to redefine the way that follow information is
>> > returned, I believe that it should include the effect of "protected"
>> > accounts on both sides of the follow equation.
>> >
>> > Thanks,
>> > -damon
>> > --http://twitter.com/damon
>> >
>> > On Tue, Jun 9, 2009 at 10:52 AM, Marcel Molina
>> wrote:
>> > > Thanks for the suggestion Chad.
>> > > What do others think of
>> > > {"relationship": {
>> > > "source": {
>> > >"id": 123,
>> > >"screen_name": "bob",
>> > >"notifications": false },
>> >
>> > > "target": {
>> > >"id": 456,
>> > >"screen_name": "jack",
>> > >"notifications": null },
>> >
>> > > "source_follows_target": true,
>> > > "source_followed_by_target": false
>> > > }
>> > > }
>> > > versus
>> >
>> > > {"relationship": {
>> >
>> > > "source": {
>> >
>> > > "id": 123,
>> >
>> > > "screen_name": "bob",
>> >
>> > > "following": true,
>> >
>> > > "followed_by": false,
>> >
>> > > "notifications_enabled": false },
>> >
>> > > "target": {
>> >
>> > > "id": 456,
>> >
>> > > "screen_name": "jack",
>> >
>> > > "following": false,
>> >
>> > > "followed_by": true,
>> >
>> > > "notifications_enabled": null }
>> >
>> > > }
>> >
>> > > }
>>
>
>
>
> --
> Marcel Molina
> Twitter API Team
> http://twitter.com/noradio
>
--
Marcel Molina
Twitter API Team
http://twitter.com/noradio
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
gt; > On Jul 28, 11:40 am, Zaudio wrote: >> > > > I don't myself think that twitter are doing anything more than >> > > > enforcing the standard. I spent 3 hours 'fixing' my code for our >> > > > application (uses Shannon Whitley's c# library as a base); I only >> > > > found two bugs in thelibrary that caused any problem... the use of >> > > > httputility.urlencode in place of the modified urlencode already >> > > > implemented for use with Oauth, as required by the spec... the >> library >> > > > just wasn't using it in two places. >> > >> > -- >> > Cristovao Morgado >> > aka Saintrhttp://www.oMeuJogoUsado.comhttp://www.TweetaPorSMS.comhttp:// >> twitter.com/TheSaintr >> > > > > -- > Abraham Williams | Community Evangelist | http://web608.org > Hacker | http://abrah.am | http://twitter.com/abraham > Project | http://fireeagle.labs.poseurtech.com > This email is: [ ] blogable [x] ask first [ ] private. > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Help signing OAuth requests
For those who might be struggling to ensure their OAuth signatures are being generated correctly, this guide provides more hand holding with the process than the specification. It includes custom forms where you can fill out all the details of your request and see what the signature and its related data *should* be. http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Twitpocalypse: The Second Coming is on the horizon
Twitter status ids are fast approaching the maximum 32-bit *unsigned* integer value (4,294,967,295). The current estimate is that this will occur in approximately 60 days, at the end of September. The 60 day window is a best-guess approximation based on projections. It could conceivably happen sooner. Developers are encouraged to not only update their applications to use a 64-bit integer (BIGINT/long long), but also verify that all libraries they use are also prepared to handle 64-bit integers. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Early developer preview: Retweeting API
Retweeting has become one of the cultural conventions of the Twitter 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
[twitter-dev] Re: Early developer preview: Retweeting API
;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. > > On Aug 13, 3:52 pm, Marcel Molina wrote: >> Retweetinghas become one of the cultural conventions of the Twitter >> 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 theAPIwe've >> cooked up forretweetingso 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 >> >> TheAPIdocumentation 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 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 >> 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: >> -- >> >> 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 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 Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Retweet API addition: retweet_id
We've added a retweet_id to the retweet_details section to allow for, e.g. deletion of retweets. The retweet_id can be provided as an argument to statuses/destroy. The example payloads have been updated to include retweet_id. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Join us in the #twitterapi IRC channel on freenode
We've heard your requests for greater transparency and more frequent communication in the last couple weeks around the fall out from the DDoS attacks. The Twitter Development Talk mailing list and @twitterapi account have gone a long way to keeping the conversation flowing. We want to facilitate even more modes of communication though. So we've opened up the #twitterapi IRC channel on irc.freenode.net. We hope to be able to provide some real-time support when things go awry. Unfortunately, we can't provide 24/7 support via IRC, but we'll try to be around during deploys, unexpected outages, and special events. We also envision it as a place for developers to help each other. So, if you're into IRC, we encourage you to come on over. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Join us in the #twitterapi IRC channel on freenode
The channel had been set to +r which requires users to be registered with the NickServ to join the channel. That restriction has been lifted so things should be fine now (and since you just joined the channel I'm assuming it works). On Tue, Aug 18, 2009 at 4:29 PM, Dewald Pretorius wrote: > > Marcel, > > I can't join #twitterapi on irc.freenode.net. Colloquy-mobile just > throws a deaf ear, i.e., nothing happens. I can join other chat rooms > no problem. > > I'm not very familiar with IRC, so I might be making a rookie mistake. > > Dewald > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] [ANN] statuses/home_timeline resource now available (though it doesn't include retweets yet)
We mentioned in our early preview email about the retweet API (http://groups.google.com/group/twitter-api-announce/browse_thread/thread/1e07e332ec3d449d) that the statuses/friends_timeline resource wasn't going to include retweets for backwards compatibility so we don't break clients that aren't planning to add retweet support. The upgrade path is entirely opt-in. To that end we're adding a statuses/home_timeline resource that is in all ways identical to statuses/friends_timeline except the home_timeline resource *will* include retweets as demonstrated in the example payload in the documentation at http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_timeline. The statuses/home_timeline resource is now available though it won't include any retweets until the retweeting feature is fully launched. To be clear, until the full retweet launch, statuses/home_timeline will be 100% identical to statuses/friends_timeline and will *not* include retweets. We wanted to make the resource available early though so that clients who will be incorporating retweets into their timelines can update the resource that they reference and have requests succeed. When the full retweet launch happens, retweets will start to appear in statuses/home_timeline as per the documentation. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Retweet API and multiple retweets in timeline
If you take a look at the payload of a retweet in the examples, each retweet has the id of the original tweet as well as details about the retweet (who retweeted it, when and what the id of the retweet is). That information, specifically the retweet's id, should be sufficient for your purposes. On Wed, Sep 2, 2009 at 2:58 PM, hansamann wrote: > > Hi all, > > this questions might have been asked already, but a quick search in > this mailing list did not lead me to a clear response... so I > apologize if this topic was discussed in detail already. > > My question: > > - if a tweet is retweeted several timese, e.g. tweet X is retweeted by > my friend A and my friend B, it is likely these retweets are not > taking place the same time. > > - my assumption and question is if the 2 retweets in this case show up > as two tweets in the home timeline. What troubles me is how I can > detect that a tweet was retweeted. I intend to save the last pulled > statusId and then just pull tweets from the home_timeline from the > last statusId. I hope to get the 'new retweets' as they happen as new > people are retweeting. If the api will aggregate the retweets under > the stausId of the original message, I will not be updated of new > retweets in this case. On the other side, if a new retweet will add > the original status a second time (possibly with the new total > retweets, e.g. several retweet_details) then I track the retweet > count. > > What do you think? > > Cheers > Sven > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: [ANN] statuses/home_timeline resource now available (though it doesn't include retweets yet)
The current friends_timeline and home_timeline both include mentions already. The friends_timeline will continue to not include retweets since the payload for a retweeted status is slightly different. At some future time, though, the friends_timeline will be removed in favor of the home_timeline, which will include retweets. Having both parallel timelines, with one that does not include retweets is just a stop gap measure to ease the upgrade path. On Wed, Sep 2, 2009 at 4:56 PM, TjL wrote: > > from the API page > >> Twitter REST API Method: statuses/home_timeline [COMING SOON] >> Returns the 20 most recent statuses, including retweets, posted by the >> authenticating user and that user's friends. This is the equivalent of >> /timeline/home on the Web. >> >> Usage note: This home_timeline is identical to statuses/friends_timeline >> except it also contains retweets, which statuses/friends_timeline does not >> (for backwards compatibility reasons). In a future version of the API, >> statuses/friends_timeline will go away and be replaced by home_timeline. >> > > Does this mean that "in a future version of the API" there won't be > any way to get a friends timeline without retweets? > > Because the ability to ignore retweets ought to be a Day 1 feature, IMO. > > I would put a much higher value on a unified feed which includes > "*mentions* and friends" than "*retweets* and friends" > > FWIW > > TjL > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: [ANN] statuses/home_timeline resource now available (though it doesn't include retweets yet)
The friends_timeline will likely be around for an amount of time on the scale of months, rather than weeks. On Thu, Sep 3, 2009 at 3:03 AM, Rich wrote: > > Any idea how long the friends_timeline will be available for, > obviously there might be some considerable development time assocated > with switching (and in the case of iPhone applications getting Apple > to review the whole process too!) > > On Sep 3, 1:19 am, Marcel Molina wrote: >> The current friends_timeline and home_timeline both include mentions >> already. The friends_timeline will continue to not include retweets >> since the payload for a retweeted status is slightly different. At >> some future time, though, the friends_timeline will be removed in >> favor of the home_timeline, which will include retweets. Having both >> parallel timelines, with one that does not include retweets is just a >> stop gap measure to ease the upgrade path. >> >> >> >> On Wed, Sep 2, 2009 at 4:56 PM, TjL wrote: >> >> > from the API page >> >> >> Twitter REST API Method: statuses/home_timeline [COMING SOON] >> >> Returns the 20 most recent statuses, including retweets, posted by the >> >> authenticating user and that user's friends. This is the equivalent of >> >> /timeline/home on the Web. >> >> >> Usage note: This home_timeline is identical to statuses/friends_timeline >> >> except it also contains retweets, which statuses/friends_timeline does >> >> not (for backwards compatibility reasons). In a future version of the >> >> API, statuses/friends_timeline will go away and be replaced by >> >> home_timeline. >> >> > Does this mean that "in a future version of the API" there won't be >> > any way to get a friends timeline without retweets? >> >> > Because the ability to ignore retweets ought to be a Day 1 feature, IMO. >> >> > I would put a much higher value on a unified feed which includes >> > "*mentions* and friends" than "*retweets* and friends" >> >> > FWIW >> >> > TjL >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Draft: Twitter Rules for API Use
To accompany our updated Terms of Service (http://bit.ly/2ZXsyW) we've posted a draft of the Twitter API rules at http://twitter.com/apirules. As the subject states, these rules are a work in progress and feedback is welcome. Please read the TOS announcement at http://bit.ly/2ZXsyW for some background. We encourage you to use the "contact us" link at http://twitter.com/apirules with any feedback you may have. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Update on the Retweet API (we collapse retweets, not you & we're adding statuses/retweets)
The Retweet API launch is close at hand. You might have already seen some retweets appearing in the new statuses/home_timeline from people who've been testing them out. We've gotten lots of great questions and feedback about the retweet API. Thanks to everyone who has rolled up their sleeves and gotten involved. It's been a big help. 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
[twitter-dev] Re: Deleting a Retweeted Tweet
If the original retweet is deleted its retweets will also disappear. On Sun, Sep 20, 2009 at 3:56 PM, Dewald Pretorius wrote: > > With the new retweeting, what happens with retweets if the original > tweet is deleted, or the author's account is closed or suspended? > > Do all the retweets of that tweet also just disappear with it? > > Dewald > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Updates to the retweet API payload
We've updated the retweet payload to look a lot more like a regular tweet's payload. We find this change makes the retweet API conceptually simpler, easier and more convenient to work with and better overall. I've linked to examples of the new payload below, and will be updating documentation shortly, but first I'd like to share some background on what we've learned working on the retweet API over the past few weeks. One of the big objectives of the retweet feature is discovering new users to follow. We wanted the original status and its author highlighted front and center so they get due credit for the tweet someone you follow found worthy of retweeting. To that end the API was designed to emphasize the original tweet by having it be the top level object. Embedded within it we provided details about who retweeted it and when. Though this makes a statement to how we'd like the feature to be thought about, logistically it doesn't degrade gracefully for clients who don't implement any retweet logic in their code. Tweets appear in timelines from people who you do not follow and unless clients differentiate those tweets visually letting you know that someone you follow has shared this tweet, confusion ensues. To mitigate this, we opted to not include retweets into the existing friends timeline. Instead we created a new parallel home timeline that would be just like the friends timeline but included retweets. That way developers could opt in to the retweet feature at their leisure. Even with this opt in policy, though, there is still a critical responsibility imposed on developers to clearly communicate to their users that a given tweet in their timeline is a retweet and who the retweet is from. The likelihood that confusion would result turned out to be too high. Additionally, with the original status as the top level object in the payload, that means consumers of the API would receive what appears to be the same tweet multiple times. In a lot of cases that's fine, in others it's problematic. After experimenting with this approach we've decided that it's a better bet to craft a payload that will degrade far more gracefully. So we've redesigned the retweet payload. Rather than having the original tweet as the top level status with embedded details about who retweeted it, the retweet is the top level object and within it we include the original tweet and its author. You'll have full access to the entire retweeted status and user as well as the original tweet and its user. So you don't have to make any additional API calls and should have everything you need to display a retweet distinctively with attribute to both the original author and the retweeter. In other words, these retweeted statuses look a whole lot like regular statuses. This new design was our instinct to begin with and we probably should have gone with it. We think it's better and hope you do too. All the same documented resources will exist. Only the payloads change. The following timeline should contain examples of the updated retweet payload. You can use this to test consuming retweets. curl http://twitter.com/statuses/user_timeline/testiverse.xml curl http://twitter.com/statuses/user_timeline/testiverse.json In the event that new tweets go into the above timeline that push the retweets out, you can access a few directly at the following urls: curl http://twitter.com/statuses/show/4452134416.xml curl http://twitter.com/statuses/show/4452466408.xml curl http://twitter.com/statuses/show/4349744308.xml The above payloads don't contain a "retweet_count" element yet and they probably will. Other than that we don't suspect any more major changes as we approach a full public launch. As always, though, we're open and solicitous of everyone's feedback. Thanks. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] New Twitter feature & API coming soon: Lists
Over on the main Twitter blog @nk has written about a new Lists feature we're getting ready to launch: http://blog.twitter.com/2009/09/soon-to-launch-lists.html. We just wanted to let API developers know that we'll be shipping an API for it on day one. You'll be able to do things like create lists, add and remove users from lists, find out who has been added to a list and read the tweet timeline for a given list. Stay tuned for documentations on the full Lists API soon. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Multiple language support for your Twitter application
Over on the main Twitter blog we've just announced that we'll be translating the site into French, Italian, Spanish and German soon, with more languages to come later (http://bit.ly/LIa4C). We figured a lot of folks building apps on the Twitter Platform might be interested in providing their applications in various languages too but haven't had the time or resources to take on building up full translations. So we are planning to provide our translation files to the developer community. We hope they're useful as at least a starting point for your own. We're just getting started. We'll follow up with more details about where you'll be able to get these translations soon. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] New spam reporting API now available
On the heels of adding a "Report as spam" button to twitter.com (http://blog.twitter.com/2009/10/help-us-nail-spammers.html), you can now also simultaneously block and report a user as a spammer via the API. The documentation for the report_spam resource can be found here: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-report_spam As the original announcement mentions, it's important to realize no automated action will be taken as a result of a spam report being created. So don't expect an account to be suspended immediately (or at all). Also you can only create one spam report for a given user, so subsequent requests will have no result. Thanks. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Seeing retweeted_details for user_timeline payload
Having retweets in the user_timeline isn't intentional. I'll be ensuring they don't appear there in the next few days. The only place they should be appearing (once publicly available) is the home_timeline. On Wed, Oct 14, 2009 at 7:45 PM, Martin wrote: > > I'm retrieving the timeline for a specific user: > > curl http://www.twitter.com/statuses/user_timeline/ev.xml > > Within that timeline, I see retweeted_status fragment. > Is this normal behavior ? > > Thanks - Martin > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Seeing retweeted_details for user_timeline payload
Updating the retweet doc payloads is on my todo list. It's unfortunately currently a tedious and onerous task. I've been using my cycles on other things. But it's on the list to do. On Thu, Oct 15, 2009 at 1:53 PM, Josh Roesslein wrote: > > The API doc on the wiki is not correct. There was an email sent out > earlier about the new payload > format. > > Could someone update the wiki for the new payload? > > Josh > > On Thu, Oct 15, 2009 at 3:48 PM, Rich wrote: >> >> Hmm except this API payload doesn't match that for the home_timeline >> >> Hometimeline shows retweet_status with a sub tag of retweeting_user, >> but yet @ev's user timeline shows a tag of retweet_status with a >> subtag of user. >> >> I want to support it but not with the inconsistency in the API >> >> On Oct 15, 5:18 pm, Martin wrote: >>> I have no problem with this new API call. But why is it also included >>> in the user_timeline payload ? >>> Is this inclusion official on the Twitter side... >>> >>> Martin >>> >>> On Oct 15, 9:46 am, ryan alford wrote: >>> >>> >>> >>> >http://apiwiki.twitter.com/Twitter-REST-API-Method:-statuses-home_tim... >>> > <http://apiwiki.twitter.com/Twitter-REST-API-Method:-statuses-home_tim...>That >>> > will be the new "Friends Timeline". It will include retweets, while the >>> > current "Friends Timeline" will not. The current "Friends Timeline" will >>> > also be going away at some point in the future. >>> >>> > Ryan >>> >>> > On Thu, Oct 15, 2009 at 8:53 AM, Martin wrote: >>> >>> > > Thanks for the clarification. >>> >>> > > That explains the inconsistent behavior we are seeing when trying to >>> > > load specific user timelines. >>> > > Do we have an updated api wiki that defines the semantics of the >>> > > fragment ? >>> >>> > > Martin >>> > >www.wherecloud.com >>> >>> > > On Oct 14, 10:59 pm, Josh Roesslein wrote: >>> > > > I think its been enabled for a select few for testing. I don't think >>> > > > its gone public yet. >>> >>> > > > On Wed, Oct 14, 2009 at 9:56 PM, ryan alford >>> > > wrote: >>> > > > > Maybe the new retweet functionality has been turned on? >>> > > > > Ryan >>> >>> > > > > On Wed, Oct 14, 2009 at 10:45 PM, Martin >>> > > wrote: >>> >>> > > > >> I'm retrieving the timeline for a specific user: >>> >>> > > > >> curlhttp://www.twitter.com/statuses/user_timeline/ev.xml >>> >>> > > > >> Within that timeline, I see retweeted_status fragment. >>> > > > >> Is this normal behavior ? >>> >>> > > > >> Thanks - Martin >>> >>> > > > -- >>> > > > Josh > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Lists API
We are rolling it out to a small set of users incrementally so that we can load test and find bugs. We've been working on the API documentation and will be rolling it out gradually. On Thu, Oct 15, 2009 at 4:10 PM, Eric Woodward wrote: > > So, what is the plan for releasing the Lists API, if there is one? It > is well known that selected people have access to them while the rest > of us do not, which is creating a problem with users. Is there a plan > to release these APIs to everyone soon? > > Please respond. I am only asking. > > --ejw > > Eric Woodward > Email: e...@nambu.com > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Draft of List API documentation
Hey folks. As some of you have likely read we're starting to do some private beta testing of our new lists feature. We're not quite ready to open it up to everyone but we've made some headway on the API and wanted to share some details of what we've got so far. There are a handful of things on our todo lists so don't consider this signed and sealed just yet. You may notice this API is a bit of a departure from the rest of the API. It's a bit more, errr, REST than the rest. First off, here's the current payload for a list: 1416 tall people @noradio/tall-people tall-people 0 3 /noradio/tall-people public 3191321 Marcel Molina noradio San Francisco, CA Engineer at Twitter on the @twitterapi team, obsessed with rock climbing & running. In a past life I was a member of the Rails Core team. http://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_normal.jpg http://project.ioni.st false 40059 9AE4E8 33 0084B4 DDFFCC BDDCAD 354 Mon Apr 02 07:47:28 + 2007 131 -28800 Pacific Time (US & Canada) http://a1.twimg.com/profile_background_images/18156348/jessica_tiled.jpg.jpeg true 3472 false true false false === Lists === POST '/:user/lists.:format' Creates a new list for the authenticated user. Parameters: * name: the name of the list. (required) * mode: whether your list is public of private. Values can be 'public' or 'private'. Public by default if not specified. (optional) Usage notes: ":user" in the url should be the screen name of the user making the request to create the list Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -d "name=tall people&mode=private" http://twitter.com/noradio/lists.xml POST/PUT '/:user/lists/:list_slug.:format' Updates the specified list. Takes the same parameters as the create resource at POST '/:user/lists.:format' (:name and :mode). Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -d "name=giants&mode=public" http://twitter.com/noradio/lists/tall-people.xml GET '/:user/lists.:format' Lists your lists. Supported format: xml, json e.g. curl -u USERNAME:PASSWORD http://twitter.com/noradio/lists.xml GET '/:user/lists/memberships.:format' List the lists the specified user has been added to. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD http://twitter.com/noradio/lists/memberships.xml DELETE '/:user/lists/:list_slug.:format' Delete the specified list owned by the authenticated user. Parameters: * list_slug: the slug of the list you want to delete. (required) Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -X DELETE http://twitter.com/noradio/lists/tall-people.xml GET '/:users/lists/:list_slug/statuses.:format' Show tweet timeline for members of the specified list. Parameters: * list_slug: the slug of the list you want the member tweet timeline of. (required) * next/previous_cursor: used to "page" through results (optional) Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD http://twitter.com/noradio/lists/tall-people/statuses.xml GET '/:users/lists/:list_slug.:format' Show a specific list you can use the new resource. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD http://twitter.com/noradio/lists/tall-people.xml === List members === POST '/:user/:list_slug/members.:format' Add a member to a list. Parameters: * id: the id of the user you want to add as a member to the list. (required) Usage notes: The :list_slug portion of the request path should be the slug of the list you want to add a member to. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -d "id=123456789" http://http://twitter.com/noradio/tall-people/members.xml GET '/:user/:list_slug/members.:format' Members of the specified list. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD http://twitter.com/noradio/tall-people/members.xml DELETE '/:user/:list_slug/members.:format' Remove a member from the specified list. Parameters: * id: the id of the user you want to remove as a member from the list. (required) Usage notes: The :list_id portion of the request path should be the slug of the list you want to add a member to. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -X DELETE -d "id=123456789" http://twitter.com/noradio/tall-people/members.xml GET '/:user/:list_slug/members/:id.:format' Check if a user is a member of the specified list. Usage notes: The :id is the id of the user you're inquiring about. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD http://twitter.com/noradio/tall-people/members/123456789.xml === List subscribers === POST '/:user/:l
[twitter-dev] Laying the foundation for API versioning
We've taken the first steps toward introducing versioning into the Twitter REST API. With a versioned API we can make ambitious improvements *today*, not tomorrow, without worrying about breaking backwards compatibility. This will lead to both a better and more reliable API. Available right now, the API's new home is at http://api.twitter.com. Currently only one version is supported: version 1 :-) Version 1 should be in all ways functionally equivalent to the API you're using at the main twitter.com url (if you find what seems like an incompatibility please submit what you've found on our issue tracker: http://code.google.com/p/twitter-api/issues/list). To make a request with the new versioned API, you just need to prefix every path with the desired version. For now that's just 1. So for example, what was http://twitter.com/users/show/noradio.xml becomes http://api.twitter.com/1/users/show/noradio.xml For now we're keeping it simple. No subversions, no implicit version defaults, no fancy-pants etc. We're leaving our approach open to these types of additions, but we aren't going to support them until we feel a compelling need to. We haven't yet determined how many versions will be supported at once or how long a version will continue to be supported once it's deprecated. We'll be figuring out answers to these questions once we spend some time supporting multiple versions and seeing how new APIs emerge and iterate. We suspect though that we'll support deprecated versions for at least 6 months. We also don't have a hard date for when API requests to http://twitter.com will no longer be serviced. We aren't planning on pulling the rug out from anyone though. Please update your applications to the new http://api.twitter.com/1 at your soonest convenience. The non API urls likely won't be supported forever. Though having a versioned API should greatly decrease the likelihood that a change in the API breaks your application, one of the notable exceptions is bug fixes. When bugs are discovered they will be fixed and backported immediately to all supported versions of the API. We're kicking the tires on http://api.twitter.com/1 but we hope to have http://api.twitter.com/2 close around the corner. The time has come for us to start knocking off some of the stuff on V2 Roadmap list http://apiwiki.twitter.com/V2-Roadmap. For a while that page has been the dumping ground for all our lofty dreams. Version 2 probably won't be so ambitious that it resolves everything on that list. We want, after all, to get good at managing a multi-version environment before we get all crazy with the nitrous injections and chrome detailing. But we're putting the framework in place that will allow us to more quickly fix the stuff you've struggling with, take chances without putting your work in jeopardy, and all other things that are good. Cheers. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Laying the foundation for API versioning
The OAuth endpoints aren't strictly speaking part of the REST API. http://api.twitter.com/oauth/authorize and family works at the api subdomain, but those paths aren't versioned (though maybe they should be...). As for search...one step at a time ;-) But thanks for noticing. On Fri, Oct 16, 2009 at 12:46 AM, Rich wrote: > > Great news guys, I noticed that the search and oauth API's aren't in > the version one API stream though. > > Is this intentional? > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Laying the foundation for API versioning
I've alerted our ops team. Thanks for the heads up. On Fri, Oct 16, 2009 at 12:56 AM, Rich wrote: > > I did notice though that api.twitter.com doesn't have a valid SSL > certificate so any clients using the API over SSL will error out too. > > On Oct 16, 8:49 am, Marcel Molina wrote: >> The OAuth endpoints aren't strictly speaking part of the REST API. >> >> http://api.twitter.com/oauth/authorizeand family works at the api >> subdomain, but those paths aren't versioned (though maybe they should >> be...). As for search...one step at a time ;-) But thanks for >> noticing. >> >> On Fri, Oct 16, 2009 at 12:46 AM, Rich wrote: >> >> > Great news guys, I noticed that the search and oauth API's aren't in >> > the version one API stream though. >> >> > Is this intentional? >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Draft of List API documentation
Depending on how our performance tests, bug fixes and all the other myriad things go we could be public with the feature as early as a week or two from now. We shall see... On Fri, Oct 16, 2009 at 1:06 AM, Rich wrote: > > This is fantastic, I hope to start working on it soon. Do you guys > have and idea of possible timespans, only because it takes us two > weeks to get things past Apple's appoval process! > > On Oct 16, 8:04 am, Marcel Molina wrote: >> Hey folks. As some of you have likely read we're starting to do some >> private beta testing of our new lists feature. We're not quite ready >> to open it up to everyone but we've made some headway on the API and >> wanted to share some details of what we've got so far. >> >> There are a handful of things on our todo lists so don't consider this >> signed and sealed just yet. >> >> You may notice this API is a bit of a departure from the rest of the >> API. It's a bit more, errr, REST than the rest. >> >> First off, here's the current payload for a list: >> >> >> >> 1416 >> tall people >> @noradio/tall-people >> tall-people >> 0 >> 3 >> /noradio/tall-people >> public >> >> 3191321 >> Marcel Molina >> noradio >> San Francisco, CA >> Engineer at Twitter on the @twitterapi team, obsessed >> with rock climbing & running. In a past life I was a member of the >> Rails Core team. >> >> http://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_no... >> http://project.ioni.st >> false >> 40059 >> 9AE4E8 >> 33 >> 0084B4 >> DDFFCC >> BDDCAD >> 354 >> Mon Apr 02 07:47:28 + 2007 >> 131 >> -28800 >> Pacific Time (US & Canada) >> >> http://a1.twimg.com/profile_background_images/18156348/jessica_tiled >> true >> 3472 >> false >> true >> false >> false >> >> >> >> === Lists === >> >> POST '/:user/lists.:format' >> Creates a new list for the authenticated user. >> >> Parameters: >> * name: the name of the list. (required) >> * mode: whether your list is public of private. Values can be >> 'public' or 'private'. Public by default if not specified. (optional) >> >> Usage notes: >> ":user" in the url should be the screen name of the user making the >> request to create the list >> >> Supported formats: >> xml, json >> >> e.g. >> curl -u USERNAME:PASSWORD -d "name=tall >> people&mode=private"http://twitter.com/noradio/lists.xml >> >> POST/PUT '/:user/lists/:list_slug.:format' >> Updates the specified list. >> >> Takes the same parameters as the create resource at POST >> '/:user/lists.:format' (:name and :mode). >> >> Supported formats: >> xml, json >> >> e.g. >> curl -u USERNAME:PASSWORD -d >> "name=giants&mode=public"http://twitter.com/noradio/lists/tall-people.xml >> >> GET '/:user/lists.:format' >> Lists your lists. >> >> Supported format: >> xml, json >> >> e.g. >> curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists.xml >> >> GET '/:user/lists/memberships.:format' >> List the lists the specified user has been added to. >> >> Supported formats: >> xml, json >> >> e.g. >> curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/memberships.xml >> >> DELETE '/:user/lists/:list_slug.:format' >> Delete the specified list owned by the authenticated user. >> >> Parameters: >> * list_slug: the slug of the list you want to delete. (required) >> >> Supported formats: >> xml, json >> >> e.g. >> curl -u USERNAME:PASSWORD -X >> DELETEhttp://twitter.com/noradio/lists/tall-people.xml >> >> GET '/:users/lists/:list_slug/statuses.:format' >> Show tweet timeline for members of the specified list. >> >> Parameters: >> * list_slug: the slug of the list you want the member tweet timeline >> of. (required) >> * next/previous_cursor: used to "page" through results (optional) >> >> Supported formats: >> xml, json >> >> e.g. >> curl -u >> USERNAME:PASSWORDhttp://twitter.com/noradio/lists/tall-people/status
[twitter-dev] Re: Laying the foundation for API versioning
Thanks for the report. Looking into it. On Fri, Oct 16, 2009 at 12:55 PM, Dave Briccetti wrote: > > DELETE http://twitter.com/friendships/destroy/USER.xml > > works, but > > DELETE http://api.twitter.com/1/friendships/destroy/USER.xml > > fails with > > You don't have permission to access /1/friendships/destroy/USER.xmlon > this server. > > > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Laying the foundation for API versioning
This was an oversight in a server configuration. We've made the change and should be pushing it out at some point today. Thanks again. On Fri, Oct 16, 2009 at 12:55 PM, Dave Briccetti wrote: > > DELETE http://twitter.com/friendships/destroy/USER.xml > > works, but > > DELETE http://api.twitter.com/1/friendships/destroy/USER.xml > > fails with > > You don't have permission to access /1/friendships/destroy/USER.xmlon > this server. > > > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Laying the foundation for API versioning
The change has been made but it probably hasn't been pushed out yet to the full cluster. I'll follow up with ops on Monday. Thanks. On Sun, Oct 18, 2009 at 1:10 PM, Dave Briccetti wrote: > > Thanks, but still failing today. > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Private lists showing up on memberships page
That looks like a bug. Thanks for bringing it to our attention. On Sun, Oct 18, 2009 at 1:49 PM, Damon C wrote: > > I've seen a couple instances now (@beaker and @mediaphyter) where a > private list shows up on the list of a user's memberships. It doesn't > seem like the existence of these private lists should be showing up in > the memberships list, nor can I reproduce the issue on my own account. > As an example, here's a brief snippet from > http://twitter.com/Beaker/lists/memberships.xml > (sidenote that the member_count shows up as 5 on the HTML version of > the memberships page). > > > 19351 > Security > @twowheelgeek/security > security > 0 > 0 > /twowheelgeek/security > private > > dpc > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Draft of List API documentation
There are plans to expose a description field eventually. On Wed, Oct 21, 2009 at 9:59 AM, nipunj wrote: > > Hey Marcel, > I expect there were many things cut in Lists v1,... but, that said, I > am surprised that Title is essentially the only attribute on the List > object that informs the consumer what a Public List is intended to > actually represent. There's no "bio" analog. IMO, this lack of > explicit descriptive attributes hamstrings Lists discovery. How about > "tags", "description", "list type", etc.? > > Also,... I understand your need to test out the API right now, but > you've created inequity with the private API access. How can folks > like us, who have an app that's closely related to Lists, get access > to the Lists API (ie create a level playing field)? > > Thanks, > Nipun > > @nipj > @tweeppacks > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Laying the foundation for API versioning
Ops is working on fixing this. We identified some stale configurations on some hosts (which is why the failures are intermittent). It's currently being worked on and should be resolved soon. Thanks for reporting it. On Wed, Oct 21, 2009 at 10:00 AM, Sal Conigliaro wrote: > > Hi Marcel- > > I'm still seeing the cert hostname mismatch. > > https://api.twitter.com/1/users/show/rwzombie.xml > > The cert hostname returned is still shown as 'twitter.com'. > > Sal > > On Oct 18, 4:36 pm, Marcel Molina wrote: >> The change has been made but it probably hasn't been pushed out yet to >> the full cluster. I'll follow up with ops on Monday. Thanks. >> >> On Sun, Oct 18, 2009 at 1:10 PM, Dave Briccetti wrote: >> >> > Thanks, but still failing today. >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Not cool to RT a protected tweet
Protected tweets will not be retweetable. On Thu, Oct 22, 2009 at 11:42 AM, Tim Haines wrote: > > Hey guys, > > @ev: "It's not cool to RT a protected tweet" > http://twitter.com/ev/status/4955618846 > > Will the new RT api disallow you from RT'ing protected tweets? I > think this would be a good move. > > Tim. > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug & more consistent names)
Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug & more consistent names)
Answers inline: On Wed, Oct 28, 2009 at 1:14 PM, Tim Haines wrote: > > Marcel, > > Great changes. A couple of questions: > > - How long can a list description be? 160 :-) > - A title can only be 15 chars - will that remain unchanged? Unchanged. > - Will there be a little overlap where memberships and subscribers > will still work while people migrate to followers/following? Yeah. There will be overlap for some period of time for those who might need to transition. > It would be awesome if there was a way to retrieve all member ids and > a separate call for subscriber ids - cursored if necessary. Right, I'll add that to the "list of things to consider" :-) > Also, filed an edge case bug around list error messages a couple of > days ago. > http://code.google.com/p/twitter-api/issues/detail?id=1145&sort=-opened&colspec=ID%20Stars%20Type%20Status%20Priority%20Owner%20Summary%20Opened%20Modified%20Component Thanks. > Cheers, > > Tim. > > > On Oct 29, 9:00 am, Marcel Molina wrote: >> Two additions and two changes to the List API will be deployed in the >> next few days: >> >> * List descriptions >> We're adding a description to every list. You'll be able to specify a >> description when you create or update a list and the description will >> be included in the payload. >> >> * Cursoring through lists of lists >> All resources that return a list of lists will include next and >> previous cursors and will accept a :cursor parameter. >> >> * Finding by list id rather than slug >> When you change the name of a list, the slug will be updated to >> reflect that change. That means using the slug in the url for >> resources to operate on lists requires the onerous task of validating >> that the slug for the list you are about to do something with hasn't >> been updated since the last time you stored its slug. What a nightmare >> :-) >> >> Every list also has an id. This value won't change. We'll be changing >> the API to replace all instances of a list slug in urls to be list ids >> instead. >> >> * Consistent names >> The terminology we've used thus far for people you follow with a list >> is members. The terminology for people who are following a list is >> subscribers. We're going to mirror the terminology used for users and >> change it to followers and following respectively. >> >> So: >> >> /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers >> >> /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following >> >> As we deploy these changes we'll send out a heads up on the dev list >> and @twitterapi. >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug & more consistent names)
Real soon now. We appreciate everyone's patience while we gradually ramp up traffic to lists to ensure we've got all our ducks in a row. On Wed, Oct 28, 2009 at 2:53 PM, Rich wrote: > > +1 to this > > Any news on when the rest of us devs can get access to this to work on > our apps? > > On Oct 28, 8:11 pm, Jesse Stay wrote: >> Maybe a little more appropriate to post this to a private list (no pun >> intended) for beta users? I admit I feel a little jealous every time I see >> one of these updates, unless there's some way to get into the beta. >> >> Thanks, >> >> Jesse >> >> >> >> On Wed, Oct 28, 2009 at 2:00 PM, Marcel Molina wrote: >> >> > Two additions and two changes to the List API will be deployed in the >> > next few days: >> >> > * List descriptions >> > We're adding a description to every list. You'll be able to specify a >> > description when you create or update a list and the description will >> > be included in the payload. >> >> > * Cursoring through lists of lists >> > All resources that return a list of lists will include next and >> > previous cursors and will accept a :cursor parameter. >> >> > * Finding by list id rather than slug >> > When you change the name of a list, the slug will be updated to >> > reflect that change. That means using the slug in the url for >> > resources to operate on lists requires the onerous task of validating >> > that the slug for the list you are about to do something with hasn't >> > been updated since the last time you stored its slug. What a nightmare >> > :-) >> >> > Every list also has an id. This value won't change. We'll be changing >> > the API to replace all instances of a list slug in urls to be list ids >> > instead. >> >> > * Consistent names >> > The terminology we've used thus far for people you follow with a list >> > is members. The terminology for people who are following a list is >> > subscribers. We're going to mirror the terminology used for users and >> > change it to followers and following respectively. >> >> > So: >> >> > /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers >> >> > /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following >> >> > As we deploy these changes we'll send out a heads up on the dev list >> > and @twitterapi. >> >> > -- >> > Marcel Molina >> > Twitter Platform Team >> >http://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug & more consistent names)
The cursors are for lists of lists and lists of users followed by/following lists. The statuses timeline for a given list takes all the same options you'd expect to manage status timelines. On Wed, Oct 28, 2009 at 5:43 PM, Naveen wrote: > > How does one keep a list up to date for a client without the concept > of since_id, like we have for the timeline methods? I look at a lists > as just a different timeline (granted one filtered to specific users), > but that is how I would expect to view them in a client. > > From my understanding of cursors, on each request we have to start at > -1 (to start paging) and page until we find an id that we already have > locally. While this will work, it has a high probability of always > over requesting data.. > > So if I have a list with two people in it, and they only tweet once a > week, when I poll for updates of this list (say every 30min) the data > is going to be the same most of the time(last 100 messages that these > two people post). This seems like a waste of bandwidth for Twitter and > us.. Some may argue that bandwidth is cheap, but it really is not on > mobile devices. Some carriers charge per kb, but even on unlimited > plans every byte transferred translates to additional battery drain.. > > Is there some concept of the cursor that I am not understanding that > will allow us to also filter based on something like since_id? So we > want to get messages newer than we already have and notify the user > that the list has something new to display. > > Thanks to anyone who can clarify if I am misunderstanding something. > > --Naveen > > On Oct 28, 6:14 pm, Marcel Molina wrote: >> Real soon now. We appreciate everyone's patience while we gradually >> ramp up traffic to lists to ensure we've got all our ducks in a row. >> >> >> >> >> >> On Wed, Oct 28, 2009 at 2:53 PM, Rich wrote: >> >> > +1 to this >> >> > Any news on when the rest of us devs can get access to this to work on >> > our apps? >> >> > On Oct 28, 8:11 pm, Jesse Stay wrote: >> >> Maybe a little more appropriate to post this to a private list (no pun >> >> intended) for beta users? I admit I feel a little jealous every time I >> >> see >> >> one of these updates, unless there's some way to get into the beta. >> >> >> Thanks, >> >> >> Jesse >> >> >> On Wed, Oct 28, 2009 at 2:00 PM, Marcel Molina wrote: >> >> >> > Two additions and two changes to the List API will be deployed in the >> >> > next few days: >> >> >> > * List descriptions >> >> > We're adding a description to every list. You'll be able to specify a >> >> > description when you create or update a list and the description will >> >> > be included in the payload. >> >> >> > * Cursoring through lists of lists >> >> > All resources that return a list of lists will include next and >> >> > previous cursors and will accept a :cursor parameter. >> >> >> > * Finding by list id rather than slug >> >> > When you change the name of a list, the slug will be updated to >> >> > reflect that change. That means using the slug in the url for >> >> > resources to operate on lists requires the onerous task of validating >> >> > that the slug for the list you are about to do something with hasn't >> >> > been updated since the last time you stored its slug. What a nightmare >> >> > :-) >> >> >> > Every list also has an id. This value won't change. We'll be changing >> >> > the API to replace all instances of a list slug in urls to be list ids >> >> > instead. >> >> >> > * Consistent names >> >> > The terminology we've used thus far for people you follow with a list >> >> > is members. The terminology for people who are following a list is >> >> > subscribers. We're going to mirror the terminology used for users and >> >> > change it to followers and following respectively. >> >> >> > So: >> >> >> > /:user/lists/:list_id/memberships becomes >> >> > /:user/lists/:list_id/followers >> >> >> > /:user/lists/:list_id/subscribers becomes >> >> > /:user/lists/:list_id/following >> >> >> > As we deploy these changes we'll send out a heads up on the dev list >> >> > and @twitterapi. >> >> >> > -- >> >> > Marcel Molina >> >> > Twitter Platform Team >> >> >http://twitter.com/noradio >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Subscribed Lists
Currently it's still slug. It hasn't been updated yet. When it is updated it will for some period of transition accept a slug or an id but eventually support for the slug in the url will be removed entirely. On Sun, Nov 1, 2009 at 2:14 AM, Rich wrote: > > Can we get some form of confirmation on the list slug/id issue. At > the moment calling by ID doesn't work anyway so it's only using the > slug. > > My preference would be to allow either (in a similar way to the other > REST api's where you can use user id or screenName) > > On Oct 31, 10:04 pm, twittelator wrote: >> :user/lists/subscriptions.:format >> >> gets the lists that the user has subscribed to. >> >> Andrew Stone >> Twitter / @twittelatorhttp://www.stone.com >> got iPhone? >> http://tinyurl.com/twitpro >> http://tinyurl.com/intentionizer >> http://tinyurl.com/gesture-buy >> http://tinyurl.com/igraffiti >> http://tinyurl.com/talkingpics >> http://tinyurl.com/mobilemix >> http://tinyurl.com/soundbite >> http://tinyurl.com/icreated >> http://tinyurl.com/pulsar-app >> >> On Oct 30, 5:00 am, "David Neubauer" >> wrote: >> >> >> >> > Has any figured out how to get a the lists I'm subscribed to. I didn't >> > realize how much I'd want this part of it. Please say it's coming... >> >> > -Original Message- >> > From: twitter-development-talk@googlegroups.com >> >> > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Jeremy Felt >> > Sent: Thursday, October 29, 2009 8:16 PM >> > To: Twitter Development Talk >> > Subject: [twitter-dev] Re: Updates to the List API (list descriptions, >> > cursoring lists of lists, finding by list id rather than slug & more >> > consistent names) >> >> > It appears that user/lists.xml only shows lists that are created by >> > the user and not those that they follow. >> >> > Any change coming to that or am I missing a way to see all lists that >> > a user follows? >> >> > Thanks, >> > Jeremy >> >> > On Oct 28, 3:00 pm, Marcel Molina wrote: >> > > Two additions and two changes to the List API will be deployed in the >> > > next few days: >> >> > > * List descriptions >> > > We're adding a description to every list. You'll be able to specify a >> > > description when you create or update a list and the description will >> > > be included in the payload. >> >> > > * Cursoring through lists of lists >> > > All resources that return a list of lists will include next and >> > > previous cursors and will accept a :cursor parameter. >> >> > > * Finding by list id rather than slug >> > > When you change the name of a list, the slug will be updated to >> > > reflect that change. That means using the slug in the url for >> > > resources to operate on lists requires the onerous task of validating >> > > that the slug for the list you are about to do something with hasn't >> > > been updated since the last time you stored its slug. What a nightmare >> > > :-) >> >> > > Every list also has an id. This value won't change. We'll be changing >> > > the API to replace all instances of a list slug in urls to be list ids >> > > instead. >> >> > > * Consistent names >> > > The terminology we've used thus far for people you follow with a list >> > > is members. The terminology for people who are following a list is >> > > subscribers. We're going to mirror the terminology used for users and >> > > change it to followers and following respectively. >> >> > > So: >> >> > > /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers >> >> > > /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following >> >> > > As we deploy these changes we'll send out a heads up on the dev list >> > > and @twitterapi. >> >> > > -- >> > > Marcel Molina >> > > Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: how to create list of lists
This is probably confusion arising from something I wrote in a previous email. When I said "list of list" I meant the payload of the response body had zero or more list elements in it, therefore a "list of lists". There is no way to create lists of lists in the sense that you are talking about. On Sat, Oct 31, 2009 at 7:13 AM, Ravi wrote: > > > The new api talks about list of lists. I do not see how to add a list > to another list. Whenever I follow a list, my main account follows it, > not my list. > > On a side note, I was playing with the API yesterday and somehow a > list I created shows up twice under "Lists you follow". I guess a bug > somewhere. > > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Subscribed Lists
Resolving a @screen_name/list_name reference in a tweet is a compelling argument for making the url parameter polymorphic and not deprecating the use of slugs. I will cogitate. On Sun, Nov 1, 2009 at 10:09 AM, wrote: > I have to second Rich on this - ID-only is flawed, as twitter supports > hotlinking lists by name (@username/slug) in tweets, and links that to the > list page. If clients want to offer the same behavior, this is not possible > if the API only supports IDs (or would require a potentially large number of > additional requests to get the user's lists and page through them to find the > one mentioned). > > Marco > > > -----Original Message- > From: Marcel Molina > Date: Sun, 1 Nov 2009 10:02:31 > To: > Subject: [twitter-dev] Re: Subscribed Lists > > > Currently it's still slug. It hasn't been updated yet. When it is > updated it will for some period of transition accept a slug or an id > but eventually support for the slug in the url will be removed > entirely. > > On Sun, Nov 1, 2009 at 2:14 AM, Rich wrote: >> >> Can we get some form of confirmation on the list slug/id issue. At >> the moment calling by ID doesn't work anyway so it's only using the >> slug. >> >> My preference would be to allow either (in a similar way to the other >> REST api's where you can use user id or screenName) >> >> On Oct 31, 10:04 pm, twittelator wrote: >>> :user/lists/subscriptions.:format >>> >>> gets the lists that the user has subscribed to. >>> >>> Andrew Stone >>> Twitter / @twittelatorhttp://www.stone.com >>> got iPhone? >>> http://tinyurl.com/twitpro >>> http://tinyurl.com/intentionizer >>> http://tinyurl.com/gesture-buy >>> http://tinyurl.com/igraffiti >>> http://tinyurl.com/talkingpics >>> http://tinyurl.com/mobilemix >>> http://tinyurl.com/soundbite >>> http://tinyurl.com/icreated >>> http://tinyurl.com/pulsar-app >>> >>> On Oct 30, 5:00 am, "David Neubauer" >>> wrote: >>> >>> >>> >>> > Has any figured out how to get a the lists I'm subscribed to. I didn't >>> > realize how much I'd want this part of it. Please say it's coming... >>> >>> > -Original Message- >>> > From: twitter-development-talk@googlegroups.com >>> >>> > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Jeremy >>> > Felt >>> > Sent: Thursday, October 29, 2009 8:16 PM >>> > To: Twitter Development Talk >>> > Subject: [twitter-dev] Re: Updates to the List API (list descriptions, >>> > cursoring lists of lists, finding by list id rather than slug & more >>> > consistent names) >>> >>> > It appears that user/lists.xml only shows lists that are created by >>> > the user and not those that they follow. >>> >>> > Any change coming to that or am I missing a way to see all lists that >>> > a user follows? >>> >>> > Thanks, >>> > Jeremy >>> >>> > On Oct 28, 3:00 pm, Marcel Molina wrote: >>> > > Two additions and two changes to the List API will be deployed in the >>> > > next few days: >>> >>> > > * List descriptions >>> > > We're adding a description to every list. You'll be able to specify a >>> > > description when you create or update a list and the description will >>> > > be included in the payload. >>> >>> > > * Cursoring through lists of lists >>> > > All resources that return a list of lists will include next and >>> > > previous cursors and will accept a :cursor parameter. >>> >>> > > * Finding by list id rather than slug >>> > > When you change the name of a list, the slug will be updated to >>> > > reflect that change. That means using the slug in the url for >>> > > resources to operate on lists requires the onerous task of validating >>> > > that the slug for the list you are about to do something with hasn't >>> > > been updated since the last time you stored its slug. What a nightmare >>> > > :-) >>> >>> > > Every list also has an id. This value won't change. We'll be changing >>> > > the API to replace all instances of a list slug in urls to be list ids >>> > > instead. >>> >>> > > * Consistent names >>> > > The terminology we've used thus far for people you follow with a list >>> > > is members. The terminology for people who are following a list is >>> > > subscribers. We're going to mirror the terminology used for users and >>> > > change it to followers and following respectively. >>> >>> > > So: >>> >>> > > /:user/lists/:list_id/memberships becomes >>> > > /:user/lists/:list_id/followers >>> >>> > > /:user/lists/:list_id/subscribers becomes >>> > > /:user/lists/:list_id/following >>> >>> > > As we deploy these changes we'll send out a heads up on the dev list >>> > > and @twitterapi. >>> >>> > > -- >>> > > Marcel Molina >>> > > Twitter Platform Teamhttp://twitter.com/noradio >> > > > > -- > Marcel Molina > Twitter Platform Team > http://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Lists API
It's available to all developers and has been since last Thursday. There are still some tweaks to be made but everything that works now should continue to be supported along side the changes and additions that will be introduced. On Mon, Nov 2, 2009 at 9:48 AM, Michael Steuer wrote: > With all the discussions on this mailing list about the Lists API, can > someone please confirm, is the API now available to all developers or all of > you in some sort of preferred position? > > Thanks, > > Michael. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Truncated URLs
I believe in that case the url is just truncated and gone. I believe this only works when shortening it with bit.ly still wouldn't make the tweet fewer than 140 characters. Though it seems unfortunate to lose the url, in a sense you aren't missing data because *no one* gets that url so ultimately it doesn't really exist :) I'd imagine this is fairly rare, yes? I'd recommend just giving up and skipping the tweet if the url isn't fully formed. On Mon, Nov 2, 2009 at 6:51 AM, Adam Green wrote: > > I'm extracting URLs from tweets, and some of them are truncated at the > end of a tweet. The URL ends up as something like http://domain... > > I can't find anything in the API that will let me get the full URL, so > I assume it is lost. Is this correct, or is there some trick to get > back the entire URL before truncation? > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Subscribed Lists
There is, in a sense, an API for resolving a list id by passing in a slug. It's the show resource for a list. You'll either get a 404 (which means the slug no longer exist) or you'll get the list payload which will include the id. On Sun, Nov 1, 2009 at 11:29 PM, Rich wrote: > > Using ID only for me is fine, except in the case we mention. If there > was a REST api to find a list ID based on a slug then it would mean we > could still resolve @screen_name/list_name links otherwise we wouldn't > be able to replicate it, except by brute force which would use yet > more API calls. > > On Nov 1, 6:14 pm, Marcel Molina wrote: >> Resolving a @screen_name/list_name reference in a tweet is a >> compelling argument for making the url parameter polymorphic and not >> deprecating the use of slugs. I will cogitate. >> >> >> >> >> >> On Sun, Nov 1, 2009 at 10:09 AM, wrote: >> > I have to second Rich on this - ID-only is flawed, as twitter supports >> > hotlinking lists by name (@username/slug) in tweets, and links that to the >> > list page. If clients want to offer the same behavior, this is not >> > possible if the API only supports IDs (or would require a potentially >> > large number of additional requests to get the user's lists and page >> > through them to find the one mentioned). >> >> > Marco >> > >> >> > -Original Message- >> > From: Marcel Molina >> > Date: Sun, 1 Nov 2009 10:02:31 >> > To: >> > Subject: [twitter-dev] Re: Subscribed Lists >> >> > Currently it's still slug. It hasn't been updated yet. When it is >> > updated it will for some period of transition accept a slug or an id >> > but eventually support for the slug in the url will be removed >> > entirely. >> >> > On Sun, Nov 1, 2009 at 2:14 AM, Rich wrote: >> >> >> Can we get some form of confirmation on the list slug/id issue. At >> >> the moment calling by ID doesn't work anyway so it's only using the >> >> slug. >> >> >> My preference would be to allow either (in a similar way to the other >> >> REST api's where you can use user id or screenName) >> >> >> On Oct 31, 10:04 pm, twittelator wrote: >> >>> :user/lists/subscriptions.:format >> >> >>> gets the lists that the user has subscribed to. >> >> >>> Andrew Stone >> >>> Twitter / @twittelatorhttp://www.stone.com >> >>> got iPhone? >> >>> http://tinyurl.com/twitpro >> >>> http://tinyurl.com/intentionizer >> >>> http://tinyurl.com/gesture-buy >> >>> http://tinyurl.com/igraffiti >> >>> http://tinyurl.com/talkingpics >> >>> http://tinyurl.com/mobilemix >> >>> http://tinyurl.com/soundbite >> >>> http://tinyurl.com/icreated >> >>> http://tinyurl.com/pulsar-app >> >> >>> On Oct 30, 5:00 am, "David Neubauer" >> >>> wrote: >> >> >>> > Has any figured out how to get a the lists I'm subscribed to. I didn't >> >>> > realize how much I'd want this part of it. Please say it's coming... >> >> >>> > -----Original Message- >> >>> > From: twitter-development-talk@googlegroups.com >> >> >>> > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Jeremy >> >>> > Felt >> >>> > Sent: Thursday, October 29, 2009 8:16 PM >> >>> > To: Twitter Development Talk >> >>> > Subject: [twitter-dev] Re: Updates to the List API (list descriptions, >> >>> > cursoring lists of lists, finding by list id rather than slug & more >> >>> > consistent names) >> >> >>> > It appears that user/lists.xml only shows lists that are created by >> >>> > the user and not those that they follow. >> >> >>> > Any change coming to that or am I missing a way to see all lists that >> >>> > a user follows? >> >> >>> > Thanks, >> >>> > Jeremy >> >> >>> > On Oct 28, 3:00 pm, Marcel Molina wrote: >> >>> > > Two additions and two changes to the List API will be deployed in the >> >>> > > next few days: >> >> >>> >
[twitter-dev] Re: Lists API
You may (until further notice) ;-) On Mon, Nov 2, 2009 at 10:12 AM, wrote: > > Can I translate that into 'the current URL to get a list using the slug will > not be deprecated'? > > Marco > > > -Original Message- > From: Marcel Molina > Date: Mon, 2 Nov 2009 10:05:03 > To: > Subject: [twitter-dev] Re: Lists API > > > It's available to all developers and has been since last Thursday. > > There are still some tweaks to be made but everything that works now > should continue to be supported along side the changes and additions > that will be introduced. > > On Mon, Nov 2, 2009 at 9:48 AM, Michael Steuer wrote: >> With all the discussions on this mailing list about the Lists API, can >> someone please confirm, is the API now available to all developers or all of >> you in some sort of preferred position? >> >> Thanks, >> >> Michael. > > > > -- > Marcel Molina > Twitter Platform Team > http://twitter.com/noradio > > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: update_delivery_device method
Please file a bug about this on our issue tracker if you haven't already: http://code.google.com/p/twitter-api/issues/list Thanks. On Wed, Oct 28, 2009 at 11:55 PM, DustyReagan wrote: > > I was playing around with the account/update_delivery_device method. > > It seems to behave like this: > > device=sms:im - Does nothing > device=none - Turns device updates off > > Neither "sms" or "im" turn device updates back on. > > Are there any plans for this method to be updated or deprecated? > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Subscribed Lists
Both will be allowed. On Mon, Nov 2, 2009 at 1:34 PM, Rich wrote: > > Thanks for that Marcel, well if it's decided to completely abandon > slugs I'll have to go down that route. > > Any idea on whether both call types will be allowed yet? Obviously > the main lookups will are quick to switch between, just this > @screen_name/list_name that'll take more work if we can't use the > slug. > > On Nov 2, 6:12 pm, Marcel Molina wrote: >> There is, in a sense, an API for resolving a list id by passing in a >> slug. It's the show resource for a list. You'll either get a 404 >> (which means the slug no longer exist) or you'll get the list payload >> which will include the id. >> >> >> >> >> >> On Sun, Nov 1, 2009 at 11:29 PM, Rich wrote: >> >> > Using ID only for me is fine, except in the case we mention. If there >> > was a REST api to find a list ID based on a slug then it would mean we >> > could still resolve @screen_name/list_name links otherwise we wouldn't >> > be able to replicate it, except by brute force which would use yet >> > more API calls. >> >> > On Nov 1, 6:14 pm, Marcel Molina wrote: >> >> Resolving a @screen_name/list_name reference in a tweet is a >> >> compelling argument for making the url parameter polymorphic and not >> >> deprecating the use of slugs. I will cogitate. >> >> >> On Sun, Nov 1, 2009 at 10:09 AM, wrote: >> >> > I have to second Rich on this - ID-only is flawed, as twitter supports >> >> > hotlinking lists by name (@username/slug) in tweets, and links that to >> >> > the list page. If clients want to offer the same behavior, this is not >> >> > possible if the API only supports IDs (or would require a potentially >> >> > large number of additional requests to get the user's lists and page >> >> > through them to find the one mentioned). >> >> >> > Marco >> >> > >> >> >> > -Original Message- >> >> > From: Marcel Molina >> >> > Date: Sun, 1 Nov 2009 10:02:31 >> >> > To: >> >> > Subject: [twitter-dev] Re: Subscribed Lists >> >> >> > Currently it's still slug. It hasn't been updated yet. When it is >> >> > updated it will for some period of transition accept a slug or an id >> >> > but eventually support for the slug in the url will be removed >> >> > entirely. >> >> >> > On Sun, Nov 1, 2009 at 2:14 AM, Rich wrote: >> >> >> >> Can we get some form of confirmation on the list slug/id issue. At >> >> >> the moment calling by ID doesn't work anyway so it's only using the >> >> >> slug. >> >> >> >> My preference would be to allow either (in a similar way to the other >> >> >> REST api's where you can use user id or screenName) >> >> >> >> On Oct 31, 10:04 pm, twittelator wrote: >> >> >>> :user/lists/subscriptions.:format >> >> >> >>> gets the lists that the user has subscribed to. >> >> >> >>> Andrew Stone >> >> >>> Twitter / @twittelatorhttp://www.stone.com >> >> >>> got iPhone? >> >> >>> http://tinyurl.com/twitpro >> >> >>> http://tinyurl.com/intentionizer >> >> >>> http://tinyurl.com/gesture-buy >> >> >>> http://tinyurl.com/igraffiti >> >> >>> http://tinyurl.com/talkingpics >> >> >>> http://tinyurl.com/mobilemix >> >> >>> http://tinyurl.com/soundbite >> >> >>> http://tinyurl.com/icreated >> >> >>> http://tinyurl.com/pulsar-app >> >> >> >>> On Oct 30, 5:00 am, "David Neubauer" >> >> >>> wrote: >> >> >> >>> > Has any figured out how to get a the lists I'm subscribed to. I >> >> >>> > didn't >> >> >>> > realize how much I'd want this part of it. Please say it's coming... >> >> >> >>> > -Original Message- >> >> >>> > From: twitter-development-talk@googlegroups.com >> >> >> >>> > [mailto:twitter-development-t...@googlegroups.com] On Behalf O
[twitter-dev] Re: Draft of List API documentation
A work around for environments that don't support the DELETE request method is, I believe, to pass a parameter called _method with the value "DELETE". In other words "_method=DELETE". On Mon, Nov 2, 2009 at 11:26 PM, wilfred yau wrote: > > It there any method to delete user from list other then using DELETE > method? > Since I am using Flex (but not Air) to develop third party Twitter > Client, There are no way to call "DELETE" (which only GET and POST). > So, will twitter provide POST or GET method API to "delete"? Thanks > > > On Oct 16, 3:04 pm, Marcel Molina wrote: >> Hey folks. As some of you have likely read we're starting to do some >> private beta testing of our new lists feature. We're not quite ready >> to open it up to everyone but we've made some headway on the API and >> wanted to share some details of what we've got so far. >> >> There are a handful of things on our todo lists so don't consider this >> signed and sealed just yet. >> >> You may notice this API is a bit of a departure from the rest of the >> API. It's a bit more, errr, REST than the rest. >> >> First off, here's the current payload for alist: >> >> >> >> 1416 >> tall people >> @noradio/tall-people >> tall-people >> 0 >> 3 >> /noradio/tall-people >> public >> >> 3191321 >> Marcel Molina >> noradio >> San Francisco, CA >> Engineer at Twitter on the @twitterapi team, obsessed >> with rock climbing & running. In a past life I was a member of the >> Rails Core team. >> >> http://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_no... >> http://project.ioni.st >> false >> 40059 >> 9AE4E8 >> 33 >> 0084B4 >> DDFFCC >> BDDCAD >> 354 >> Mon Apr 02 07:47:28 + 2007 >> 131 >> -28800 >> Pacific Time (US & Canada) >> >> http://a1.twimg.com/profile_background_images/18156348/jessica_tiled >> true >> 3472 >> false >> true >> false >> false >> >> >> >> === Lists === >> >> POST '/:user/lists.:format' >> Creates a newlistfor the authenticated user. >> >> Parameters: >> * name: the name of thelist. (required) >> * mode: whether yourlistis public of private. Values can be >> 'public' or 'private'. Public by default if not specified. (optional) >> >> Usage notes: >> ":user" in the url should be the screen name of the user making the >> request to create thelist >> >> Supported formats: >> xml, json >> >> e.g. >> curl -u USERNAME:PASSWORD -d "name=tall >> people&mode=private"http://twitter.com/noradio/lists.xml >> >> POST/PUT '/:user/lists/:list_slug.:format' >> Updates the specifiedlist. >> >> Takes the same parameters as the create resource at POST >> '/:user/lists.:format' (:name and :mode). >> >> Supported formats: >> xml, json >> >> e.g. >> curl -u USERNAME:PASSWORD -d >> "name=giants&mode=public"http://twitter.com/noradio/lists/tall-people.xml >> >> GET '/:user/lists.:format' >> Lists your lists. >> >> Supported format: >> xml, json >> >> e.g. >> curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists.xml >> >> GET '/:user/lists/memberships.:format'Listthe lists the specified user has >> been added to. >> >> Supported formats: >> xml, json >> >> e.g. >> curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/memberships.xml >> >> DELETE '/:user/lists/:list_slug.:format' >> Delete the specifiedlistowned by the authenticated user. >> >> Parameters: >> * list_slug: the slug of thelistyou want to delete. (required) >> >> Supported formats: >> xml, json >> >> e.g. >> curl -u USERNAME:PASSWORD -X >> DELETEhttp://twitter.com/noradio/lists/tall-people.xml >> >> GET '/:users/lists/:list_slug/statuses.:format' >> Show tweet timeline for members of the specifiedlist. >> >> Parameters: >> * list_slug: the slug of thelistyou want the member tweet timeline >> of. (required) >> * next/previous_cursor: used to "page" through results (optional) >> >> Supporte
[twitter-dev] Re: List API : statuses timeline and count parameter
You can use all the same parameters as are available in the other status timeline resources (e.g. max_id, count, since_id, etc). On Tue, Nov 3, 2009 at 4:07 PM, stephane wrote: > > Hi guys ! > > Is there a way (or planned method) to get more than 20 statuses per > list timeline API call ? apparently there is no equivalent to the > count parameter. > > Best, > > Stephane Philipakis > @sphilipakis > www.twazzup.com > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: List API : statuses timeline and count parameter
Oh. I've realized that all the options *except* for count are supported. Fixing that now. Should be deployed to production in the next day or so. Thanks for reporting this. On Tue, Nov 3, 2009 at 5:01 PM, Marcel Molina wrote: > You can use all the same parameters as are available in the other > status timeline resources (e.g. max_id, count, since_id, etc). > > On Tue, Nov 3, 2009 at 4:07 PM, stephane > wrote: >> >> Hi guys ! >> >> Is there a way (or planned method) to get more than 20 statuses per >> list timeline API call ? apparently there is no equivalent to the >> count parameter. >> >> Best, >> >> Stephane Philipakis >> @sphilipakis >> www.twazzup.com >> > > > > -- > Marcel Molina > Twitter Platform Team > http://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Suggestion for User record
We've got this on our todo list. It requires fairly extensive asynchronous fragment invalidation so it's not as simple as just adding the count into the payload. We've got it on the list though. On Sat, Oct 31, 2009 at 7:10 PM, Dave Winer wrote: > > It would be useful if a had a lists_count element, in addition > to the other counts (followers, statuses, favourites). > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: RSS support for Lists
We will be supporting atom for the statuses timeline of a list soon. On Wed, Nov 4, 2009 at 6:17 AM, alexkingorg wrote: > > [Sorry if this has been covered, I searched for a while before > posting.] > > According to the documentation and my initial testing, there does not > appear to be support for receiving data from a List in RSS format > (only json and xml). Is there a reason why this hasn't been added or > was it just not high enough priority and will get added at some point > in the future? > > If you were waiting for someone to request it, I'm happy to fill that > role. :) > > Thanks, > --Alex > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Draft of List API documentation
We plan to support this. It's on the todo list. Thanks for the suggestion. On Tue, Nov 3, 2009 at 8:38 PM, Damon Clinkscales wrote: > > On Fri, Oct 16, 2009 at 1:04 AM, Marcel Molina wrote: >> >> Hey folks. As some of you have likely read we're starting to do some >> private beta testing of our new lists feature. We're not quite ready >> to open it up to everyone but we've made some headway on the API and >> wanted to share some details of what we've got so far. >> >> There are a handful of things on our todo lists so don't consider this >> signed and sealed just yet. > > Marcel, > > It would be nice if we could pass in either the user_id or the > screen_name, wherever you are currently requiring a Twitter user id. > This would be consistent with the rest of the REST API (and quite > useful, saving an extra call). > > Thanks, > -damon > -- > http://twitter.com/damon > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Since_ID and Search Problem
I've talked with the search team and there's a known condition where 10 of our servers are behind the others that can cause varying results across requests. We're aware of the issue, it is ticket and we are working on it. On Wed, Nov 4, 2009 at 3:45 AM, Spode wrote: > > Hi, > > I've been noticing some strange behaviour since last night - but > that's not to say it's not been going on longer. > > http://search.twitter.com/search.json?q=JournoTwit&rpp=100&since_id=5402169538 > > Performing this search turns up 0 results when it should show 4. > > http://search.twitter.com/search.json?q=JournoTwit&rpp=100&since_id= > > Run it with no since_id and it works. Then straight away run the > original query... > > http://search.twitter.com/search.json?q=JournoTwit&rpp=100&since_id=5402169538 > > And you get the expected 4 results. > > What's going on? > > Spode (journotwit.com) > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Background images on a0.twimg.com giving access denied
Thanks for reporting this. I've forwarded this to the team responsible
for the S3 uploading.
On Wed, Nov 4, 2009 at 10:28 AM, Kevin wrote:
>
> We are uploading Twitter backgrounds via the API. We noticed today new
> attempts to upload seem to be successful, but the profiles show no
> background image. Looking at the page source, it shows a new
> background image URL:
> background: ... url('http://a0.twimg.com/profile_background_images/
> bg12573586264055.jpg') ...;
>
> However, opening that URL returns an error:
>
> AccessDeniedAccess Denied Message>20FB3BC5AEC2A2D5KheAYU8E/puKx
> +qm5jtF9YeLLfc/NHcoCr6q2iOWZy2OR3tbtouA3Fo5aTrHUrZn
>
> It would appear Twitter is not adding the S3 access key query string
> to these background image URLs, or the images are being put into S3 as
> private items.
>
> Hope to see a fix soon.
> Regards,
> Kevin Hunt
> Bubble Fusion Labs
>
--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio
[twitter-dev] Re: Draft of List API documentation
I think it should work for any request. Not sure though. Give it a try ;-) On Thu, Nov 5, 2009 at 5:48 AM, Paul Kinlan wrote: > Can you confirm that _method=DELETE only works on POST's and not GET's? > Paul > > 2009/11/3 Marcel Molina >> >> A work around for environments that don't support the DELETE request >> method is, I believe, to pass a parameter called _method with the >> value "DELETE". In other words "_method=DELETE". >> >> On Mon, Nov 2, 2009 at 11:26 PM, wilfred yau wrote: >> > >> > It there any method to delete user from list other then using DELETE >> > method? >> > Since I am using Flex (but not Air) to develop third party Twitter >> > Client, There are no way to call "DELETE" (which only GET and POST). >> > So, will twitter provide POST or GET method API to "delete"? Thanks >> > >> > >> > On Oct 16, 3:04 pm, Marcel Molina wrote: >> >> Hey folks. As some of you have likely read we're starting to do some >> >> private beta testing of our new lists feature. We're not quite ready >> >> to open it up to everyone but we've made some headway on the API and >> >> wanted to share some details of what we've got so far. >> >> >> >> There are a handful of things on our todo lists so don't consider this >> >> signed and sealed just yet. >> >> >> >> You may notice this API is a bit of a departure from the rest of the >> >> API. It's a bit more, errr, REST than the rest. >> >> >> >> First off, here's the current payload for alist: >> >> >> >> >> >> >> >> 1416 >> >> tall people >> >> @noradio/tall-people >> >> tall-people >> >> 0 >> >> 3 >> >> /noradio/tall-people >> >> public >> >> >> >> 3191321 >> >> Marcel Molina >> >> noradio >> >> San Francisco, CA >> >> Engineer at Twitter on the @twitterapi team, obsessed >> >> with rock climbing & running. In a past life I was a member of the >> >> Rails Core team. >> >> >> >> http://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_no... >> >> http://project.ioni.st >> >> false >> >> 40059 >> >> 9AE4E8 >> >> 33 >> >> 0084B4 >> >> DDFFCC >> >> BDDCAD >> >> 354 >> >> Mon Apr 02 07:47:28 + 2007 >> >> 131 >> >> -28800 >> >> Pacific Time (US & Canada) >> >> >> >> http://a1.twimg.com/profile_background_images/18156348/jessica_tiled >> >> true >> >> 3472 >> >> false >> >> true >> >> false >> >> false >> >> >> >> >> >> >> >> === Lists === >> >> >> >> POST '/:user/lists.:format' >> >> Creates a newlistfor the authenticated user. >> >> >> >> Parameters: >> >> * name: the name of thelist. (required) >> >> * mode: whether yourlistis public of private. Values can be >> >> 'public' or 'private'. Public by default if not specified. (optional) >> >> >> >> Usage notes: >> >> ":user" in the url should be the screen name of the user making the >> >> request to create thelist >> >> >> >> Supported formats: >> >> xml, json >> >> >> >> e.g. >> >> curl -u USERNAME:PASSWORD -d "name=tall >> >> people&mode=private"http://twitter.com/noradio/lists.xml >> >> >> >> POST/PUT '/:user/lists/:list_slug.:format' >> >> Updates the specifiedlist. >> >> >> >> Takes the same parameters as the create resource at POST >> >> '/:user/lists.:format' (:name and :mode). >> >> >> >> Supported formats: >> >> xml, json >> >> >> >> e.g. >> >> curl -u USERNAME:PASSWORD -d >> >> "name=giants&mode=public"http://twitter.com/noradio/lists/tall-people.xml >> >> >> >> GET '/:user/lists.:format' >> >> Lists your lists. >> >> >> >>
[twitter-dev] Re: Draft of List API documentation
Status timelines paginate with the page parameters. Social graph resources such as the members in a list use the cursor parameters. We're looking to rationalize all this as we move to new systems but for now there are different interfaces. You use the same mechanisms for the list statuses timeline as you do for all other status timelines. On Thu, Nov 5, 2009 at 7:05 AM, Milen wrote: > > I think that all methods which refer to lists should use the id, not > the slug. As people have mentioned, the slug can change, so in order > to reliably delete a list, you will have to fetch its slug and then > issue a delete (or you risk getting an error as the slug might have > changed in the meantime). > > I also tried to "page" through the statuses in a list but it seemed > that: > - next_cursor / previous_cursor had no effect on what was returned > - cursor=-1 or anything else didn't have an effect > > Can anyone shed some light on how we're supposed to do paging? > > Thanks, > M > > On Oct 16, 7:04 am, Marcel Molina wrote: > >> GET '/:users/lists/:list_slug/statuses.:format' >> Show tweet timeline for members of the specified list. >> >> Parameters: >> * list_slug: the slug of the list you want the member tweet timeline >> of. (required) >> * next/previous_cursor: used to "page" through results (optional) >> >> Supported formats: >> xml, json >> >> e.g. >> curl -u >> USERNAME:PASSWORDhttp://twitter.com/noradio/lists/tall-people/statuses.xml > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Draft of List API documentation
We will support specifying a list by both id and slug indefinitely. Though we recognize the short comings of finding by slug since they are prone to changing, there are use cases where finding by slug is a lot more convenient. So we'll be supporting both. You never *have* to search by slug :-) On Thu, Nov 5, 2009 at 7:05 AM, Milen wrote: > > I think that all methods which refer to lists should use the id, not > the slug. As people have mentioned, the slug can change, so in order > to reliably delete a list, you will have to fetch its slug and then > issue a delete (or you risk getting an error as the slug might have > changed in the meantime). > > I also tried to "page" through the statuses in a list but it seemed > that: > - next_cursor / previous_cursor had no effect on what was returned > - cursor=-1 or anything else didn't have an effect > > Can anyone shed some light on how we're supposed to do paging? > > Thanks, > M > > On Oct 16, 7:04 am, Marcel Molina wrote: > >> GET '/:users/lists/:list_slug/statuses.:format' >> Show tweet timeline for members of the specified list. >> >> Parameters: >> * list_slug: the slug of the list you want the member tweet timeline >> of. (required) >> * next/previous_cursor: used to "page" through results (optional) >> >> Supported formats: >> xml, json >> >> e.g. >> curl -u >> USERNAME:PASSWORDhttp://twitter.com/noradio/lists/tall-people/statuses.xml > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Is image shrinking broken?
I've passed this issue along to the team that owns the image resizing code to see if they have any insights into what the issue might be. On Mon, Nov 2, 2009 at 9:25 PM, TCI wrote: > > I am noticing an increase in the number of avatar images which do not > get shrinked in the smaller versions. It is most noticeable in the > twitter.com homepage as the images load very slowly from top to > bottom. How are your clients handling this? In my case I am assuming > the shrinking is working and therefore my page load times are being > affected. > > Example: > > http://a3.twimg.com/profile_images/506101471/Copy__2__of_Francesca__4__bigger.jpg > http://a3.twimg.com/profile_images/506101471/Copy__2__of_Francesca__4__normal.jpg > http://a3.twimg.com/profile_images/506101471/Copy__2__of_Francesca__4__mini.jpg > > are all the same... > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Background images on a0.twimg.com giving access denied
To follow up I've been told that this is the most critical bug they
are working on right now. So it's being worked on. I'll pass along
updates as provided.
On Wed, Nov 4, 2009 at 1:57 PM, Marcel Molina wrote:
> Thanks for reporting this. I've forwarded this to the team responsible
> for the S3 uploading.
>
> On Wed, Nov 4, 2009 at 10:28 AM, Kevin wrote:
>>
>> We are uploading Twitter backgrounds via the API. We noticed today new
>> attempts to upload seem to be successful, but the profiles show no
>> background image. Looking at the page source, it shows a new
>> background image URL:
>> background: ... url('http://a0.twimg.com/profile_background_images/
>> bg12573586264055.jpg') ...;
>>
>> However, opening that URL returns an error:
>>
>> AccessDeniedAccess Denied> Message>20FB3BC5AEC2A2D5KheAYU8E/puKx
>> +qm5jtF9YeLLfc/NHcoCr6q2iOWZy2OR3tbtouA3Fo5aTrHUrZn
>>
>> It would appear Twitter is not adding the S3 access key query string
>> to these background image URLs, or the images are being put into S3 as
>> private items.
>>
>> Hope to see a fix soon.
>> Regards,
>> Kevin Hunt
>> Bubble Fusion Labs
>>
>
>
>
> --
> Marcel Molina
> Twitter Platform Team
> http://twitter.com/noradio
>
--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio
[twitter-dev] Re: Oauth and (lack) delegation
We've got a project lined up to come up with an answer for OAuth app delegation problem. We haven't done a deep dive into what the approach might be yet so we don't have any ideas yet. Would be glad to have the conversation with those who are interested and have ideas. On Thu, Nov 5, 2009 at 4:20 PM, Michael Steuer wrote: > Does Twitter (or anyone else) have thoughts around the lack of delegation in > Oauth and the announced deprecation of basic authentication? Currently, to > enable an API that allows web services to interact with Twitter on its > behalf (e.g. TwitPic, yFrog, etc.) one has to rely on basic authentication > (the twitter client passing the user’s username & password to the web > services API), as delegation is not possible via Oauth... If a user > authenticates with my application via Oauth, there’s no way I can have a 3rd > party API do anything on behalf of that user... > > Similarly, if I want to develop an API to my Twitter web service, I would > have to develop that with basic authentication, but what’s the point: > > knowing that basic auth is going to be deprecated in the (near) future > so many apps are now based on oauth and wouldn’t be able to use my API > because they can’t authenticate > > I’m sure other devs have run into this. Does Twitter have any thoughts > around this? How do you expect to maintain a 3rd party app/API eco system > after basic auth deprecation? > > Looking forward to everyone’s feedback.. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: api.twitter.com not returning compressed data
We've confirmed this and reported it to our operations team. We've identified the problem and are actively fixing it. Thanks for the detailed report. I'll let you know when the gzip compression is restored. On Thu, Nov 5, 2009 at 7:19 PM, Jason Diller wrote: > > API calls to http://twitter.com/ with Accept-Encoding:gzip in the > headers are > returning compressed data, while calls to http://api.twitter.com/1/ > with the same > headers do not. > > You can demonstrate this with cUrl: > curl --basic -u "user:pass" --header "Accept-Encoding:gzip, deflate" > http://api.twitter.com/1/statuses/friends_timeline.json > > vs. > > curl --basic -u "user:pass" --header "Accept-Encoding:gzip, deflate" > http://twitter.com/statuses/friends_timeline.json > > In the second example, you will get garbled response indicating that > the data is > compressed, whereas in the first you will get clear text. (Note: if > you use > --compress instead of --header then cUrl will decompress the response > so you'll have > to use Wireshark or some other network sniffer to see the raw data). > > We tracked this down because one of our users in Europe reported a big > perf hit after we switched to the versioned endpoint. (see > http://code.google.com/p/tweetsharp/issues/detail?id=104) > > I hope this isn't by design. > > Jason Diller > Tweetsharp Contributor > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Getting user info from REST interface using name and not screen name
There is no API for that at the moment. We're developing an API for people search though. On Thu, Nov 5, 2009 at 6:38 PM, Kripashankar wrote: > > Hi, > > I am developing a small prototype and would like to know the > following. > > > 1. How can I get info about a user given only the name and not screen > name ? > > Example: > http://twitter.com/users/show.xml?screen_name=aplusk > > gives me info about ashton kutcher but let's say I don't know the > screen name but only know the name "Ashton Kutcher". How can I get the > corresponding screen name and id, or the user info with just the > name ? The api > > http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show > > doesn't seem to take name as a parameter. > > BTW, I noticed two user info > http://twitter.com/users/show.xml?screen_name=aplusk > http://twitter.com/users/show.xml?screen_name=ashtonkutcher > > So I am not sure which is the right one as well for Ashton Kutcher. > > Any help much appreciated. > > Thanks! > > > > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: api.twitter.com not returning compressed data
The configuration has been fixed. The configuration updates should be pushed out to all servers tomorrow morning PST. On Thu, Nov 5, 2009 at 8:20 PM, Marcel Molina wrote: > We've confirmed this and reported it to our operations team. We've > identified the problem and are actively fixing it. Thanks for the > detailed report. I'll let you know when the gzip compression is > restored. > > On Thu, Nov 5, 2009 at 7:19 PM, Jason Diller wrote: >> >> API calls to http://twitter.com/ with Accept-Encoding:gzip in the >> headers are >> returning compressed data, while calls to http://api.twitter.com/1/ >> with the same >> headers do not. >> >> You can demonstrate this with cUrl: >> curl --basic -u "user:pass" --header "Accept-Encoding:gzip, deflate" >> http://api.twitter.com/1/statuses/friends_timeline.json >> >> vs. >> >> curl --basic -u "user:pass" --header "Accept-Encoding:gzip, deflate" >> http://twitter.com/statuses/friends_timeline.json >> >> In the second example, you will get garbled response indicating that >> the data is >> compressed, whereas in the first you will get clear text. (Note: if >> you use >> --compress instead of --header then cUrl will decompress the response >> so you'll have >> to use Wireshark or some other network sniffer to see the raw data). >> >> We tracked this down because one of our users in Europe reported a big >> perf hit after we switched to the versioned endpoint. (see >> http://code.google.com/p/tweetsharp/issues/detail?id=104) >> >> I hope this isn't by design. >> >> Jason Diller >> Tweetsharp Contributor >> > > > > -- > Marcel Molina > Twitter Platform Team > http://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Authentication not required for Twitter REST API Method
The statuses timeline does not in fact require authentication. I'll update the docs. This was an oversight. Thanks. On Thu, Nov 5, 2009 at 9:37 PM, davidzimm wrote: > > The API description says that authentication is supposed to be > required, but it is not. I don't know if this is a typo or if > something is wrong, but you don't have to be authenticated to get the > updates of a twitter list by ATOM (or any other format, for that > matter). > > Not that I'm complaining: > http://www.dizzysoft.com/twitter/twitter-lists-text-messages > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: /statuses/retweeted_to_me.xml?count=200 yields HTTP 500
Thanks for the report. Will try to recreate & look into it. On Fri, Nov 6, 2009 at 12:35 AM, Dave Briccetti wrote: > > BY ME: http://twitter.com/statuses/retweeted_by_me.xml?count=200 works > just fine. > > TO ME: /statuses/retweeted_to_me.xml?count=10 works fine. > > User dcbriccetti > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Question about versioning
We do not have plans to support minor versions initially. We're going to start with the simplest versioning scheme possible and then expand it to include minor versions when the need arises. So as of right now version 1 already exists, at http://api.twitter.com/1. As for whether it should be considered "stable", I'd say it's very close to being so. I've been using it exclusively on my Twitter clients for several months. Since announcing it publicly a couple weeks ago the only reports of irregularities have been around server configuration (e.g. some requests over ssl getting an untrusted cert error and requests for gzipped responses not being configured correctly). As for the behavior of the API it should be 100% compatible with the non versioned twitter.com API. On Thu, Nov 5, 2009 at 7:36 AM, DeWitt Clinton wrote: > Hi all, > I'd like to sync the version numbers and release cycles of a few twitter > libraries (python-twitter and java-twitter) up with the version of the > Twitter API itself. I'll admit that I've fallen way behind on > the maintenance of each, partly because the Twitter API itself is a moving > target (not a bad thing, just hard to keep in sync with). > What's the expected timing of when we can rely on a stable versioned > endpoint for v1, v2, etc, and bleeding-edge API versions? In theory we'd do > parallel releases on major/minor releases, and keep a dev branch open for > the latest-and-greatest-and-beta-est version of the Twitter API. > -DeWitt -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: can FOLLOW, but can't LEAVE
I've passed this along to our mobile team. Will update when I hear back from them. Thanks for reporting this. On Mon, Nov 9, 2009 at 2:24 PM, Cameron Kaiser wrote: > > I have users complaining that of the commands listed on > > http://help.twitter.com/forums/59008/entries/14020 > > they all still work right for status updates *except* LEAVE (FOLLOW > *does* work). On my own testing, LEAVE just appears to do nothing. Did > this break? > > -- > personal: http://www.cameronkaiser.com/ > -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com > -- Never explain, never apologise. -- John Arbuthnot "Jackie" Fisher > -- > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: can FOLLOW, but can't LEAVE
The mobile team can't reproduce this problem. Several of them tried and LEAVE worked for all of them... On Mon, Nov 9, 2009 at 2:28 PM, Marcel Molina wrote: > I've passed this along to our mobile team. Will update when I hear > back from them. Thanks for reporting this. > > On Mon, Nov 9, 2009 at 2:24 PM, Cameron Kaiser wrote: >> >> I have users complaining that of the commands listed on >> >> http://help.twitter.com/forums/59008/entries/14020 >> >> they all still work right for status updates *except* LEAVE (FOLLOW >> *does* work). On my own testing, LEAVE just appears to do nothing. Did >> this break? >> >> -- >> personal: http://www.cameronkaiser.com/ >> -- >> Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com >> -- Never explain, never apologise. -- John Arbuthnot "Jackie" Fisher >> -- >> > > > > -- > Marcel Molina > Twitter Platform Team > http://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Count for statuses from a list appears to do nothing
You can use the "per_page" parameter for this. I'll update the documentation. Should probably support "count" as well as an alias. On Mon, Nov 9, 2009 at 5:15 PM, Ryan Bigg wrote: > > Specifying different count on the request appears to send back the > same file: > > ryanb...@fp:mocra-web (master)$ wget "http://api.twitter.com/1/drnic/ > lists/mocra/statuses.json?callback=updateTwitter()&count=100" > --2009-11-10 11:13:41-- > http://api.twitter.com/1/drnic/lists/mocra/statuses.json?callback=updateTwitter()&count=100 > Resolving api.twitter.com... 128.121.146.109 > Connecting to api.twitter.com|128.121.146.109|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 24800 (24K) [application/json] > Saving to: `statuses.json?callback=updateTwitter()&count=100' > > 100% > [==>] > 24,800 --.-K/s in 0.02s > > 2009-11-10 11:13:42 (1.56 MB/s) - `statuses.json?callback=updateTwitter > ()&count=100' saved [24800/24800] > > ryanb...@fp:mocra-web (master)$ wget "http://api.twitter.com/1/drnic/ > lists/mocra/statuses.json?callback=updateTwitter()&count=5" > --2009-11-10 11:13:51-- > http://api.twitter.com/1/drnic/lists/mocra/statuses.json?callback=updateTwitter()&count=5 > Resolving api.twitter.com... 128.121.146.109 > Connecting to api.twitter.com|128.121.146.109|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 24800 (24K) [application/json] > Saving to: `statuses.json?callback=updateTwitter()&count=5' > > 100% > [==>] > 24,800 --.-K/s in 0.02s > > 2009-11-10 11:13:51 (1.37 MB/s) - `statuses.json?callback=updateTwitter > ()&count=5' saved [24800/24800] > > ryanb...@fp:mocra-web (master)$ > > Even though the API here says you can specify one: > http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-list-statuses?SearchFor=%3AList&sp=5 > > What gives? > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: 500 ISE on List API Update?
Yes we've been made aware of this. It should be noted that the update sticks despite the 500 response. It's on our todo list of things to investigate. Thanks for reporting it. On Tue, Nov 10, 2009 at 9:48 AM, Aaron Brazell wrote: > I seem to be getting 500 Internal Server Errors on the List API for updating > a list. Can anyone verify? > > Aaron Brazell > CEO, Emmense Technologies > Lead Editor, Technosailor.com > Author, The WordPress Bible > > e: aa...@technosailor.com > b: http://technosailor.com > t: http://twitter.com/technosailor > p: 443-455-1056Aaron Brazell > web:: www.technosailor.com > phone:: 410-608-6620 > skype:: technosailor > twitter:: @technosailor > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: direct messages to lists
That is indeed an interesting idea that we've been thinking about. The rules around who can send and receive DMs would continue to be enforced as normal, so for talking purposes, if you DMed a list, only those who follow you would receive it. On Tue, Nov 10, 2009 at 9:21 AM, Marcus Better wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > have you considered adding a mechanism for sending a sort of "direct > message" to a list? > > This would allow users to send targeted tweets to a list (provided the > user is a member of the list). It could be incredibly useful. For > example tweets on a specific topic could be targeted to a selected > interest group, without bothering your general followers. > > Currently the only granularity provided is "whole world" (tweet) and > "single recipient" (direct message), but this would allow new use cases, > for example something similar to a mailing list. > > Cheers, > > Marcus > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkr5oQUACgkQXjXn6TzcAQk+PgCfemGcdxyqZZrg1tNsxTWhna39 > gdAAoLJZHsM8yIqxzpHMp3XlYue2ODpz > =ARYR > -END PGP SIGNATURE- > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: direct messages to lists
As with all things, there will certainly be vectors for abuse. For every bad use case, there are just as many or more positive use cases. We'll certainly be thinking about many on both sides. Thanks for pointing out some of the potential hazards. On Tue, Nov 10, 2009 at 10:28 AM, Dewald Pretorius wrote: > > Marcel, > > How would that be different from sending bulk DMs - something I have > been advised in the past is not something that Twitter condones. > > Here's the scenario. > > MarketerMario has 2,000 followers. He creates four lists and adds 500 > of his followers to each list. Now he can send, with four simple > clicks, his tweet whitening affiliate link to all his followers. > > Dewald > > On Nov 10, 2:19 pm, Marcel Molina wrote: >> That is indeed an interesting idea that we've been thinking about. The >> rules around who can send and receive DMs would continue to be >> enforced as normal, so for talking purposes, if you DMed a list, only >> those who follow you would receive it. >> >> >> >> On Tue, Nov 10, 2009 at 9:21 AM, Marcus Better wrote: >> >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA1 >> >> > Hi, >> >> > have you considered adding a mechanism for sending a sort of "direct >> > message" to a list? >> >> > This would allow users to send targeted tweets to a list (provided the >> > user is a member of the list). It could be incredibly useful. For >> > example tweets on a specific topic could be targeted to a selected >> > interest group, without bothering your general followers. >> >> > Currently the only granularity provided is "whole world" (tweet) and >> > "single recipient" (direct message), but this would allow new use cases, >> > for example something similar to a mailing list. >> >> > Cheers, >> >> > Marcus >> > -----BEGIN PGP SIGNATURE- >> > Version: GnuPG v1.4.10 (GNU/Linux) >> > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org >> >> > iEYEARECAAYFAkr5oQUACgkQXjXn6TzcAQk+PgCfemGcdxyqZZrg1tNsxTWhna39 >> > gdAAoLJZHsM8yIqxzpHMp3XlYue2ODpz >> > =ARYR >> > -END PGP SIGNATURE- >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: 500 ISE on List API Update?
Worksforme: mar...@albatross:~TW% master ./bin/twurl /1/noradio/lists/1416.xml 1416 tall people @noradio/tall-people tall-people 3 3 /noradio/tall-people public etc ... On Tue, Nov 10, 2009 at 10:19 AM, Aaron Brazell wrote: > On Tue, Nov 10, 2009 at 1:16 PM, Marcel Molina wrote: >> >> Yes we've been made aware of this. It should be noted that the update >> sticks despite the 500 response. It's on our todo list of things to >> investigate. Thanks for reporting it. >> > > Excellent. While we're at it, we're 404ing on the GET List ID API.... In > case you didn't know that as well :) -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Blocking vs non-blocking list creation: list streams are different
Indeed something looks strange there. I've brought this to the attention of the team working on the lists backend. I'll let you know what they discover. On Mon, Nov 9, 2009 at 10:20 PM, Eric Gilbert wrote: > > I'm developing an app that builds a few lists. Since it seems the only > way to add users to lists is one id per call (please let me know if > I'm mistaken), I experimented with populating the lists > asynchronously. Both seem to build the list fine, and of course async > is much faster. Here's the strange thing: although the lists created > with each method have the same membership list, the lists streams are > not the same. (Sync seems to be doing the right thing, but I haven't > verified this rigorously.) For example, see > > http://twitter.com/eegilbert/right vs > http://twitter.com/eegilbert/notsoright > > Strange. > > Cheers, > Eric > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: direct messages to lists
But people who are added to MarketerMario's list won't get his list broadcasts unless they follow him. That's their "opt-in". If they have followed him for whatever reason and decide they do *not* want his broadcasts, they can simply unfollow him. On Tue, Nov 10, 2009 at 10:46 AM, Dewald Pretorius wrote: > > Marcel, > > You can circumvent the issue by making the receiving of a DM that is > sent to a list dependent on two triggers: > > a) You must follow the sender of the DM; and > > b) You must explicitly double opt-in to receive DMs that are sent to > the list. > > Bona fide use cases will be able to acquire the double opt-ins from > interested users, while most people will simply not opt-in when > MarketerMario adds them to his list. > > Dewald > > On Nov 10, 2:34 pm, Marcel Molina wrote: >> As with all things, there will certainly be vectors for abuse. For >> every bad use case, there are just as many or more positive use cases. >> We'll certainly be thinking about many on both sides. Thanks for >> pointing out some of the potential hazards. >> >> >> >> On Tue, Nov 10, 2009 at 10:28 AM, Dewald Pretorius wrote: >> >> > Marcel, >> >> > How would that be different from sending bulk DMs - something I have >> > been advised in the past is not something that Twitter condones. >> >> > Here's the scenario. >> >> > MarketerMario has 2,000 followers. He creates four lists and adds 500 >> > of his followers to each list. Now he can send, with four simple >> > clicks, his tweet whitening affiliate link to all his followers. >> >> > Dewald >> >> > On Nov 10, 2:19 pm, Marcel Molina wrote: >> >> That is indeed an interesting idea that we've been thinking about. The >> >> rules around who can send and receive DMs would continue to be >> >> enforced as normal, so for talking purposes, if you DMed a list, only >> >> those who follow you would receive it. >> >> >> On Tue, Nov 10, 2009 at 9:21 AM, Marcus Better wrote: >> >> >> > -BEGIN PGP SIGNED MESSAGE- >> >> > Hash: SHA1 >> >> >> > Hi, >> >> >> > have you considered adding a mechanism for sending a sort of "direct >> >> > message" to a list? >> >> >> > This would allow users to send targeted tweets to a list (provided the >> >> > user is a member of the list). It could be incredibly useful. For >> >> > example tweets on a specific topic could be targeted to a selected >> >> > interest group, without bothering your general followers. >> >> >> > Currently the only granularity provided is "whole world" (tweet) and >> >> > "single recipient" (direct message), but this would allow new use cases, >> >> > for example something similar to a mailing list. >> >> >> > Cheers, >> >> >> > Marcus >> >> > -BEGIN PGP SIGNATURE- >> >> > Version: GnuPG v1.4.10 (GNU/Linux) >> >> > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org >> >> >> > iEYEARECAAYFAkr5oQUACgkQXjXn6TzcAQk+PgCfemGcdxyqZZrg1tNsxTWhna39 >> >> > gdAAoLJZHsM8yIqxzpHMp3XlYue2ODpz >> >> > =ARYR >> >> > -END PGP SIGNATURE- >> >> >> -- >> >> Marcel Molina >> >> Twitter Platform Teamhttp://twitter.com/noradio >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: direct messages to lists
I'm not saying any of this is being implemented. I'm just responding in the abstract about the scenario you were proposing. On Tue, Nov 10, 2009 at 11:08 AM, Dewald Pretorius wrote: > > Marcel, > > You should talk to Jillian about this as well. I'm sure she will have > a contrary opinion on the matter. > > Dewald > > On Nov 10, 2:51 pm, Marcel Molina wrote: >> But people who are added to MarketerMario's list won't get his list >> broadcasts unless they follow him. That's their "opt-in". If they have >> followed him for whatever reason and decide they do *not* want his >> broadcasts, they can simply unfollow him. >> >> >> >> On Tue, Nov 10, 2009 at 10:46 AM, Dewald Pretorius wrote: >> >> > Marcel, >> >> > You can circumvent the issue by making the receiving of a DM that is >> > sent to a list dependent on two triggers: >> >> > a) You must follow the sender of the DM; and >> >> > b) You must explicitly double opt-in to receive DMs that are sent to >> > the list. >> >> > Bona fide use cases will be able to acquire the double opt-ins from >> > interested users, while most people will simply not opt-in when >> > MarketerMario adds them to his list. >> >> > Dewald >> >> > On Nov 10, 2:34 pm, Marcel Molina wrote: >> >> As with all things, there will certainly be vectors for abuse. For >> >> every bad use case, there are just as many or more positive use cases. >> >> We'll certainly be thinking about many on both sides. Thanks for >> >> pointing out some of the potential hazards. >> >> >> On Tue, Nov 10, 2009 at 10:28 AM, Dewald Pretorius >> >> wrote: >> >> >> > Marcel, >> >> >> > How would that be different from sending bulk DMs - something I have >> >> > been advised in the past is not something that Twitter condones. >> >> >> > Here's the scenario. >> >> >> > MarketerMario has 2,000 followers. He creates four lists and adds 500 >> >> > of his followers to each list. Now he can send, with four simple >> >> > clicks, his tweet whitening affiliate link to all his followers. >> >> >> > Dewald >> >> >> > On Nov 10, 2:19 pm, Marcel Molina wrote: >> >> >> That is indeed an interesting idea that we've been thinking about. The >> >> >> rules around who can send and receive DMs would continue to be >> >> >> enforced as normal, so for talking purposes, if you DMed a list, only >> >> >> those who follow you would receive it. >> >> >> >> On Tue, Nov 10, 2009 at 9:21 AM, Marcus Better >> >> >> wrote: >> >> >> >> > -BEGIN PGP SIGNED MESSAGE- >> >> >> > Hash: SHA1 >> >> >> >> > Hi, >> >> >> >> > have you considered adding a mechanism for sending a sort of "direct >> >> >> > message" to a list? >> >> >> >> > This would allow users to send targeted tweets to a list (provided >> >> >> > the >> >> >> > user is a member of the list). It could be incredibly useful. For >> >> >> > example tweets on a specific topic could be targeted to a selected >> >> >> > interest group, without bothering your general followers. >> >> >> >> > Currently the only granularity provided is "whole world" (tweet) and >> >> >> > "single recipient" (direct message), but this would allow new use >> >> >> > cases, >> >> >> > for example something similar to a mailing list. >> >> >> >> > Cheers, >> >> >> >> > Marcus >> >> >> > -BEGIN PGP SIGNATURE- >> >> >> > Version: GnuPG v1.4.10 (GNU/Linux) >> >> >> > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org >> >> >> >> > iEYEARECAAYFAkr5oQUACgkQXjXn6TzcAQk+PgCfemGcdxyqZZrg1tNsxTWhna39 >> >> >> > gdAAoLJZHsM8yIqxzpHMp3XlYue2ODpz >> >> >> > =ARYR >> >> >> > -END PGP SIGNATURE- >> >> >> >> -- >> >> >> Marcel Molina >> >> >> Twitter Platform Teamhttp://twitter.com/noradio >> >> >> -- >> >> Marcel Molina >> >> Twitter Platform Teamhttp://twitter.com/noradio >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: /statuses/retweets_of_me resource does not have the retweet_status element
I believe in this case the documentation is just incorrect. The status timeline of retweets_of_me is my original tweets that have been retweeted. I'll update the docs to reflect that. On Tue, Nov 10, 2009 at 7:11 PM, Michael Ivey (@ivey) wrote: > > Marcel, et al > > I'm working on bringing our Retweet-commerce tools up to date with the > new RTs, now that they're rolling out, and we've got an issue. > > /statuses/retweets_of_me is returning just the statuses, without a > retweet_status element to tell me who did the retweet. Is this a doc > issue, or a bug? > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: GET list members/subscribers - variant that returns ids only?
This has been brought up before and is on the list of things to implement. Thanks for the suggestion. On Wed, Nov 11, 2009 at 12:11 AM, Steve Farrell wrote: > > The social graph methods that return a list of ids are very simple and > efficient. For example: > http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids. > > Are there plans for offering analogous queries for Lists? The > existing functions for paging through user *objects* using cursors is > considerably less efficient when you simply are looking for ids. > > Thanks! > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: GET list members/subscribers - variant that returns ids only?
Yup. Ids everywhere of everything! On Wed, Nov 11, 2009 at 11:23 AM, Steve Farrell wrote: > > That's great news! > > An analogous request: how about getting a set of list ids instead of > list objects for subscriptions/memberships? > > On Nov 11, 11:18 am, Marcel Molina wrote: >> This has been brought up before and is on the list of things to >> implement. Thanks for the suggestion. >> >> On Wed, Nov 11, 2009 at 12:11 AM, Steve Farrell wrote: >> >> > The social graph methods that return a list of ids are very simple and >> > efficient. For >> > example:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids. >> >> > Are there plans for offering analogous queries for Lists? The >> > existing functions for paging through user *objects* using cursors is >> > considerably less efficient when you simply are looking for ids. >> >> > Thanks! >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Bad ssl certs on some servers for api.twitter.com/1 ?
Ops has been trying to track down this problem for a while. They confirmed that all servers have the correct cert. The current hypothesis is that there are some rogue servers that are being load balanced to that we don't expect to be accepting api.twitter.com traffic that do not have the correct cert. Sorry it's not fixed yet. We hope we can figure it out soon as it's a blocker for the transition of api traffic from twitter.com to api.twitter.com. On Tue, Nov 17, 2009 at 7:41 AM, Mageuzi wrote: > > I've been having this same issue when connecting to https://api.twitter.com. > I would have thought that if it is a problem with my code, I would > always get this error. However, it is intermittent. Most times it > works, but a few times an hour I will get the error. Also, I never > have this problem with https://twitter.com. > > > On Nov 15, 6:46 pm, John Adams wrote: >> On Nov 15, 2009, at 1:16 PM, Tim Haines wrote: >> >> > Hi there, >> >> > I'm doing some dev work and I'm getting occasional ssl errors when >> > making calls against api.twitter.com/1. The most recent was posting >> > to favorites/create. >> >> > Is it possible some of the servers have bad certificates? Or is it >> > likely I'm doing something very wrong? >> >> All of our servers have the same certificates; We have had some people >> report a similar issue before and we verified all of the certificates >> at that time. I do know of people having validation issues when they >> don't have current versions of OpenSSL, a current Root CA bundle, or >> their code has problems processing chained SSL certificates. >> >> Which program are you using to make requests against api.twitter.com? >> curl? Firefox? >> >> Twitter's SSL certs are issued by RapidSSL/Equifax. >> Make sure you have the proper root CA certs installed. >> >> If you're using OpenSSL libraries directly, remember that OpenSSL >> ships without any Root CA certs installed. >> >> Curl users will have similar problems as well -- you'll want to run mk- >> ca-bundle to get the proper ca-bundle installed. >> >> The TTYtter developers have a script that pulls the current CA bundle >> from Mozilla, here: >> >> http://www.floodgap.com/software/ttytter/mk-ca-bundle.txt >> >> -john > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Retweets - where are they placed on timeline
Should appear as a new tweet with the time of the retweet, not the original tweet creation time. That assumes though that no one else has retweeted it to you yet. If someone else has then this additional retweet won't appear in your timelines except for the statuses/retweets/id resource that lists up to 100 retweets for a given tweet. Duplicates are collapsed out of the other timelines. On Tue, Nov 17, 2009 at 11:46 AM, Tim Haines wrote: > Hi guys, > I'm wondering if anyone can clarify. > The services I run often shown tweets that are several months old, and offer > the RT button next to them. If someone clicks to RT the tweet, how does the > tweet get presented to people that aren't following the original tweeter? > Is it placed at the top of the timeline appearing as a new tweet, or is it > placed at the time the original tweet was tweeted? i.e. months ago, so > likely to never be seen? > If it would be placed months ago, it makes RT pointless for older tweets, in > which case I'll switch to 'classic mode' RT's. > Tim. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Retweets - where are they placed on timeline
As Tim mentioned, clients are empowered to uncollapse retweets if they'd like. On Tue, Nov 17, 2009 at 12:37 PM, Dewald Pretorius wrote: > > Marcel, > > This collapsing behavior is far from ideal and will cause people with > busy timelines to completely miss retweets. > > Nobody is online 24x7, and if only the first retweet of an update is > shown in a user's timeline, they will miss completely it if the first > retweet happened several hours before they login and check their > timeline. > > In other words, someone can retweet the same update while they are > online and they still won't see it. > > From a Twitter-internal technical standpoint, new retweets are ideal > because it eliminates a lot of duplication and accompanying processing > and storage requirements. > > From a user's perspective, it is far from ideal. > > With old-style retweets, if I saw ten retweets of the same thing, I > knew to check it out because obviously a lot of people felt it was > something worth sharing with their followers. With the new retweets, > I'm going to miss that completely. Even if I notice the first retweet, > the "retweeted by" section may show only one or two people, and I > won't know that the update was retweeted by twenty more people after I > happened to look at it. > > In my irrelevant opinion, the new retweet feature is trying to fix > something that was not broken. > > Dewald > > On Nov 17, 3:58 pm, Marcel Molina wrote: >> Should appear as a new tweet with the time of the retweet, not the >> original tweet creation time. That assumes though that no one else has >> retweeted it to you yet. If someone else has then this additional >> retweet won't appear in your timelines except for the >> statuses/retweets/id resource that lists up to 100 retweets for a >> given tweet. Duplicates are collapsed out of the other timelines. >> >> On Tue, Nov 17, 2009 at 11:46 AM, Tim Haines wrote: >> > Hi guys, >> > I'm wondering if anyone can clarify. >> > The services I run often shown tweets that are several months old, and >> > offer >> > the RT button next to them. If someone clicks to RT the tweet, how does >> > the >> > tweet get presented to people that aren't following the original tweeter? >> > Is it placed at the top of the timeline appearing as a new tweet, or is it >> > placed at the time the original tweet was tweeted? i.e. months ago, so >> > likely to never be seen? >> > If it would be placed months ago, it makes RT pointless for older tweets, >> > in >> > which case I'll switch to 'classic mode' RT's. >> > Tim. >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Retweets - where are they placed on timeline
The retweet feature is currently rolled out to 50% of users. We gradually ramping it up. Full availability should be soon unless issues arise as we incrementally roll it out. Thanks for your patience. It's awesome to have people ready to pull the trigger on retweet. On Tue, Nov 17, 2009 at 1:27 PM, Rich wrote: > Does everyone have access to the ReTweet beta now? If not when is > expected deployment. I have a fully working ReTweet API > implementation but I don't want to submit it to Apple until everyone > has access to it. > > On Nov 17, 9:19 pm, Marcel Molina wrote: >> As Tim mentioned, clients are empowered to uncollapse retweets if they'd >> like. >> >> >> >> >> >> On Tue, Nov 17, 2009 at 12:37 PM, Dewald Pretorius wrote: >> >> > Marcel, >> >> > This collapsing behavior is far from ideal and will cause people with >> > busy timelines to completely miss retweets. >> >> > Nobody is online 24x7, and if only the first retweet of an update is >> > shown in a user's timeline, they will miss completely it if the first >> > retweet happened several hours before they login and check their >> > timeline. >> >> > In other words, someone can retweet the same update while they are >> > online and they still won't see it. >> >> > From a Twitter-internal technical standpoint, new retweets are ideal >> > because it eliminates a lot of duplication and accompanying processing >> > and storage requirements. >> >> > From a user's perspective, it is far from ideal. >> >> > With old-style retweets, if I saw ten retweets of the same thing, I >> > knew to check it out because obviously a lot of people felt it was >> > something worth sharing with their followers. With the new retweets, >> > I'm going to miss that completely. Even if I notice the first retweet, >> > the "retweeted by" section may show only one or two people, and I >> > won't know that the update was retweeted by twenty more people after I >> > happened to look at it. >> >> > In my irrelevant opinion, the new retweet feature is trying to fix >> > something that was not broken. >> >> > Dewald >> >> > On Nov 17, 3:58 pm, Marcel Molina wrote: >> >> Should appear as a new tweet with the time of the retweet, not the >> >> original tweet creation time. That assumes though that no one else has >> >> retweeted it to you yet. If someone else has then this additional >> >> retweet won't appear in your timelines except for the >> >> statuses/retweets/id resource that lists up to 100 retweets for a >> >> given tweet. Duplicates are collapsed out of the other timelines. >> >> >> On Tue, Nov 17, 2009 at 11:46 AM, Tim Haines wrote: >> >> > Hi guys, >> >> > I'm wondering if anyone can clarify. >> >> > The services I run often shown tweets that are several months old, and >> >> > offer >> >> > the RT button next to them. If someone clicks to RT the tweet, how >> >> > does the >> >> > tweet get presented to people that aren't following the original >> >> > tweeter? >> >> > Is it placed at the top of the timeline appearing as a new tweet, or >> >> > is it >> >> > placed at the time the original tweet was tweeted? i.e. months ago, so >> >> > likely to never be seen? >> >> > If it would be placed months ago, it makes RT pointless for older >> >> > tweets, in >> >> > which case I'll switch to 'classic mode' RT's. >> >> > Tim. >> >> >> -- >> >> Marcel Molina >> >> Twitter Platform Teamhttp://twitter.com/noradio >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] api.twitter.com SSL issue should be resolved now
After doing some righteous spelunking our ops team discovered a small misconfiguration that was very likely the culprit of the intermittent untrusted cert error people were getting when trying to hit api.twitter.com over SSL. This should be all fixed now. To those who reported the problem thank you. Please let us know if you still run into it. We don't think you will be we want to make sure it's totally fixed. Thanks to everyone who's been patient as we ferreted out this subtle problem. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Retweets and the Public Timeline
They are intentionally removed from the user_timeline. On Wed, Nov 18, 2009 at 9:11 AM, Tyson Lowery wrote: > I've noticed that with the new retweet feature, retweets no longer > appear in the user_timeline API calls. Is this intentional or is this > a bug? If it is a bug, any ideas on the expected fix date? I > noticed a lot of complaints about this searching on twitter (like > "hey, retweets don't show up in my XYZ application!") > > If it is intentional, there is no longer a way to get public retweets > using the developer API calls. Unless I am missing something? The > only way I see to do this is through the retweet API calls which > require an authenitcated user. > > Thanks for any help you can provide. I'm trying to get all the > information I can before I start sinking time into writing a fix for > this for my application. > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Lists now have descriptions
You can now add a description to a list. The resources for creating and updating a list via the API now supports a "description" parameter and list payloads will include it as well. All the relevant documentation should be updated to reflect these additions: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-list-id http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-POST-lists http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-POST-lists-id http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-DELETE-list-id http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-lists Let us know if something seems amiss and we hope you enjoy! -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Lists now have descriptions
I've forwarded this along to our i18n team to see what they say. On Wed, Nov 18, 2009 at 4:54 PM, JinS wrote: > it's great! > however it seems cannot accept other asian languages such as Korean. > > On Nov 19, 11:21 am, Marcel Molina wrote: >> You can now add a description to a list. The resources for creating >> and updating a list via the API now supports a "description" parameter >> and list payloads will include it as well. >> >> All the relevant documentation should be updated to reflect these >> additions:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-list-idhttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-POST-listshttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-POST-lists-idhttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-DELETE-list-idhttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-lists >> >> Let us know if something seems amiss and we hope you enjoy! >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Retweet count in status
It's on the todo list. On Wed, Nov 18, 2009 at 4:55 PM, Remy Sharp wrote: > I'm not sure if this has been covered already, so if it has please > point me in the right direction (had a quick search too). > > Once piece of really valuable information on the user timeline against > each status would be the retweet count. Obviously doing this > ourselves via API calls could be expensive (in terms of hits we're > sending), so it makes sense if it were available in the API. > > I can see lots of use for having just the count in there, just as we > have the favorited flag. > > Any chance it's coming? > > Cheers, > > Remy. > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] List creation updated (needs description param)
The description parameter is not required to create a list. On Wed, Nov 18, 2009 at 3:57 PM, David wrote: > I've been using the List api in my app, and just noticed that the POST > method to /:user/lists.:format returned the correct response, but > didn't actually create a list. > > I've been following this api document: > http://apiwiki.twitter.com/Twitter-REST-API-Method:-POST-lists > > What I did notice was that the Add New List ui on Twitter.com has a > description field, and so I tried the same call with an additional > post param "description", and it worked. > > The description param can be empty, but it is required to make this > call work. Might be a bug? > > Just a heads up for anyone who might be wondering. > > DC > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Retweets and the Public Timeline
I don't believe so. Are you working on a javascript widget that makes authentication hard? Why do you want to access it without authenticating? On Wed, Nov 18, 2009 at 1:29 PM, Tyson Lowery wrote: > Thanks for the response. > > Is there a way to get them without authentication? > > On Nov 18, 10:43 am, Marcel Molina wrote: >> They are intentionally removed from the user_timeline. >> >> >> >> >> >> On Wed, Nov 18, 2009 at 9:11 AM, Tyson Lowery wrote: >> > I've noticed that with the new retweet feature, retweets no longer >> > appear in the user_timeline API calls. Is this intentional or is this >> > a bug? If it is a bug, any ideas on the expected fix date? I >> > noticed a lot of complaints about this searching on twitter (like >> > "hey, retweets don't show up in my XYZ application!") >> >> > If it is intentional, there is no longer a way to get public retweets >> > using the developer API calls. Unless I am missing something? The >> > only way I see to do this is through the retweet API calls which >> > require an authenitcated user. >> >> > Thanks for any help you can provide. I'm trying to get all the >> > information I can before I start sinking time into writing a fix for >> > this for my application. >> >> -- >> Marcel Molina >> Twitter Platform Teamhttp://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Retweets and the Public Timeline
That's a compelling point. I need to think about it. We're stripping retweets out of user_timeline because clients that don't implement retweet have the (likely) potential of creating a very confusing experience for users. Removing retweets from the user_timeline at the time seemed fine because clients could merge retweets in using the retweet timelines if they wanted to. Use cases that didn't require authentication weren't being thought about for that scenario. On Wed, Nov 18, 2009 at 5:48 PM, Jeffrey wrote: > Not having retweets in the user_timeline represents a loss of > functionality. > > With user_timeline you can get the tweets of any user using the "id" > parameter, but there is no way to get the tweets of another user using > home_timeline without being authenticated *as that user*. So this > limits the ability of applications to gather info for a user without > requiring them to log in. Before the retweet funcdtionality was > added, "organic" retweets were of course visible. The built-in > retweets are not. > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Retweet API launched to 100% of users
Back in August we announced plans to release the Retweet feature along with an API to publish and consume retweets. Over the last few months we've been gradually opening up the feature to more users as we performance test and refine it. You can see some of the original announcement emails around retweets here: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/1e07e332ec3d449d# http://groups.google.com/group/twitter-api-announce/browse_thread/thread/08540da9d7d64c46# http://groups.google.com/group/twitter-api-announce/browse_thread/thread/3641a248d555da20# http://groups.google.com/group/twitter-api-announce/browse_thread/thread/46928276a4c78df2# Today we've launched the feature to 100% of users. You can now consume retweets via the /statuses/home_timeline resource, as well as all the specialized retweet timelines. For backwards compatibility reasons we're stripping retweets out of the friends_timeline resource as well as the user_timeline resource. If you plan on implementing support for consuming retweets from timelines, switch all instances of /statuses/friends_timeline to /statuses/home_timeline. All the relevant retweet documentation can be found here: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweet http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_timeline http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweeted_by_me http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweeted_to_me http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets_of_me http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets To those implementing this feature in your clients, I'd suggest taking some UI cues from what we've done on Twitter.com: http://s3.amazonaws.com/twitter_production/differentiating-retweets.png Notice how the retweet by @ablegrape of @wblakegray's tweet is clearly differentiated from the surrounding tweets with a distinctive retweet icon and the "Retweeted by" label along the bottom. This is just one way of doing it. Use whatever interface you think makes sense. What's important is communicating to your users that the tweet they are seeing was shared with them by someone they follow so they don't get confused by seeing tweets in their timeline from people they aren't following. We're just getting started with the retweet feature but we're happy with this initial v1 we pushed out. We're really looking forward to seeing how everyone works with this new API. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] French version of twitter.com launched: More translation strings now available
Twitter.com is now available in French: http://bit.ly/twitter-in-french If you're looking to add a French version of your application, we've added some of the translation strings we're using to the translations page on the developer wiki: http://apiwiki.twitter.com/Twitter-String-Translations Hope some find it useful! -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Twitter List API not working?
We are aware of the description parameter being (unintentionally) mandatory right now. We're working on a fix. Thanks. On Tue, Nov 24, 2009 at 2:18 AM, alan_b wrote: > it is just me or everybody else as well? the List API seems down at > the moment > > i tried to create a list using the API > > example: > --- > curl -u user:pass -d "name=friends" > http://api.twitter.com/1/31337geek/lists.xml > > i've got a normal response > --- > > > 3780302 > friends > @31337geek/friends > friends > > 0 > 0 > /31337geek/friends > public > . > > > and then i made a "index" call immediately: > curl -u user:pass http://api.twitter.com/1/31337geek/lists.xml > > i got a empty list: > - > > > > > 0 > 0 > > > > did i call a wrong API? or the API is currently down? > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] List creation updated (needs description param)
The list API requiring a parameter to create/update a list has been fixed and should be deployed today or tomorrow. Thanks everyone who reported this. Sorry about that... On Wed, Nov 18, 2009 at 3:57 PM, David wrote: > I've been using the List api in my app, and just noticed that the POST > method to /:user/lists.:format returned the correct response, but > didn't actually create a list. > > I've been following this api document: > http://apiwiki.twitter.com/Twitter-REST-API-Method:-POST-lists > > What I did notice was that the Add New List ui on Twitter.com has a > description field, and so I tried the same call with an additional > post param "description", and it worked. > > The description param can be empty, but it is required to make this > call work. Might be a bug? > > Just a heads up for anyone who might be wondering. > > DC > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
