from:"alex"


Tim,

We specify full URLs to images so that developers don't have to supply
custom code to pull in profile images and background images. It sounds
like you have a pretty unusual use case for our profile images.

For what it's worth, I think we deployed six variations of those
images, but our front end team may deploy more at any time. Similarly,
they may change up the default profile colors and such. That's out of
the control of our team.

On Tue, Sep 15, 2009 at 04:38, timwhitlock
tim.whitl...@publicreative.com wrote:

 I notice today that Twitter has created a new default profile pic;
 e.g:
 http://s.twimg.com/a/1252980779/images/default_profile_1_normal.png

 Great. That's broken some of my algorithms on Twitblock.org.
 (identifying re-used images)
 I can fix that. I'll just add the new MD5 to my app config.

 But, wait. Did I spot some different colours?
 Yes, that example is only one; e.g.2:
 http://s.twimg.com/a/1252980779/images/default_profile_2_normal.png

 a. Can Twitter tell use how many there are of these?
 b. How about a user object property profile_image_default (true|
 false) ?
 c. How about Twitter start notifying the developer community of
 changes?




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

[twitter-dev] Re: Comments for the group and Twitter staff


Waldron,

We're looking into this issue, but it requires a great deal of
coordination with the folks who work on our back-end infrastructure.
When you ask for a list of denormalized IDs, that request spends very
little time in API code, and most of its time talking to a back-end
system that my team has no control over. We're working with the folks
in charge of that on reliability and better ways for developers to
access that data.

Please understand that the denormalized lists are currently provided
to developers on a best-effort basis. For the vast majority of Twitter
applications, this data isn't necessary. A specialized class of
applications need this data, and we're doing our best to provide it.

On Tue, Sep 15, 2009 at 00:21, Waldron Faulkner
waldronfaulk...@gmail.com wrote:

 Ryan, please look no further than existing, accepted issues in the
 issues list for examples as to how this platform is not yet ready. One
 of your primary API calls, followers/ids (and friends/ids) is broken,
 and has been for more than a week now. Since paging is not working,
 and un-paged requests on accounts with many followers yields fail
 whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and
 it doesn't feel like it's getting any kind of response.

 As I have said repeatedly in this forum and in the issues list, this
 has frozen business development for my fledgling business, which I
 have trusted to the Twitter API. I can't show a broken product. At
 some point, you will put this little dream of mine out of business.
 I'm up late working on my project, which will ultimately add value to
 Twitter's business. I hope your team isn't leaving me high and dry.
 Please tell me I don't have to go do a Facebook app instead. Please
 tell me that someone was working on this over the weekend.

 I'd love to have some solid, no-nonsense response to this, with hard
 dates. So far we've had well-meaning but empty words.

 Thanks,

 - Waldron Faulkner
 Founder, GraphEdge LLC.
 http://graphedge.com

 On Sep 15, 2:59 am, Ryan Sarver rsar...@twitter.com wrote:
 WyoKnott,

 Thanks for your email. We really appreciate the candid feedback and
 definitely is not something we want to see happening. I would like to
 hear more about what you mean by not stable enough and what specific
 issues we can work on that would get you to consider Twitter a
 platform worthy of building your business on.

 I look forward to your feedback.

 Best, Ryan

 On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott mycro...@lifewithindustry.com 
 wrote:

  A few months ago I was introduced to the Twitter API by a prospective
  client who wanted a custom application. I took the time to learn the
  API and wrote a quick and dirty standalone windows app. The project
  fell through (the client could not get financing) but I have continued
  to be a twitter user and have subscribed to this group email. I
  stopped development on the project because the API does not yet seem
  stable enough for me to try to produce a marketable product on my own
  while at the same time chasing an API around. Is my opinion way off
  the mark or are some of the other developers out there feeling the
  same way.

  I am considering restarting development on the project if the Twitter
  API is likely to get more stable in the near future.

  Thanks for tolerating my ravings

  WyoKnott




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

[twitter-dev] Re: Comments for the group and Twitter staff


We're planning on doing just that: communicating more, monitoring the
API via a third-party service from a variety of locales, and providing
better documentation. We've got more developer support hires lined up,
and more.

Thanks for the list of what you'd like to see, and thanks for bearing with us.

On Tue, Sep 15, 2009 at 12:13, zippy_monster alex.zep...@gmail.com wrote:

 On Sep 15, 11:04 am, Alex Payne a...@twitter.com wrote:

 Please understand that the denormalized lists are currently provided
 to developers on a best-effort basis. For the vast majority of Twitter
 applications, this data isn't necessary. A specialized class of
 applications need this data, and we're doing our best to provide it.

 As a developer, implementation details are mainly a recreational
 interest.  My primary concern is the end result (does it work? or
 not?).  Excuses and apologies are nice, but not a substitute for more
 explicit testing and communication.  So far I've run into two
 disruptive changes:

 - Today, for a brief period, API queries were returning twice the
 number of responses they should have.  Instead of showing the proper 6
 DMs, I was getting 12 back.  Oops.

 - Previously, the way POST + OAuth requests were being handled
 changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
 was sending GET arguments with every request (even POST).  For a while
 this worked, but in the past few weeks this broke with no warning.
 Yeah, that was sloppy client-side code, but the documentation was
 silent on this, and certainly the error message (invalid/re-used
 nonce) was not terribly helpful as a proper nonce was being generated
 each time.

 Additionally, Internet rumblings about how OAuth was handled lend
 credence to the idea that the API just isn't terribly stable... both
 from the idea that you're pushing people to use what is officially
 considered an experimental API, and that it's being treated as an
 experimental API (OAuth specific outages for instance).

 Or, the current pagination problems.  The threads I see here seem to
 all be started by API consumers.  What's missing from the picture is
 an announcement from Twitter that some feature is broken.  That smacks
 of really poor (well, non-existent) communication.

 So, yeah, after spending time tracking down the above problems, and
 reading general internet rumblings, my gut feeling is that the Twitter
 API simply isn't terribly stable.  Specifically, I wonder how serious
 Twitter is about testing things in a non-production environment.  If I
 had to propose a solution, it would be to keep a more explicit list
 (blog, regular group postings, whatever) of what changes... even if
 you think it's insignificant.  When something breaks, no matter how
 small, a formal announcement would be great.  If such a thing exists,
 I sure don't know about it.

 The API blog hasn't been updated since July.  The third hit on Google
 for twitter api is a post to this group begging for documentation.
 The API changelog is out there, but it too seems like it's not
 consistently updated.




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

[twitter-dev] Re: Paging STILL broken


Just wanted to follow up on this thread. We've pushed out a change and
associated documentation that should allow for reliable, fast
pagination through lists of denormalized IDs. Please kick the tires on
the new cursor-based pagination:

http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids

On Mon, Sep 14, 2009 at 09:33, Ryan Sarver rsar...@twitter.com wrote:

 Waldron,

 I wish I had an exact ETA for you, but unfortunately these types of
 issues are never simple. As soon as we can identify exactly what is
 causing the problem we should be able to know when it can be resolved.
 I will update you with an ETA as soon as we can.

 Thanks, rs

 On Mon, Sep 14, 2009 at 5:23 AM, Waldron Faulkner
 waldronfaulk...@gmail.com wrote:

 That's awesome, Ryan, thanks. Can I get an ETA on a fix please? This
 is extremely important to my business, I need to know when I can begin
 selling. This bug has caused a delay, because I can't sell a broken
 product, even if it is Twitter's bug and not my own.

 So... ETA??

 Thanks!

 On Sep 13, 5:49 pm, Ryan Sarver rsar...@twitter.com wrote:
 Waldron,

 Thanks for the email. I am working with our team internally to track
 down the issue and figure out how to resolve it. I will get back to
 you with an update shortly, but know that we are listening and working
 on this.

 Best, Ryan

 On Sun, Sep 13, 2009 at 8:55 AM, Waldron Faulkner

 waldronfaulk...@gmail.com wrote:

  PLEASE, can someone on the API team let us know when the paging bug(s)
  with followers/ids (and friends/ids) will be addressed? There have
  been problems with it for weeks, but now it's just downright broken.
  We can't get lists of followers for users with large numbers of
  followers. That's a basic, fundamental API feature that's just BROKEN.
  There's a reproduced, accepted, high priority bug against this issue
  in the issues area, starred by many, and we've had neither a fix,
  nor a comment as to whether it's even being addressed.

  I need to know that I can expect problems with the platform's basic
  functionality to be resolved within a reasonable time-frame. This is
  killing my business development efforts. If Twitter wants people to
  build businesses on this platform, they HAVE to support it.

  PLEASE guys, give us something. Don't make me throw away months of
  work and go focus on something unrelated to Twitter.





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

[twitter-dev] Re: Comments for the group and Twitter staff


The main twitter.com site already uses the API in some places. Our
revised mobile site is built entirely on the API, and our Facebook
application has been built off our API for some time.

Dogfooding! We support it.

On Tue, Sep 15, 2009 at 14:08, Jim Renkel james.ren...@gmail.com wrote:

 I emphatically second and support the idea of twitter.com having to use
 the API.

 We had similar quality problems at a place I formerly worked, and they
 were solved, completely, when such a policy was instituted.

 Yeah, it puts pressure on the API team and may inconvenience the UI
 team, or whatever you call them, but in the long run it will be worth
 it.

 Side effects that we saw were a simpler, cleaner, more consistent
 architecture for the whole system, and lower total costs to develop and
 maintain the system.

 Bite the bullet and do it now. The longer you wait, the more difficult
 and expensive it will be.

 Jim Renkel

 -Original Message-
 From: twitter-development-talk@googlegroups.com
 [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
 Haneda
 Sent: Tuesday, September 15, 2009 15:55
 To: twitter-development-talk@googlegroups.com
 Subject: [twitter-dev] Re: Comments for the group and Twitter staff


 Probably too late for this, but perhaps moving forward, it could be
 done...
 Twitter.com should move to using their own API.  The tools they use to
 power their own site should be the same tools we use and rely on.

 In all reality, this seems a simpler approach, rather than pushing out
 code for their stuff, and then essentially backporting that to an API,
 just work on making the API, and then integrate that into the
 twitter.com site.

 As far as I can tell, this would solve pretty much every problem the
 API has, as there can not be a case where twitter is down, but the API
 is up, or the API is down, and twitter is up.

 Twitter should be eating their own dog food :)
 --
 Scott * If you contact me off list replace talklists@ with scott@ *






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

[twitter-dev] Friends Ids API

2009-09-10 Thread Alex Popescu


Hi guys,

I don't seem to have found any trace of this report before, so I
thought I should post it.

According to the http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends ids
documentation, you can actually get the results using any of the
following 4 URIs:

http://twitter.com/friends/ids/numeric_id.json
http://twitter.com/friends/ids/screen_name.json

http://twitter.com/friends/ids/ids.json?user_id=numeric_id
http://twitter.com/friends/ids/ids.json?screen_name=screen_name

Now, I know this may sound weird or I've just missed this par,  but
the results I'm getting back from the first 2 requests are different
to the ones for the last 2 URIs.

The size of the second result set is significantly smaller than the
first one. As an additional clarification: I am testing these against
an account that doesn't follow more than 5000 users.

2. I have found the first line from the doc a bit confusing:

[q] Returns an array of numeric IDs for every user the specified user
is following.[/q]

I'd suggest rephrasing it to something like:

[q]Returns the array of numeric IDs of all users following the
specified user.[/q]

Looking forward to hearing your comment on the first issue. Thanks in
advance,

./alex

[twitter-dev] Alert: Twitpocalypse II coming Friday, September 11th - make sure you can handle large status IDs!

2009-09-09 Thread Alex Payne


As mentioned previously, the Twitter operations team will artificially
increase the maximum status ID to 4294967296 this coming Friday,
September 11th. This action is part of routine database upgrades and
maintenance.

If your Twitter API application stores status IDs, please be sure that
your datastore is configured to handle integers of that size. Thanks.

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

[twitter-dev] Re: Geocoded OR search broken?

2009-09-09 Thread Alex Payne


Another note: the Search API documentation has been updated to reflect
that querying based on geocode is not compatible with disjunctions (OR
queries).

Please see the Operator Limits section of
http://apiwiki.twitter.com/Twitter-Search-API-Method:-search.

On Wed, Sep 9, 2009 at 11:19, Samuel Luckenbills...@twitter.com wrote:

 Hey Folks,

 The bug is specifically that all queries using the geocode parameter
 with no query string return no results. We'll launch a bug fix today.
 In the interim, you can use the geocode: operator in the query string
 or add a bogus string as someone else has suggested. Sorry for the
 inconvenience and we appreciate your patience.

 Sam

 On Sep 8, 6:25 pm, Jose Tinoco jose.tin...@gmail.com wrote:
 Geocoded API searches are also broken. This is the geocoding example
 from the API documentation, which used to work and now doesn't:

 http://search.twitter.com/search.atom?geocode=40.757929%2C-73.985506%...

 My website (blablabra.net) does similar searches and now receives only
 403 Forbidden errors or an empty XML/JSON with You must enter a
 query if I try this search on my browser window.

 On Sep 8, 10:05 pm, Alex Payne a...@twitter.com wrote:

  Our Search Team informs me that they shipped a new query parser today.
  This is likely a bug in the new parser, and I've let them know about
  it.

  On Tue, Sep 8, 2009 at 17:48, Mack D. Malemaster...@gmail.com wrote:

   Until a couple of hours ago, searching for something like edmonton OR
   #yeg OR near:edmonton  (or the API equivalent) worked just fine. Now
   it doesn't return anything new, and seems to return an odd set of old
   results.

   You can search for them separately, as in edmonton OR #yeg and
   near:edmonton but not together.

   What gives?

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




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

[twitter-dev] Re: Alert: Twitpocalypse II coming Friday, September 11th - make sure you can handle large status IDs!

2009-09-09 Thread Alex Payne


Sorry, an error in phrasing. It was previously mentioned that this
change was pending. We had not previously announced a date for the
change.

Normally, we prefer to provide more advance notice where possible, but
I'm letting you all know immediately after our operations team
informed me that it was necessary to make this change on Friday.

On Wed, Sep 9, 2009 at 12:13, Hwee-Boon Yarhweeb...@gmail.com wrote:

 May I know when and where was it mentioned that it will be
 artificially increased this coming Friday?

 --
 Hwee-Boon

 On Sep 10, 2:49 am, Alex Payne a...@twitter.com wrote:
 As mentioned previously, the Twitter operations team willartificially
 increase the maximum status ID to 4294967296 this coming Friday,
 September 11th. This action is part of routine database upgrades and
 maintenance.

 If your Twitter API application stores status IDs, please be sure that
 your datastore is configured to handle integers of that size. Thanks.

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




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

[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids

2009-09-08 Thread Alex Payne


It hasn't been deployed yet, but it's still gonna happen. Will update
when I know more.

On Tue, Sep 8, 2009 at 13:59, Yu-Shan Fungambivale...@gmail.com wrote:
 I remember reading about this a while back. Has this been deployed yet? The
 wiki doesn't look like it has any info about cursors.
 Thanks!
 Yu-Shan



 On Tue, Aug 4, 2009 at 10:18 AM, Alex Payne a...@twitter.com wrote:

 Once we deprecate the page parameter, it will simply be ignored and
 the method will attempt to return the entire result set.

 On Sun, Aug 2, 2009 at 15:15, janoles...@mobileways.de wrote:
 
  Hi Alex,
 
  In two weeks, we'll be addressing this with a change in back-end
  infrastructure. The page parameter will be replaced with a cursor
 
  does this mean the page parameter won't work anymore after the
  change?
 
  What's happening to those calls to the API still containing the
  page=x parameter?
 
  Cheers
  Ole
 
  --
  Jan Ole Suhr
  s...@mobileways.de
  http://twitter.com/janole
 



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



 --
 “When nothing seems to help, I go look at a stonecutter hammering away at
 his rock perhaps a hundred times without as much as a crack showing in it.
 Yet at the hundred and first blow it will split in two, and I know it was
 not that blow that did it, but all that had gone before.” — Jacob Riis




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

[twitter-dev] Re: Geocoded OR search broken?

2009-09-08 Thread Alex Payne


Our Search Team informs me that they shipped a new query parser today.
This is likely a bug in the new parser, and I've let them know about
it.

On Tue, Sep 8, 2009 at 17:48, Mack D. Malemaster...@gmail.com wrote:

 Until a couple of hours ago, searching for something like edmonton OR
 #yeg OR near:edmonton  (or the API equivalent) worked just fine. Now
 it doesn't return anything new, and seems to return an odd set of old
 results.

 You can search for them separately, as in edmonton OR #yeg and
 near:edmonton but not together.

 What gives?




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

[twitter-dev] Re: 200 errors

2009-09-05 Thread Alex


hi Ryan,
any update on this issue ?

[twitter-dev] Re: Either destroy is/was failing, or my understanding of destroy is/was failing

2009-09-02 Thread Alex Payne


We've got a fix for this going out tomorrow.

On Wed, Sep 2, 2009 at 09:38, Ted Newardted.new...@gmail.com wrote:
 I’ve been hacking on the Twitter API, and I’m running into some serious
 weirdness with destroy.



 I post a message:



 C:\ curl -u name:pass -d status=Testing
 http://twitter.com/statuses/update.xml

 ?xml version=1.0 encoding=UTF-8?

 status

   created_atWed Sep 02 10:10:23 + 2009/created_at

   id3708721364/id

   textTesting/text

   sourcelt;a href=quot;http://apiwiki.twitter.com/quot;
 rel=quot;nofollowquot;gt;APIlt;/agt;/source

   truncatedfalse/truncated

   in_reply_to_status_id/in_reply_to_status_id

   in_reply_to_user_id/in_reply_to_user_id

   favoritedfalse/favorited

   in_reply_to_screen_name/in_reply_to_screen_name

   user

     id70927096/id

     nameTed Neward/name

     screen_nameTestingScitter/screen_name

     location/location

     description/description


 profile_image_urlhttp://s.twimg.com/a/1251845223/images/default_profile_normal.png/profile_image_url

     url/url

     protectedfalse/protected

     followers_count1/followers_count

     profile_background_color9ae4e8/profile_background_color

     profile_text_color00/profile_text_color

     profile_link_colorff/profile_link_color

     profile_sidebar_fill_colore0ff92/profile_sidebar_fill_color

     profile_sidebar_border_color87bc44/profile_sidebar_border_color

     friends_count6/friends_count

     created_atWed Sep 02 09:49:13 + 2009/created_at

     favourites_count0/favourites_count

     utc_offset/utc_offset

     time_zone/time_zone


 profile_background_image_urlhttp://s.twimg.com/a/1251845223/images/themes/theme1/bg.gif/profile_background_image_url

     profile_background_tilefalse/profile_background_tile

     statuses_count4/statuses_count

     notificationsfalse/notifications

     verifiedfalse/verified

     followingfalse/following

   /user

 /status



 … which is all good, but then I try to delete that message:



 C:\ curl -u name:pass --http-request DELETE
 http://twitter.com/statuses/destroy/3708721364.xml

 ?xml version=1.0 encoding=UTF-8?

 hash

   request/statuses/destroy/3708721364.xml/request

   errorWe could not delete that status for some reason./error

 /hash





 What gives? Is this something that I’m doing wrong on my end? Momentary
 server weirdness? (Though it seems to have been pretty consistent all
 night.)



 Ted Neward

 Java, .NET, XML Services

 Consulting, Teaching, Speaking, Writing

 http://www.tedneward.com







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

[twitter-dev] Track API Limit message meaning

2009-08-21 Thread Alex Popescu


Hi guys,

I am currently testing a library for using the track API in order to
make sure that I'm following all the rules exposed on the docs. While
running against the real API I have noticed sporadic messages in the
form:

{limit:{track:121564}}

According to the docs:

[q]Track streams may also contain limitation notices, where the
integer track is an enumeration of statuses that matched the track
predicate but were administratively limited. [/q]

I am not very sure that I'm correctly interpreting the above text as:

1. the track value seems to always be a single value
2. the track value seems to be growing in time
3. the track value doesn't seem to be a twitter message id

Could you please clarify a bit the meaning of these messages?

Many thanks in advance,

./alex

PS: I've asked John (@jkalucki) about this and while I've got an
answer from him (thanks a bunch John), I'm still not sure I'm getting
it.

[twitter-dev] https on twimg.com?

2009-08-18 Thread Alex


Our app uses https during the user session and in order to prevent
errors in some browsers we must make sure that all files (including
images) are loading via https as well.

Up until now we were just taking the profile image URL and swapping
http for https in the URL, and everything worked fine. For example:
https://s3.amazonaws.com/twitter_production/profile_images/52714790/aj_normal.gif

However I am noticing that as profile images get migrated to twimg.com
the SSL is no longer working, and as a result we are not able to load
the images for those users.

For example, @garyvee's profile image is:
http://a3.twimg.com/profile_images/333261519/twitterProfilePhoto_normal.jpg

But it will not load if we request:
https://a3.twimg.com/profile_images/333261519/twitterProfilePhoto_normal.jpg

Do you have plans to support https requests on the twimg.com
subdomains?

Thanks.

[twitter-dev] Service Update for August 17, 2009


All,

Thanks for bearing with us as we continue to fend off a Distributed
Denial of Service (DDoS) attack. In order to help us better assist
you, please supply the following information when reporting API
connectivity and performance issues to a...@twitter.com:

1. The IP of the machine making requests to the Twitter API. If you're
behind NAT, please be sure to send us your *external* IP.

2. The IP address of the machine you're contacting in the Twitter
cluster. You can find this on UNIX machines via the host or
nslookup commands, and on Windows machines via the nbslookup
command.

3. The Twitter API URL (method) you're requesting and any other
details about the request (GET vs. POST, parameters, headers, etc.).

4. Your host operating system, browser (including version), relevant
cookies, and any other pertinent information about your environment.

5. What kind of network connection you have and from which provider,
and what kind of network connectivity devices you're using.

Without this information, we cannot adequately troubleshoot your issue
while responding to the ongoing attack. Thanks for your consideration.

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

[twitter-dev] Re: Issues with the API this morning?


Just sent out an update on the sort of information we need to help you
guys out. We're working on it. Expect things to open up for a bit as
we tune some settings for the next hour.

On Mon, Aug 17, 2009 at 12:07, Sean P.seantpa...@gmail.com wrote:

 I was starting to worry that something was wrong with Twobile (basic
 auth). Any news from the mothership on what's happening?

 On Aug 17, 10:42 am, Aaron Forgue for...@gmail.com wrote:
 My app, too, appears to be blocked. I can't even get status codes -
 the requests just timeout with no response.

 On Aug 17, 12:24 pm, Dewald Pretorius dpr...@gmail.com wrote:

  So, the general message is: Mayhem rules.

  I have no issues with Basic Auth (on low volume API calls). Login no
  problem.

  Dewald

  On Aug 17, 1:04 pm, Sean Callahan seancalla...@gmail.com wrote:

   The issue we're seeing at TweetPhoto is that no one can login to their
   account when using basic auth. Was informed by Twitter support that
   they are aware of the issue and are looking for a fix.






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

[twitter-dev] Re: Platform downtime is expected


There are other threads going about these ongoing issues, including
instructions for what to send us to help troubleshoot.

On Mon, Aug 17, 2009 at 12:41, Adamadamarticul...@gmail.com wrote:

 Hi Ryan,

 Still meeting?  Anxiously waiting since we are now dead in the water
 for 3 days now.

 Thanks.

 Adam

 On Aug 17, 1:39 pm, Ryan Sarver rsar...@twitter.com wrote:
 Everyone,

 I am meeting with Ops right now to get a status update and will follow
 up with the list as soon as we are done.

 Stay tuned.

 Best, Ryan

 On Mon, Aug 17, 2009 at 6:39 AM, jonat...@scribblelivemitc...@gmail.com 
 wrote:

  The Twitter OAuth login is working about 50% of the time for us.
  Sometimes we get failures making the initial request for a token. If
  that works, and the user gets to the Decline/Accept screen, when they
  click Accept the connection often times out before they get a
  response.




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

[twitter-dev] Re: Service Update for August 17, 2009


23 hours ago, we posted this:
http://status.twitter.com/post/164410057/trouble-with-oauth-and-api-clients

On Mon, Aug 17, 2009 at 13:35, Paul McDonaldpaul0...@gmail.com wrote:

 Alex - Is there ANY way you guys could post information to your status
 page that a DDOS or issue is going on?   Something we can point our
 customers to so they don't think it is our service/product?  Right now
 many of my users think the problem is our product, when in fact, it is
 simply the IPs they are coming from being blocked.   This would really
 help out with customer perception of what is going on.

 -paul

 On Aug 17, 3:10 pm, Alex Payne a...@twitter.com wrote:
 All,

 Thanks for bearing with us as we continue to fend off a Distributed
 Denial of Service (DDoS) attack. In order to help us better assist
 you, please supply the following information when reporting API
 connectivity and performance issues to a...@twitter.com:

 1. The IP of the machine making requests to the Twitter API. If you're
 behind NAT, please be sure to send us your *external* IP.

 2. The IP address of the machine you're contacting in the Twitter
 cluster. You can find this on UNIX machines via the host or
 nslookup commands, and on Windows machines via the nbslookup
 command.

 3. The Twitter API URL (method) you're requesting and any other
 details about the request (GET vs. POST, parameters, headers, etc.).

 4. Your host operating system, browser (including version), relevant
 cookies, and any other pertinent information about your environment.

 5. What kind of network connection you have and from which provider,
 and what kind of network connectivity devices you're using.

 Without this information, we cannot adequately troubleshoot your issue
 while responding to the ongoing attack. Thanks for your consideration.

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




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

[twitter-dev] API Changes for August 12, 2009

2009-08-13 Thread Alex Payne

A day late and a bug short...


   - FIXED: /account/verify_credentials no longer enforces a rate limit
   that's inconsistent with the rest of the API.

Thanks.

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

[twitter-dev] Re: Uploaded new pic to Twitter and it isn't showing up

2009-08-13 Thread Alex Payne

This is an intermittent bug as we improve our static asset hosting.
In the future, please use this group for questions that are strictly
API-related. Thanks!

On Thu, Aug 13, 2009 at 11:51, SharayahR handballch...@hotmail.com wrote:


 Ok so every single time I upload a picture to Twitter to change my
 profile pic it never shows up. Just has an X on it. It says it's
 uploaded, but nothing is there. Only one of my pictures works... and
 I'm tired of that one so I wanted to change it. Anything I'm doing
 wrong?? Is this a common problem?




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

[twitter-dev] Re: 401 Unauthorized...

2009-08-12 Thread Alex Payne

To the best of my knowledge, we're not doing any unusual blocking. Rate
limits are as they have been.

On Wed, Aug 12, 2009 at 08:08, AccountingSoftwareGuy virga.rob...@gmail.com
 wrote:


 Is Twitter still blocking posts to the API from non-white listed
 apps?  Since the DDOS attack we can't seem to send any posts through
 the API using oAuth.  Nothing in our code has changed but all was
 working prior to the attack. Is anyone out there havine any success
 sending messages with oauth (non-whitelisted app)???

 Can someone/anyone please comment, I need to get our app working but
 considering our code has not changed I don't want to spend a lot of
 time chasing something down that is not my fault and out of my
 control.

 PLEASE HELP




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

[twitter-dev] Re: Following Churn: Specific guidance needed

An update on this thread: we have an inquiry out to our spam team to get
more information about the metrics they use when policing
mass-following/unfollowing.

On Mon, Aug 10, 2009 at 15:12, IDOLpeeps
belm...@grandcentralholdings.comwrote:


 Twitter recently started suspending accounts which bulk unfollow those
 who don't follow back for Terms of Service Violation (see:

 http://groups.google.com/group/twitter-development-talk/browse_thread/thread/1aeb1f40ff665f78/955da80afd36ca4d?lnk=gstq=follower+churn#955da80afd36ca4d
 ).
 This policy has it's supporters and detractors. What it does not yet
 have is specific guidance describing the specific limitations on bulk
 unfollowing which, when not done for following churn, has it's
 legitimate purposes.

 Heretofore several utility applications provided a bulk unfollow
 function to end users (most commonly as a method of recruiting
 followers by following people in the hope they'd follow back and then
 unfollowing those who didn't) and some real twitter users (ie, not
 spammers) used this method to building their followers.  As there are
 still bona fide rreasons for bulk unfollowing friends, it would be
 extremely helpulf if Twitter can provide more clear guidance about
 what type of bulk unfollowing exactly will flag an account for
 suspension?

 For example, does unfollowing several hundred friends whether they are
 following an account or not constitute the type of bulk unfollowing
 that will get an account suspended?  Popular blogger Robert Scoble
 just had a script unfollow ALL his friends (http://scobleizer.com/
 2009/08/05/you-are-so-unfollowed/) successfully, yet a friend of mine
 unfollowed all his friends and his account was suspended later that
 same day.  And another friend used a third party unfollow script to
 get her friends number below the 2,000 limit and her account was
 suspended.

 What are the specific rules regarding the type, quantity, and timing
 of bulk unfollowing that will result in account suspension?  It's very
 difficult to manage twitter accounts with the specter of seemingly
 arbitrary account suspensions looming without having more specific
 guidance on how TOS are interpreted.




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

[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone

For the case of a dedicated application on a rich mobile platform like
iPhone, I agree that OAuth does not offer a particularly different user
experience. It does, however, provide us at Twitter the information we need
to provide detailed usage analytics back to developers, as well as the data
we need to better understand our platform and help it grow.
OAuth also provides a mechanism for users to revoke access to applications
that aren't behaving as they expected; on the iPhone, removing a misbehaving
application is as simple as deleting it, but for some non-technical users it
may be helpful for them to visit their Twitter settings and see the list of
applications they've authorized.

We're working with our mobile team on improving the iPhone-optimized version
of the OAuth workflow. It may not be an enormous improvement over
password-based authentication, but once it's done, it certainly won't be a
hinderance. Twitter is one of many companies moving to OAuth, and you can
already find iPhone applications like TripIt that rely solely on OAuth for
authentication.

On Mon, Aug 10, 2009 at 14:16, Bradley S. O'Hearne
brad.ohea...@gmail.comwrote:


 All,

 I don't want to kick this subject to death, as there was a lengthy thread
 on general OAuth vs. Basic auth -- I want to restrict this question strictly
 to the scope of iPhone apps. Having pored over the OAuth vs. Basic
 authentication process, I have a question, given the following assumptions:

 - The iPhone app is communicating directly with Twitter, i.e. not through
 some third-party means.

 - The iPhone app requires authentication at the beginning of each
 application runtime (i.e. each time the app is run the user has to type in
 their password).

 - The password is cached only in memory, for the life of that specific
 runtime (i.e. when the user quits the app, the password is released).

 - The password is NEVER persisted anywhere, i.e. never stored to disk.

 - All network communication with Twitter takes place over HTTPS.

 If all of those things are true in an iPhone app, how is OAuth superior in
 any way to basic authentication from a security standpoint? Furthermore,
 given having to introduce a foreign UI element and extra authentication
 steps over the web, could OAuth even be considered inferior when evaluated
 as a whole as an authentication means for the iPhone, when app branding,
 integration, and ease of use are considered?

 Mind you, the purpose of this post is not in any way to incite a religious
 war or stir the pot, it is to definitively establish the true pros and cons
 of each authentication means within the specific use case of the iPhone
 only. Many of the other OAuth / Basic auth threads are somewhat overridden
 with personally charged statements that I'd rather ignore them.

 Anyway, your constructive views are most appreciated.

 Regards,

 Brad





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

[twitter-dev] Re: Format of 'favorite status' URL

Even if passing id as a parameter works, it's not the documented behavior
and isn't guaranteed to be supported indefinitely. Please specify IDs
in-URL.

On Tue, Aug 11, 2009 at 02:37, Mariusz mariusz...@gmail.com wrote:


 Hi

 I am making small Twitter client in Java. Currently I make option
 'farourite status' and I have a strange problem.

 I always use format of url like this (for example for 'follow user'):

 http://twitter.com/friendships/create.json?id=

 It works well in almost all cases. However it doesn't work in
 'favourite status'. If I try:

 http://twitter.com/favorites/create.json?id=11

 I will get error. But if I try:

 http://twitter.com/favorites/create/11.json

 everything works well.

 Could somebody tell me why I can't use first way of the URL? I would
 like to use link with parameters after '?' character. Why doesn't it
 work in 'favorite status'?

 Mariusz




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

[twitter-dev] Re: External API Team App Test Site

One of the projects on our list is a continuous testing system, running from
a machine outside our cluster. We have the test suite built to do it, just
not the production-safe fixture data.

On Mon, Aug 10, 2009 at 10:20, Dewald Pretorius dpr...@gmail.com wrote:


 Does the API team have a test third-party app, from where you can
 experience and test the API from a consumer's perspective?

 If not, I think it may be helpful to you to have something like that.
 You don't need to run it at full stress all the time.

 When you roll out a mod to the API, or at times like these, you can
 run tests and do detail logging. That will enable you to detect and
 fix issues long before we start yelling at you.

 Dewald




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

[twitter-dev] Re: TwitterLand - Ruby wrapper for many Twitter-related APIs

Very cool! Thanks much. I've added it to
http://apiwiki.twitter.com/Libraries#Ruby

On Mon, Aug 10, 2009 at 10:18, Wynn Netherland wynn.netherl...@gmail.comwrote:


 I'd like to thank those of you who have released your own APIs for the
 apps you've built on top of Twitter. If you're using Ruby, we've
 bundled up our wrappers for many of them into a new gem called
 TwitterLand. Please check it out and let us know if you'd like to see
 new APIs added or fork us on GitHub and contribute.


 http://www.rubyinside.com/twitterland-5-twitter-data-apis-in-a-single-gem-2215.html

 Thanks,

 Wynn Netherland
 // @pengwynn




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

[twitter-dev] Re: Tweepy -- python library

Thanks for your library, Josh! I've added it to
http://apiwiki.twitter.com/Libraries#Python

On Mon, Aug 10, 2009 at 09:50, Josh Roesslein jroessl...@gmail.com wrote:

 Hello twitter developers:

 Just posting here to announce a library for python I have been putting
 together.
 It supports pretty much the entire twitter API's endpoints. This includes
 the search
 and streaming APIs. The library also works fine with OAuth authentication.

 I have the library hosted here: http://gitorious.org/tweepy
 or if you are on Github: http://github.com/joshthecoder/tweepy

 If you are searching for a python library for twitter check it out.
 If you have any questions ask here or on twe...@googegroups.com

 Also if someone with write permission on the api wiki could list my library
 under the python category I would much appreciate it.

 Thank you for your time and hope you enjoy this library and find it useful.

 Josh




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

[twitter-dev] Timeouts and API Errors, Tuesday August 11th

We're currently experiencing another wave of Distributed Denial of Service
(DDoS) attacks against our system. Expect periodic slowness and errors until
the attack passes or is countered by our operations team and hosting
provider. Updates will be provided as we get them.
Thanks for your patience.

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

[twitter-dev] Re: Timeouts and API Errors, Tuesday August 11th

Our operations staff has informed me that the attack ceased several minutes
ago. Site performance should be returning to normal.

On Tue, Aug 11, 2009 at 12:23, Alex Payne a...@twitter.com wrote:

 We're currently experiencing another wave of Distributed Denial of Service
 (DDoS) attacks against our system. Expect periodic slowness and errors until
 the attack passes or is countered by our operations team and hosting
 provider. Updates will be provided as we get them.
 Thanks for your patience.

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




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

[twitter-dev] Re: created_at format

We do intend to move to unified format. This inconsistency is the result of
the Search system being developed independently of Twitter before it was
acquired.

On Tue, Aug 11, 2009 at 13:33, Jonas boxnumbe...@gmail.com wrote:


 I am using search.json and track.json and I noticed that the date
 format for created_at is different.

 search.json: Tue, 11 Aug 2009 20:23:36 +
 track.json: Tue Aug 11 20:23:36 + 2009

 Is there a reason why Twitter uses different formats for the same
 information?

 Is there any interest in using just one format?  I would prefer the
 format outputted by search.json because it is easily parsed by the
 DateTime object in .NET.




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

[twitter-dev] Re: Timeouts and API Errors, Tuesday August 11th

Yes, I've just been informed that the attack has resumed, and that our
service provider is putting network hardware in place to counter the attack.
We're trying to work with them to ensure minimal impact to the API, but in
the near term there may be issues with OAuth and the Streaming API.
This is a bit of a juggling act, as we're trying to coordinate our team, the
operations team, our service provider's staff, and specialists that they've
brought in for this issue. Please bear with us.

On Tue, Aug 11, 2009 at 13:54, Dewald Pretorius dpr...@gmail.com wrote:


 My guess is it's still ongoing. I'm seeing far more rejections per
 second, and the number of backed-off retries have also increased.

 Dewald

 On Aug 11, 5:37 pm, Andrew Badera and...@badera.us wrote:
  On Tue, Aug 11, 2009 at 4:11 PM, Alex Paynea...@twitter.com wrote:
   Our operations staff has informed me that the attack ceased several
 minutes
   ago. Site performance should be returning to normal.
 
   On Tue, Aug 11, 2009 at 12:23, Alex Payne a...@twitter.com wrote:
 
   We're currently experiencing another wave of Distributed Denial of
 Service
   (DDoS) attacks against our system. Expect periodic slowness and errors
 until
   the attack passes or is countered by our operations team and hosting
   provider. Updates will be provided as we get them.
   Thanks for your patience.
 
   --
   Alex Payne - Platform Lead, Twitter, Inc.
  http://twitter.com/al3x
 
  Has it resumed? Still getting lots of intermittency here.
 
  ∞ Andy Badera
  ∞ This email is: [ ] bloggable [x] ask first [ ] private
  ∞ Google me:
 http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera)




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

[twitter-dev] Re: Seeing same login issues right now as when DDoD happened

Please see the other thread in this group.

On Tue, Aug 11, 2009 at 13:55, Sean Callahan seancalla...@gmail.com wrote:


 I've tried logging into a handful of sites built around the Twitter
 API without success. I'm seeing the same login issues right now as
 when the DDoD happened. Twitter is aware of the downtime issue on
 their status page, http://status.twitter.com, but are they aware of
 the API issues (e.g., being able to login)?

 Sean




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

[twitter-dev] Re: Timeouts and API Errors, Tuesday August 11th

We're aware of these issues; sorry.
Our ops team tells me that the countermeasures that are being put in place
should not cause the 302 redirect behavior that impacted OAuth and other
services late last week. If you're seeing that behavior, please post here
and we'll coordinate with them to eliminate it.

On Tue, Aug 11, 2009 at 13:58, Sean Callahan seancalla...@gmail.com wrote:


 Alex,

 Did not see this post and posted a new message. Still receiving lots
 of errors and no one can login on our site, tweetphoto.com, right now
 along with a handful of others (that I've tried myself). Just wanted
 to give you a heads up. Thanks!

 Sean

 On Aug 11, 1:11 pm, Alex Payne a...@twitter.com wrote:
  Our operations staff has informed me that the attack ceased several
 minutes
  ago. Site performance should be returning to normal.
 
  On Tue, Aug 11, 2009 at 12:23, Alex Payne a...@twitter.com wrote:
   We're currently experiencing another wave of Distributed Denial of
 Service
   (DDoS) attacks against our system. Expect periodic slowness and errors
 until
   the attack passes or is countered by our operations team and hosting
   provider. Updates will be provided as we get them.
   Thanks for your patience.
 
   --
   Alex Payne - Platform Lead, Twitter, Inc.
  http://twitter.com/al3x
 
  --
  Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x




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

[twitter-dev] Re: Timeouts and API Errors, Tuesday August 11th

Just found out that our hosting provider put some hardware in place that may
cause disruptions. Our operations team just spoke them, and they should be
taking it down in 15 - 30 minutes.

On Tue, Aug 11, 2009 at 14:03, Andrew Badera and...@badera.us wrote:


 On Tue, Aug 11, 2009 at 5:01 PM, Andrew Baderaand...@badera.us wrote:
  On Tue, Aug 11, 2009 at 4:57 PM, Alex Paynea...@twitter.com wrote:
  Yes, I've just been informed that the attack has resumed, and that our
  service provider is putting network hardware in place to counter the
 attack.
  We're trying to work with them to ensure minimal impact to the API, but
 in
  the near term there may be issues with OAuth and the Streaming API.
  This is a bit of a juggling act, as we're trying to coordinate our team,
 the
  operations team, our service provider's staff, and specialists that
 they've
  brought in for this issue. Please bear with us.
 
 
 
  Thanks for the update Alex. No worries here, you all seem to be
  keeping us much more comfortably updated than most of Friday.
 
  --ab
 


 *Thursday, not Friday




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

[twitter-dev] Re: php curl api calls no returns about 90% of the time

If you include the full headers in your response output, that would be
helpful in tracking this down.

On Tue, Aug 11, 2009 at 17:17, freefall tehgame...@googlemail.com wrote:


 It's quite impressive but I get nothing back from most of the curl api
 request I make to twitter. Fully whitelisted on ip, lots of ratelimit
 spare, total failures from twitter all the time.

 A new favourite appeared today from a
 http://twitter.com/friends/ids/accountname.xml
 get:
 ?xml version=1.0 encoding=UTF-8 ?
  ids /


 I'd love to know why this is happening, anyone got any ideas?

 Thanks




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

[twitter-dev] Re: Updating the APIs authentication limiting policy

2009-08-06 Thread Alex Payne


We've just heard from our operations and deploy staff that we won't be
able to deploy any code (for the API or otherwise) until Monday due to
the DDoS attack and other issues. That means that the revert to the
old rate limiting policy for this method won't go out this week. My
apologies.

On Thu, Aug 6, 2009 at 02:43, Goblinstu...@abovetheinternet.org wrote:

 Alex, is that *not* estimated or was it an iPhone being daft and
 changing now to not?

 On Aug 5, 7:11 pm, Alex Payne a...@twitter.com wrote:
 The change did not go live yesterday due to some deploy issues. It's
 not estimated to go out tomorrow. Once again, sorry for the delay.



 On Wed, Aug 5, 2009 at 07:48, Dewald Pretoriusdpr...@gmail.com wrote:

  Alex,

  Did the change go live on Tuesday?

  I have very irate users due to this issue. There are spam bots out
  there that got hold of users' credentials. The users have changed
  their Twitter passwords to get rid of the spam tweets published in
  their timelines, but now those bots are locking them out 24x7 from all
  apps that use the API.

  On Aug 3, 2:56 pm, Alex Payne a...@twitter.com wrote:
  The rollback should be deployed tomorrow. Sorry for the delay.

  On Sat, Aug 1, 2009 at 23:36, Jesse Stayjesses...@gmail.com wrote:
   A timeframe would be very helpful. This is turning out to be a headache 
   as
   I'm testing. If my own user is having to log in over and over to test my
   app, I'm quickly hitting the verify_credentials limit (and I'm even 
   using
   OAuth).  I'm getting really frustrated.
   Jesse

   On Fri, Jul 31, 2009 at 8:01 PM, Bob Thomson stormid...@googlemail.com
   wrote:

   Hi Doug,

   Is there a timescale for rolling back / making the change to the new
   scheme?

   We're just putting the finishing touches to moving to OAuth and we're
   experiencing the issue when using verify_credentials to get the users
   basic details once we've got the token back from the authentication
   process. We're experiencing the issue when:

   1. Testing our login and authentication processes
   2. When users login and logout of our application frequently

   A heads up on when these changes will be made would be useful. Thanks,

   Bob

   On Jul 29, 6:37 pm, Grant Emsley grant.ems...@gmail.com wrote:
Locked out of authenticated resources for that account, or will that
IP not be able to login to any account?

On Jul 29, 1:14 pm, Doug Williams d...@twitter.com wrote:

 Ray,For clarity, we will roll back the current restriction of 15 
 calls
 per
 user per hour to account/verify_credentials, and implement the
 proposed
 scheme:

  ... we will limit the total number of unsuccessful
  attempts to access authenticated resources to 15 an hour per user
  per IP
  address. If a single IP address makes 15 attempts to access a
  protected resource unsuccessfully for a given user (as indicated 
  by
  an
 HTTP 401),
  then the user will be locked out of authenticated resources from
  that
  IP address for 1 hour.

 Thanks,
 Doug

 On Wed, Jul 29, 2009 at 9:51 AM, Ray rvizz...@testlabs.com wrote:

  Doug,

  I'm in a similar situation as that voiced by TinBlue.  This 
  change
  has
  affected our iPhone App.  We also want to encourage you to 
  rollback
  this change ASAP.

  When you say This approach is what we are going to take., do 
  you
  mean rolling back the fix so as not to affect multiple, 
  successful,
  authorized logins?  I'm hopeful that this approach means that 
  our
  apps will not be affected yet again by changing to a new auth
  approach.

  I appreciate you all keeping this thread informed.

  Ray

  On Jul 27, 11:23 am, Doug Williams d...@twitter.com wrote:
   Thanks to everyone who has contributed feedback. This approach 
   is
   what we
   are going to take.
   Alex will be making this change shortly. I will update this 
   thread
   when
   there is timeframe to share.

   Thanks,
   Doug

   On Mon, Jul 27, 2009 at 7:52 AM, TinBlue tinb...@gmail.com
   wrote:

What is happening?

This rollback is taking far too long for something that has
affected a
lot of people!

On Jul 25, 2:32 pm, Dewald Pretorius dpr...@gmail.com 
wrote:
 Doug,

 I would prefer to adopt OAuth instead of writing code for
 Basic Auth.

 So, you guys need to move OAuth out of public beta into 
 full
 production sooner rather than later. :-)

 I manage 100,000+ Twitter accounts, and I simply cannot 
 take
 on the
 support workload of answering user tickets when there's a 
 snag
 with
 OAuth beta.

 I monitor these forums and the API Issues and still see too
 many
  OAuth
 issues being reported to give me

[twitter-dev] Re: API Calls During DoS Attack

2009-08-06 Thread Alex Payne


We're talking to our operations team about it, who in turn is talking
to our hosting provider. It seems that some aggressive IP filtering
may have been catching some web-based third-party Twitter
applications, as well as data centers used by mobile providers.

On Thu, Aug 6, 2009 at 12:52, Jonathantwitcaps.develo...@gmail.com wrote:

 I would also appreciate an answer to this question. My calls to the
 Search API are failing because of circular redirection, and

     curl http://twitter.com

 returns nothing at all from my production server, which seems like a
 sign that its IP has been blocked.

 My app works fine from my dev box.

 -jonathan

 On Aug 6, 1:35 pm, Dewald Pretorius dpr...@gmail.com wrote:
 Chad,

 I know it's a little late in asking, but should we switch off cron
 jobs that make a lot of API calls while this DoS is going on, or while
 you are recovering from it?

 I don't want my IP addresses to be blocked because they are making a
 lot of calls! I've seen in the past that Ops lay down carpet bombing
 with cluster munitions when under attack.

 Will it help you to recover if we switched off the cron jobs?

 Right now most of my connections are just being refused.

 Do you guys at least check against the list of white listed IP
 addresses before you block an IP address in times like these?

 Will there be innocent bystanders caught in the cross-fire again?

 This is the kind of info that we developers need...

 Dewald




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

[twitter-dev] Re: rate limit has reverted from 20000 to 150 for my IPs...

2009-08-06 Thread Alex Payne


Things are going to be a little wonky until we're out of the woods on
this DDoS attack.

On Thu, Aug 6, 2009 at 13:51, Haewoonhaewoon.k...@gmail.com wrote:

 me, too.

 In my case, one of 10 IPs has reverted.

 On Aug 7, 5:43 am, chinaski007 chinaski...@gmail.com wrote:
 Even worse... IPs are showing 0/150 remaining hits constantly, thus
 bringing my app to a total HALT.

 On Aug 6, 1:39 pm, chinaski007 chinaski...@gmail.com wrote:



  UGH!  All of my whitelisted IPs have reverted from 20k/hour limit to a
  150/hour limit.

  Anyone else??

  What the heck?!




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

[twitter-dev] Re: Updating the APIs authentication limiting policy

2009-08-05 Thread Alex Payne


The change did not go live yesterday due to some deploy issues. It's
not estimated to go out tomorrow. Once again, sorry for the delay.

On Wed, Aug 5, 2009 at 07:48, Dewald Pretoriusdpr...@gmail.com wrote:

 Alex,

 Did the change go live on Tuesday?

 I have very irate users due to this issue. There are spam bots out
 there that got hold of users' credentials. The users have changed
 their Twitter passwords to get rid of the spam tweets published in
 their timelines, but now those bots are locking them out 24x7 from all
 apps that use the API.


 On Aug 3, 2:56 pm, Alex Payne a...@twitter.com wrote:
 The rollback should be deployed tomorrow. Sorry for the delay.

 On Sat, Aug 1, 2009 at 23:36, Jesse Stayjesses...@gmail.com wrote:
  A timeframe would be very helpful. This is turning out to be a headache as
  I'm testing. If my own user is having to log in over and over to test my
  app, I'm quickly hitting the verify_credentials limit (and I'm even using
  OAuth).  I'm getting really frustrated.
  Jesse

  On Fri, Jul 31, 2009 at 8:01 PM, Bob Thomson stormid...@googlemail.com
  wrote:

  Hi Doug,

  Is there a timescale for rolling back / making the change to the new
  scheme?

  We're just putting the finishing touches to moving to OAuth and we're
  experiencing the issue when using verify_credentials to get the users
  basic details once we've got the token back from the authentication
  process. We're experiencing the issue when:

  1. Testing our login and authentication processes
  2. When users login and logout of our application frequently

  A heads up on when these changes will be made would be useful. Thanks,

  Bob

  On Jul 29, 6:37 pm, Grant Emsley grant.ems...@gmail.com wrote:
   Locked out of authenticated resources for that account, or will that
   IP not be able to login to any account?

   On Jul 29, 1:14 pm, Doug Williams d...@twitter.com wrote:

Ray,For clarity, we will roll back the current restriction of 15 calls
per
user per hour to account/verify_credentials, and implement the
proposed
scheme:

 ... we will limit the total number of unsuccessful
 attempts to access authenticated resources to 15 an hour per user
 per IP
 address. If a single IP address makes 15 attempts to access a
 protected resource unsuccessfully for a given user (as indicated by
 an
HTTP 401),
 then the user will be locked out of authenticated resources from
 that
 IP address for 1 hour.

Thanks,
Doug

On Wed, Jul 29, 2009 at 9:51 AM, Ray rvizz...@testlabs.com wrote:

 Doug,

 I'm in a similar situation as that voiced by TinBlue.  This change
 has
 affected our iPhone App.  We also want to encourage you to rollback
 this change ASAP.

 When you say This approach is what we are going to take., do you
 mean rolling back the fix so as not to affect multiple, successful,
 authorized logins?  I'm hopeful that this approach means that our
 apps will not be affected yet again by changing to a new auth
 approach.

 I appreciate you all keeping this thread informed.

 Ray

 On Jul 27, 11:23 am, Doug Williams d...@twitter.com wrote:
  Thanks to everyone who has contributed feedback. This approach is
  what we
  are going to take.
  Alex will be making this change shortly. I will update this thread
  when
  there is timeframe to share.

  Thanks,
  Doug

  On Mon, Jul 27, 2009 at 7:52 AM, TinBlue tinb...@gmail.com
  wrote:

   What is happening?

   This rollback is taking far too long for something that has
   affected a
   lot of people!

   On Jul 25, 2:32 pm, Dewald Pretorius dpr...@gmail.com wrote:
Doug,

I would prefer to adopt OAuth instead of writing code for
Basic Auth.

So, you guys need to move OAuth out of public beta into full
production sooner rather than later. :-)

I manage 100,000+ Twitter accounts, and I simply cannot take
on the
support workload of answering user tickets when there's a snag
with
OAuth beta.

I monitor these forums and the API Issues and still see too
many
 OAuth
issues being reported to give me a level of comfort that I can
safely
switch over to OAuth.

On Jul 24, 5:46 pm, Doug Williams d...@twitter.com wrote:

 Well said Joshua.

 Dewald, you have identified the risk of using basic
 authentication.
 If
 your users being locked out due to malicious behavior, you
 should
 either implement further user-level rate limiting on your
 side or
 adopt OAuth.

 Are there any other glaring omissions in our thinking or
 should we
 proceed with this as our solution?

 Thanks,
 Doug

 On Fri, Jul 24, 2009 at 11:08 AM, Joshua
 Perryj...@6bit.com
 wrote

[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids


Graphs of more than several thousand users, following or followed by.

On Fri, Jul 31, 2009 at 11:09, Arik Fraimovicharik...@gmail.com wrote:



 On Jul 31, 9:03 pm, Alex Payne a...@twitter.com wrote:
 To clarify, since several people have asked: this pending change does
 NOT mean that pagination is required. You can still attempt to
 retrieve all IDs in one call, but be aware that this is likely to time
 out or fail for users with large social graphs.

 What is defined as large social graphs?

 --
 Arik Fraimovich
 follow me on twitter: http://twitter.com/arikfr




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

[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids

What our infrastructure team has told me is that they can support both
behaviors for a limited period of time.

On Fri, Jul 31, 2009 at 12:06, Isaiahsupp...@yourhead.com wrote:

First off, thanks for the heads up and giving us a large lead time. It's
what I asked for in a previous email, and even if you never read that email
and this isn't a response to me at all. I'll say thanks anyway, because
it's great. :-)
But, forgive me if I'm off base, but you're
saying this change is going to happen just like a switch. One minute the
API will behave one way, then next minute the API will behave differently?
Doesn't this level of behavior change merit a bit of a deprecation period where both behaviors function?
After a sudden change any app still using the old behavior is guaranteed to
fail. If the app fixes early then it will fail up until the api change. In
other words, ALL APPS that use this api call WILL be guaranteed to FAIL for
some period of time. That seems like a pretty ugly prospect.
Many api temper this sort of change in behavior by adding a new method call
or a new argument to the method call. And for some period of time letting
both function while marking the old method deprecated, use at the risk of
being abandoned without warning at the next update. This lets apps update
from one functioning call to another functioning call without users
experiencing any downtime.
I understand that some changes might need to be rolled in quickly to avert
infrastructure disaster or to patch security holes, but with 2 weeks notice,
I'm guessing that's not what we're dealing with here.
Isaiah
YourHead Software
supp...@yourhead.com
http://www.yourhead.com

On Jul 31, 2009, at 11:09 AM, Arik Fraimovich wrote:

On Jul 31, 9:03 pm, Alex Payne a...@twitter.com wrote:

To clarify, since several people have asked: this pending change does

NOT mean that pagination is required. You can still attempt to

retrieve all IDs in one call, but be aware that this is likely to time

out or fail for users with large social graphs.

What is defined as large social graphs?

--
Arik Fraimovich
follow me on twitter: http://twitter.com/arikfr

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

[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids


It will be a hash with 'ids' as one of the elements.

On Sat, Aug 1, 2009 at 18:26, Dewald Pretoriusdpr...@gmail.com wrote:

 Alex,

 For non-paged calls, will the result set be  [1,2,3,...] or will it be
 {ids: [1,2,3]} ?

 Dewald

 On Jul 31, 3:03 pm, Alex Payne a...@twitter.com wrote:
 To clarify, since several people have asked: this pending change does
 NOT mean that pagination is required. You can still attempt to
 retrieve all IDs in one call, but be aware that this is likely to time
 out or fail for users with large social graphs.



 On Fri, Jul 31, 2009 at 10:35, Alex Paynea...@twitter.com wrote:
  The Twitter API currently has two methods for returning a user's
  denormalized social graph: /friends/ids [1] and /followers/ids [2].
  These methods presently allow pagination by use of a ?page=n
  parameter; without that parameter, they attempt to return all user IDs
  in the specified set. If you've used this methods, particularly for
  exploring the social graphs of users that are following or followed by
  a large number of other users, you've probably run into lag and server
  errors.

  In two weeks, we'll be addressing this with a change in back-end
  infrastructure. The page parameter will be replaced with a cursor
  parameter, which in turn will result in a change in the response
  bodies for these two methods. Whereas currently you'd receive an array
  response like this (in JSON):

   [1,2,3,...]

  You will now receive:

   {ids: [1,2,3], next_id: 1231232}

  You can then use the next_id value to paginate through the set:

   /followers/ids.json?cursor=1231232

  To start paginating:

   /followers/ids.json?cursor=-1

  The negative one (-1) indicates that you want to begin paginating.
  When the next_id value is zero (0), you're at the last page.

  Documentation of the new functionality will, of course, be provided on
  the API Wiki in advance of the change going live. If you have any
  questions or concerns, please contact us as soon as possible.

  [1] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids
  [2] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids

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

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




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

[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids


Once we deprecate the page parameter, it will simply be ignored and
the method will attempt to return the entire result set.

On Sun, Aug 2, 2009 at 15:15, janoles...@mobileways.de wrote:

 Hi Alex,

 In two weeks, we'll be addressing this with a change in back-end
 infrastructure. The page parameter will be replaced with a cursor

 does this mean the page parameter won't work anymore after the
 change?

 What's happening to those calls to the API still containing the
 page=x parameter?

 Cheers
 Ole

 --
 Jan Ole Suhr
 s...@mobileways.de
 http://twitter.com/janole




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

[twitter-dev] Re: Updating the APIs authentication limiting policy

2009-08-03 Thread Alex Payne


The rollback should be deployed tomorrow. Sorry for the delay.

On Sat, Aug 1, 2009 at 23:36, Jesse Stayjesses...@gmail.com wrote:
 A timeframe would be very helpful. This is turning out to be a headache as
 I'm testing. If my own user is having to log in over and over to test my
 app, I'm quickly hitting the verify_credentials limit (and I'm even using
 OAuth).  I'm getting really frustrated.
 Jesse

 On Fri, Jul 31, 2009 at 8:01 PM, Bob Thomson stormid...@googlemail.com
 wrote:

 Hi Doug,

 Is there a timescale for rolling back / making the change to the new
 scheme?

 We're just putting the finishing touches to moving to OAuth and we're
 experiencing the issue when using verify_credentials to get the users
 basic details once we've got the token back from the authentication
 process. We're experiencing the issue when:

 1. Testing our login and authentication processes
 2. When users login and logout of our application frequently

 A heads up on when these changes will be made would be useful. Thanks,

 Bob

 On Jul 29, 6:37 pm, Grant Emsley grant.ems...@gmail.com wrote:
  Locked out of authenticated resources for that account, or will that
  IP not be able to login to any account?
 
  On Jul 29, 1:14 pm, Doug Williams d...@twitter.com wrote:
 
   Ray,For clarity, we will roll back the current restriction of 15 calls
   per
   user per hour to account/verify_credentials, and implement the
   proposed
   scheme:
 
... we will limit the total number of unsuccessful
attempts to access authenticated resources to 15 an hour per user
per IP
address. If a single IP address makes 15 attempts to access a
protected resource unsuccessfully for a given user (as indicated by
an
   HTTP 401),
then the user will be locked out of authenticated resources from
that
IP address for 1 hour.
 
   Thanks,
   Doug
 
   On Wed, Jul 29, 2009 at 9:51 AM, Ray rvizz...@testlabs.com wrote:
 
Doug,
 
I'm in a similar situation as that voiced by TinBlue.  This change
has
affected our iPhone App.  We also want to encourage you to rollback
this change ASAP.
 
When you say This approach is what we are going to take., do you
mean rolling back the fix so as not to affect multiple, successful,
authorized logins?  I'm hopeful that this approach means that our
apps will not be affected yet again by changing to a new auth
approach.
 
I appreciate you all keeping this thread informed.
 
Ray
 
On Jul 27, 11:23 am, Doug Williams d...@twitter.com wrote:
 Thanks to everyone who has contributed feedback. This approach is
 what we
 are going to take.
 Alex will be making this change shortly. I will update this thread
 when
 there is timeframe to share.
 
 Thanks,
 Doug
 
 On Mon, Jul 27, 2009 at 7:52 AM, TinBlue tinb...@gmail.com
 wrote:
 
  What is happening?
 
  This rollback is taking far too long for something that has
  affected a
  lot of people!
 
  On Jul 25, 2:32 pm, Dewald Pretorius dpr...@gmail.com wrote:
   Doug,
 
   I would prefer to adopt OAuth instead of writing code for
   Basic Auth.
 
   So, you guys need to move OAuth out of public beta into full
   production sooner rather than later. :-)
 
   I manage 100,000+ Twitter accounts, and I simply cannot take
   on the
   support workload of answering user tickets when there's a snag
   with
   OAuth beta.
 
   I monitor these forums and the API Issues and still see too
   many
OAuth
   issues being reported to give me a level of comfort that I can
   safely
   switch over to OAuth.
 
   On Jul 24, 5:46 pm, Doug Williams d...@twitter.com wrote:
 
Well said Joshua.
 
Dewald, you have identified the risk of using basic
authentication.
If
your users being locked out due to malicious behavior, you
should
either implement further user-level rate limiting on your
side or
adopt OAuth.
 
Are there any other glaring omissions in our thinking or
should we
proceed with this as our solution?
 
Thanks,
Doug
 
On Fri, Jul 24, 2009 at 11:08 AM, Joshua
Perryj...@6bit.com
wrote:
 
 Jim's concern is valid, fortunately OAuth is immune to
brute-force
  attacks
 once the access key has been issued to an application. For
 this
  reason alone
 I would urge people to switch to OAuth if at all possible.
  I
would
  hope
 (and assume) that if login attempts for an account are
 locked out
  that a
 user would still be able to successfully use an already
authorized
  OAuth
 driven application.
 
 Unfortunately allowing a successful un/pw login while an
 account
is
  locked
 out even when the correct password is presented

[twitter-dev] 2 week advance notice: changes to /friends/ids and /followers/ids

2009-07-31 Thread Alex Payne


The Twitter API currently has two methods for returning a user's
denormalized social graph: /friends/ids [1] and /followers/ids [2].
These methods presently allow pagination by use of a ?page=n
parameter; without that parameter, they attempt to return all user IDs
in the specified set. If you've used this methods, particularly for
exploring the social graphs of users that are following or followed by
a large number of other users, you've probably run into lag and server
errors.

In two weeks, we'll be addressing this with a change in back-end
infrastructure. The page parameter will be replaced with a cursor
parameter, which in turn will result in a change in the response
bodies for these two methods. Whereas currently you'd receive an array
response like this (in JSON):

  [1,2,3,...]

You will now receive:

  {ids: [1,2,3], next_id: 1231232}

You can then use the next_id value to paginate through the set:

  /followers/ids.json?cursor=1231232

To start paginating:

  /followers/ids.json?cursor=-1

The negative one (-1) indicates that you want to begin paginating.
When the next_id value is zero (0), you're at the last page.

Documentation of the new functionality will, of course, be provided on
the API Wiki in advance of the change going live. If you have any
questions or concerns, please contact us as soon as possible.

[1] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids
[2] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids

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

[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids

2009-07-31 Thread Alex Payne


To clarify, since several people have asked: this pending change does
NOT mean that pagination is required. You can still attempt to
retrieve all IDs in one call, but be aware that this is likely to time
out or fail for users with large social graphs.

On Fri, Jul 31, 2009 at 10:35, Alex Paynea...@twitter.com wrote:
 The Twitter API currently has two methods for returning a user's
 denormalized social graph: /friends/ids [1] and /followers/ids [2].
 These methods presently allow pagination by use of a ?page=n
 parameter; without that parameter, they attempt to return all user IDs
 in the specified set. If you've used this methods, particularly for
 exploring the social graphs of users that are following or followed by
 a large number of other users, you've probably run into lag and server
 errors.

 In two weeks, we'll be addressing this with a change in back-end
 infrastructure. The page parameter will be replaced with a cursor
 parameter, which in turn will result in a change in the response
 bodies for these two methods. Whereas currently you'd receive an array
 response like this (in JSON):

  [1,2,3,...]

 You will now receive:

  {ids: [1,2,3], next_id: 1231232}

 You can then use the next_id value to paginate through the set:

  /followers/ids.json?cursor=1231232

 To start paginating:

  /followers/ids.json?cursor=-1

 The negative one (-1) indicates that you want to begin paginating.
 When the next_id value is zero (0), you're at the last page.

 Documentation of the new functionality will, of course, be provided on
 the API Wiki in advance of the change going live. If you have any
 questions or concerns, please contact us as soon as possible.

 [1] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids
 [2] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids

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




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

[twitter-dev] Re: tex

2009-07-21 Thread Alex Payne


Please see http://help.twitter.com/ for questions about using Twitter over SMS.

On Mon, Jul 20, 2009 at 20:07, canpaulcanpau...@gmail.com wrote:

 i have a metroPCS cell phone i cant get your texes whats up with that.




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

[twitter-dev] Re: using whitelisted account for getting multiple user statuses

2009-07-21 Thread Alex Payne


It's possible to apply whitelisted rate limits to authenticated
requests, whether the request is made with Basic Auth or OAuth. If the
requesting user is whitelisted, the higher rate limit will take
effect.

On Mon, Jul 20, 2009 at 23:38, BGbinug...@gmail.com wrote:

 My application retrieves status of multiple Twitter users. I have a
 whitelisted account for a username. The Twitter API documentation
 recommends that I use whitelisted IP Addresses to get the statuses.
 However, my IP addresses change pretty often, so I would like to know
 if it is possible to make more than 150 status requests using a
 whitelisted account (OAuth).

 If it isn't possible, what other options do I have?

 Thanks,
 BG




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

[twitter-dev] Re: Matt Sanford, signing off.

2009-07-20 Thread Alex Payne


Matt has done fantastic work while on our team, and will be missed.

Incidentally, if you'd like to work on the API, we're hiring:
http://static.twitter.com/jobvite_frame.html?c=q8X9VfwTjvi=oAYcVfwp,Job.

On Sun, Jul 19, 2009 at 22:05, Doug Williams d...@twitter.com wrote:

 We will certainly miss having you on the team, Matt.

 Regards,
 Doug




 On Fri, Jul 17, 2009 at 11:19 PM, surya sravanthi sravanthi.su...@gmail.com 
 wrote:

 All the bast Matt!!! Thanks for all you
 r help .


 On Sat, Jul 18, 2009 at 2:48 AM, Matt Sanfordm...@twitter.com wrote:
 
  Hi everybody*,
 
     Starting next week I'm not going to be responding to mails on the dev
  list or working on Google Code issues as part of my daily work. I have been
  working on the Search and API/Platform teams here at Twitter since the
  acquisition of Summize a year ago and the time has come for a change. I'm
  leaving both teams to take on the role of technical lead for the new 
  Twitter
  internationalization team. Anybody who's gotten me talking about language
  detection or language-specifics (especially in person) knows this is
  something I have a personal interest in.
     The other team member are going to continue to keep an eye on the dev
  list and the Google Code issues. As always you can email
  a...@twitter.com directly if you need something. I'll continue working on 
  the
  Google Code issues assigned to me or in some cases someone will take them
  over next week. I mostly felt like I should send you all a good bye since
  you're considered an extension of the API/Platform team. This change should
  be fully backward compatible so I didn't see the need for 7-days notice.
 
  Good night, and good luck;
   – Matt Sanford / @mzsanford
      Twitter Dev
 
  * = Who just said Hi, Dr. Nick. out loud? Your cube neighbor thinks 
  you're
  crazy.




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

[twitter-dev] Re: Failed API returning over capacity HTML page content

JD,
Whether talking to the Twitter API or any other API on the web, always check
the response code before attempting to do any processing of the response
body. Proceed only if you got a 200 (or the response code you expected for
that particular operation). Many things can go wrong in the process of
making an HTTP request between your computer and our servers.

On Wed, Jul 15, 2009 at 10:32, J.D. jeremy.d.mul...@gmail.com wrote:


 On Jul 15, 9:09 am, Nick Arnett nick.arn...@gmail.com wrote:
  My code waits a few seconds and tries again if the JSON parse
  fails.  A bunch of fails in a row and it gives up.

 Thanks. I have similar code around the web calls, but had not put it
 around the json parse yet.




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

[twitter-dev] Re: Following metric is null

This is as designed. That attribute is essentially being
deprecated. But in the Streaming API, we don't populate that field
because we don't know who the requesting user is that we want to see
if the target user is following.

On Tue, Jul 14, 2009 at 16:35, Kris Jirapinyo krispyj...@gmail.com wrote:

 Hi all,
Has anyone seen the following field from gardenhose API always
 returning null?  Is this as designed or is it a bug?

 Thanks,
 Kris.




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

[twitter-dev] Re: Following metric is null

That field already exists under a different name: friends_count

On Wed, Jul 15, 2009 at 11:12, Kris Jirapinyo krispyj...@gmail.com wrote:

 So are there plans to add following_count field like followers_count?
 I don't need to know exactly who the user's following, just how many users
 he's following.


 On Wed, Jul 15, 2009 at 10:55 AM, Alex Payne a...@twitter.com wrote:

 This is as designed. That attribute is essentially being
 deprecated. But in the Streaming API, we don't populate that field because 
 we don't know who the requesting user is that we want to see if the target 
 user is following.


 On Tue, Jul 14, 2009 at 16:35, Kris Jirapinyo krispyj...@gmail.comwrote:

 Hi all,
Has anyone seen the following field from gardenhose API always
 returning null?  Is this as designed or is it a bug?

 Thanks,
 Kris.




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





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

[twitter-dev] Re: Rules About Making Money