[twitter-dev] Re: Deprecation Notice: pagination on several methods is being replaced with cursoring on October 26, 2009
I'll pass those numbers along to our App Services team and see what they can do. On Thu, Sep 24, 2009 at 19:07, Dewald Pretorius dpr...@gmail.com wrote: Alex, Thanks for this. Is there any way that response times on the call could be improved? It takes around 4 seconds to retrieve one cursor. When one retrieves the followers/friends of an account with 100,000 of those, with 100 followers/friends per cursor, it takes more than an hour to retrieve all the followers/friends. It's not a train smash issue, it would just be good to have faster response times. I have noticed the same slower response times (measured against 0.4 seconds for other calls) on the social graph methods when using cursors. Dewald -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Please Make 401 Singular In Meaning
That absolutely seems like a bug, or at least an inconsistency - we generally return a 404 when things are missing. Please file an issue and we'll fix it up early next week. On Fri, Sep 25, 2009 at 17:51, Dewald Pretorius dpr...@gmail.com wrote: API folks, could you please, please NOT return 401 Not authorized when an authenticated call with a perfectly valid username and password requests a /queryusername.json where that queryusername happens to be a username that does not exist. Rather return 404. By returning 401 you are making it impossible for me to tell where the actual problem lies and inform the user. Is it with the user's password, or is it because the user wanted information about a Twitter account that does not exist? Dewald -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] About the oneforty application directory
Just wanted to pass on a note from the team at oneforty.com, who recently launched with over 1300 Twitter applications in their directory. Your app might already be on their site. If it's not yet, you can register as a developer and add it. Once you register and claim your app you can promote it with screenshots, descriptions, tags, and reviews. If you saw the early alpha version of oneforty, it's much improved - real home page, most popular apps ranking and essentials. New item pages just launched and look much better than the prototype did. Their team working on the ability to sell apps right on the site. They're also definitely looking for your feedback. @freerobby, @graysky, @macasek, and @pistachio are often in the #twitterapi IRC channel. There's more contact info below, too. A note from the oneforty team and info on how to register, claim, edit add stuff: We built oneforty to help the best stuff being built on the Twitter API get found and get profitable. Come claim your apps, add content and add new projects in the Twitter appstore oneforty.com To get started: Sign in via oauth. (We whitelisted as many dev usernames as we could find. If you can't login already use invite code TWAPI and we'll let you right in.) Register as a developer: http://oneforty.com/me/developer_profile Search for and claim your app (Suggest Item if we don't have it yet!) Check out your item's page, make sure it's tagged well, tweet a link to it, etc Once approved, add details, screenshots, media coverage and more In the near future you'll be able to offer things for sale right in oneforty. For now we link to your sites and (optionally) let you collect donations. We want to help you get your app found, rated, reviewed and into the hands of the users who need it the most. We also want to get the Twitter community to do a better job supporting developers and apps so that your innovation can flourish. It's frustrating when great apps go defunct because of server costs, etc. We're anticipating decent blog and press coverage, so we want your to look its best! Please let us know whatever we can do to help you. Thank you. We'd really love to know what you think and what you want: Uservice feedback forum. Any questions at all, develop...@oneforty.com or 617-645-7767, anytime. oneforty Founder Laura (@Pistachio) Fitton will be at events in Fort Worth 9/25, Seattle 9/26-27, SF/bay area 9/27-30 and Boston 10/1 and would love to meet you (see http://bit.ly/tour140 for Tweetup event info). She also wrote Twitter for Dummies. Check 'em out! -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Deprecation Notice: pagination on several methods is being replaced with cursoring on October 26, 2009
Hi, Recently, we documented a new pagination mechanism for our social graph methods, /friends/ids and /followers/ids. Traditional page-based pagination doesn't dovetail with our recent backend changes, and we've now exposed a cursor-based pagination mechanism that's far more reliable. Today, we've documented that this new pagination mechanism is also available for the /statuses/friends and /statuses/followers methods. With that change, we're setting a hard deprecation date for traditional pagination on these four methods: October 26th, 2009. That's over a month from now. Once deprecated, we'll simply ignore the page parameter if it's sent by a client, and you'll get the default number of items for the method you're calling. For more information, see http://apiwiki.twitter.com/Twitter-API-Documentation. Thanks. -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Comments for the group and Twitter staff
For applications like yours, moving to the Streaming API will increase the quality of service for you and decrease load for us. A big part of building an effective application on our API is figuring out which methods to use and what strategies to use for retrieving information and sending updates and direct messages. If you reach out to us (a...@twitter.com), we're happy to help with that. Often times, we don't hear from unhappy developers until they're already outraged and posting on their blogs or in this group. Please: give us a chance to help you out first. We may not always be able to make your particular issues our highest priority, but we'll give it our best shot. If you're still pissed, then you can go vent :) And yes, reporting bugs with detailed debugging output (HTTP requests and responses with all headers and full response bodies) are incredibly useful. We essentially can't help you without this information for any non-trivial bugs. Another huge help to us: if you know anyone who either wants to join our team as an engineer or help us out with full- or part-time developer support, please send them to http://twitter.com/jobs. We're a very small team with a very big job, but we've got the funding to add more people. Please, please, please send good people our way! Every addition to the team helps us help you. On Wed, Sep 16, 2009 at 03:13, Fabien Penso fabienpe...@gmail.com wrote: On Wed, Sep 16, 2009 at 7:00 AM, Matthew Ranney m...@ranney.com wrote: Hey Alex, would you consider just giving everybody their money back if they aren't 100% satisfied? Hi guys. I have been developing an iPhone application for push called notifications : www.appnotifications.com I've added Gmail push, RSS, Google voice, I provide an API for sending yourself notifications, and of course I've added Twitter too. I've had some support from some Twitter developers and I'm happy I did. However, to reply to the subject of this thread I also had many issues with the API, some tweets not showing up for example. The complains I get from users is all about the Twitter plugin I did, I almost regret to have added it. I might have done something wrong on my side, but I also have the feelings, like other people here, than the API is not always working well. And I don't blame anyone, I think with the number of tweets you have, and the massive number of new users you had within the last year, it must be a super exciting job to work at Twitter, but also such a stressed one :) I wouldn't want to be responsible for scalability there. Is there anything we can do to help you guys? Reporting specific bugs (they are sometimes hard to find and hard to reproduce as it's a stream). -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Comments for the group and Twitter staff
I completely agree. As I said, we can't always make someone's pet issue our top priority. Given that we have basically 2.5 full-time engineers on our team, that can mean waiting weeks or months for a fix to a lower-priority issue. But we should absolutely be communicating during that wait, and the author of that post has every right to be pissed. One thing I have noticed, though, is developers going through our user support track (via http://help.twitter.com) rather than contacting the Platform Team via a...@twitter.com or by filing an issue on our issue tracker. Our user support folks try their best, but they're often not able to answer developer questions and are likely to hand that issue off to our team and close the ticket. Contacting us developer-facing folks is a much better way to get your issue answered. On Wed, Sep 16, 2009 at 13:21, zippy_monster alex.zep...@gmail.com wrote: On Sep 16, 10:37 am, Alex Payne a...@twitter.com wrote: Often times, we don't hear from unhappy developers until they're already outraged and posting on their blogs or in this group. Please: give us a chance to help you out first. We may not always be able to make your particular issues our highest priority, but we'll give it our best shot. If you're still pissed, then you can go vent :) Well take a look at the grumbling about the OAuth stuff. Mixed in with complaints about OAuth are complaints about Twitter support being non-responsive. Take a look at this from earlier this month: http://homeculinaire.blogspot.com/2009/01/twitter-support-your- problems-are-far.html That person was waiting two months(!) for a response, only to have his support tickets deleted. I suspect a lot of the unhappy bloggers have indeed tried to contact Twitter, and that this group (and the blogs) are an outlet of last resort. Understaffed or not, that sucks for the developers. -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Comments for the group and Twitter staff
Generally, the folks on the Platform Team aren't set up with accounts for the user-facing support system. That's why we try to keep things on the Google Code issue tracker - it's in public, it's easier for our team to manage, and it's easier for other developers to discover bugs so we get fewer duplicates. On Wed, Sep 16, 2009 at 13:47, zippy_monster alex.zep...@gmail.com wrote: On Sep 16, 1:41 pm, Alex Payne a...@twitter.com wrote: One thing I have noticed, though, is developers going through our user support track (viahttp://help.twitter.com) rather than contacting the Platform Team via a...@twitter.com or by filing an issue on our issue tracker. Our user support folks try their best, but they're often not able to answer developer questions and are likely to hand that issue off to our team and close the ticket. Contacting us developer-facing folks is a much better way to get your issue answered. Do developers not use or respond to the support tickets directly? - alex -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Default profile pics
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] Alert: Twitpocalypse II coming Friday, September 11th - make sure you can handle large status IDs!
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?
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!
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
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?
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: Either destroy is/was failing, or my understanding of destroy is/was failing
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] 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
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
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...
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
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
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...
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
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
it instead of their public ID to access associated sites such as twitpic or twxlate. In fact, I think this change, though potentially large on the twitter side, could be implemented without any changes to users or associated sites, with one small, obscure exception: now, if I attempt to create a new twitter account or change the ID of an existing account, and find that the ID I want is in use, I can view that account; if this were implemented and I attempted to use a private ID that was not the same as its associated public ID, I could not view the account using the ... read more » -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] 2 week advance notice: changes to /friends/ids and /followers/ids
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
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
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
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.
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
Lots of people are making money via Twitter. Some sell their applications, others post ads directly on Twitter, others use Twitter content on their sites and include ads there; there are many different possible business models. As long as you stay within our terms of service - which, of course, may be updated at our discretion, so stay current - you should be fine. We do actively police spam and abusive behavior. Some people's conception of legitimate business, it turns out, is everyone else's conception of unsolicited and aggressive marketing. Don't do that. On Wed, Jul 15, 2009 at 13:30, MakeMoney chicagolocalde...@gmail.comwrote: I have a business plan and I am looking to role it out. It involves using Twitter as a median. I have already gotten interest from parties willing to pay for my service, but I beleive it may infringe upon how Twitter will eventually make money. I do not want to invest in this service, and then have Twitter shut it down to replace it with their own. I sent Twitter an email today asking them for a possible discussion time, but I am guessing they get a ton of these and most likely won't respond. If not does anyone know the legality of using there service to make money? And the legality of them being able to shut off my account? Thanks. -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Is it okay to close a connection by opening a new one?
If you're only doing this every hour, that's fine by us. On Tue, Jul 14, 2009 at 15:58, owkaye owk...@gmail.com wrote: The Streaming API docs say we should avoid opening new connections with the same user:pass when that user already has a connection open. But I'm hoping it is okay to do this every hour or so, here's why: My plan is to write the streaming XML data to a text file during each connection -- but I don't want this file to get so big that I have trouble processing it on the back end. Therefore I want to rotate these files every hour ... This means I have to stop writing to the file, close it, move it somewhere else, and create a new file so I can use the new file to continue storing new streaming XML data. The obvious way for me to close these files is to close the connection -- by opening a new connection -- because from what I've read it seems that opening a new connection forces the previous connection to close. Can I do this without running into any black listing or denial of service issues? I mean, is this an acceptable way to close a connection ... by opening a new one in order to force the old connection to close? Any info you can provide that will clarify this issue is greatly appreciated, thanks! Owkaye -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Want to develop a Twitter app/bot for Google Wave?
Do you have a killer Twitter idea for Google Wave? Didn't get into the beta? The Wave team has generously offered up to 100 sandbox accounts to Twitter developers who want to experiment. We're looking forward to seeing what you build. If you're interested, please fill out http://spreadsheets.google.com/viewform?formkey=dHpOUzhhR2ExOTlhamFQM0ktV1Awa3c6MA .. Enjoy! -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Geo location?
Not just yet, but we're working on it. On Tue, Jul 14, 2009 at 16:48, Brother obran...@gmail.com wrote: Can we pass geo tag in status or direct messages? Have not seen this in API but have heard there is or will be support for this. B- -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: updating follow/shadow/birddog list of users
Yes, it's a bit of a pain right now. Long term, we intend on providing methods in the REST API that you can call from another process, while connected to the Streaming API. Those methods will allow you to add and remove user IDs from the list of users you're getting streaming updates from. On Wed, Jul 8, 2009 at 12:17, braver delivera...@gmail.com wrote: Uf you have thousands of users, do you really have to cook up a following file with comma-separated say 100,000 user IDs? Should it all be on one line? Now what happens if we want to drop some and add some IDs -- do we have to restart and re-upload all that list again? I see when the curl -d @following ... starts up, it does that. Restarting with huge lists sounds like data loss... Cheers, Alexy -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Spamming via addition of trending words to tweets
Anyone can send a Direct Message to @spam with the username of a potential spammer. We factor those reports into our automated spam detection tools. We're well aware of the issue, and we appreciate the help. On Tue, Jul 7, 2009 at 15:41, Jeffrey Greenberg jeffreygreenb...@gmail.comwrote: So i'm seeing a ton of tweet spam that appends the trending topics to the tweet. For example, Hey here is my http://spam/1234 Michael Jackson MJ iran They get picked up by searches ( for instance see the search stock market at http://www.tweettronics.com ) What is Twitter doing or planning on doing to deal with this? It has been noted elsewhere that any tweet with 3 or more trending topics is likely to be spam... Will Twiitter institute an automated spam rejection through the API let alone through it's other interfaces? I suppose we've entered the era of dealing with Twitter spam with all our apps... ugh Please advise jeffrey greenberg http://www.jeffrey-greenberg.com http://www.tweettronics.com -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Aquí 1.0 released today
Nice and simple. Thanks! On Thu, Jul 2, 2009 at 09:47, Charles Choi kickingve...@gmail.com wrote: A heads up that I've just published an iPhone Twitter client called Aquí that lets you tweet your Google Maps location with a single push- button operation. Thanks for all the input here that helped me build this app. Here's the URL for Aquí: http://www.yummymelon.com/aqui Best regards - -Charles -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Security Best Practices
The simplest solution is that every deployment of the tool will have to register for their own OAuth credentials. This isn't ideal. I'd inquire over at http://groups.google.com/group/oauth On Tue, Jun 30, 2009 at 06:04, DWRoelands duane.roela...@gmail.com wrote: This is really an excellent question. If we're developing an open-source Twitter client, how are we supposed to handle the consumer_key and consumer_key_secret? On Jun 29, 7:58 pm, Support supp...@yourhead.com wrote: 2. Obfuscation of the application's registered key and secret. Are there any best practices? What about an open source project? -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Security Best Practices
That's a solution that better fits open source Twitter web services. For an open source desktop client like Spaz it certainly doesn't work. On Tue, Jun 30, 2009 at 16:37, DWRoelands duane.roela...@gmail.com wrote: Wait, the solution is that every -user- of an open-source Twitter client would have to register for their own set of -consumer- keys? That's not what you meant, is it? On Jun 30, 4:39 pm, Alex Payne a...@twitter.com wrote: The simplest solution is that every deployment of the tool will have to register for their own OAuth credentials. This isn't ideal. I'd inquire over athttp://groups.google.com/group/oauth On Tue, Jun 30, 2009 at 06:04, DWRoelands duane.roela...@gmail.com wrote: This is really an excellent question. If we're developing an open-source Twitter client, how are we supposed to handle the consumer_key and consumer_key_secret? On Jun 29, 7:58 pm, Support supp...@yourhead.com wrote: 2. Obfuscation of the application's registered key and secret. Are there any best practices? What about an open source project? -- Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Security Best Practices
I wanted to point out a blog post ( http://apiblog.twitter.com/security-best-practices-for-twitter-apps) that addresses the coming Month of Twitter Bugs. Long story short: Twitter is in the loop, we've got security at the forefront of our daily work right now, and we're available to help if your application is identified as vulnerable or compromised. Please check out the new wiki page ( http://apiwiki.twitter.com/Security-Best-Practices) and let us know what's missing. Thanks! -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Security Best Practices
Any recent celebrity-related compromises I'm aware of having been, as you said, media 'hacking'. The last issue I'm aware of that resulted from actually taking advantage of a security flaw in our system was the Mikeyy worm that was going around for a weekend several months ago. We've done a lot of security work since then, and there's more in progress. On Mon, Jun 29, 2009 at 15:40, Scott Haneda talkli...@newgeo.com wrote: I heard the other day that in the wake of the MJ stuff, a few high profile celebs accounts where hacked. Is this media hacking and there were just weak passwords, or their email accounts were compromised, or were these real live hacks where someone brute forced, or did otherwise nefarious acts to get in. Some clarification on these events would help to let us know where and how people are getting in, so we can tighten things up on our end. If the hacks are just email accounts being gotten into, there is nothing twitter apps need to do. If it is something else, there may be other things we can do to keep the accounts safe. Thanks. On Jun 29, 2009, at 3:34 PM, Alex Payne wrote: I wanted to point out a blog post ( http://apiblog.twitter.com/security-best-practices-for-twitter-apps) that addresses the coming Month of Twitter Bugs. Long story short: Twitter is in the loop, we've got security at the forefront of our daily work right now, and we're available to help if your application is identified as vulnerable or compromised. Please check out the new wiki page ( http://apiwiki.twitter.com/Security-Best-Practices) and let us know what's missing. Thanks! -- Scott * If you contact me off list replace talklists@ with scott@ * -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Security Best Practices
We're in contact with TwitPic's developer, and we reach out to developers with security issues. We want to keep the barrier to entry as low as possible on the Twitter platform, and a vetting system doesn't dovetail with that philosophy. On Mon, Jun 29, 2009 at 16:03, Scott Haneda talkli...@newgeo.com wrote: Got to love these headlines: http://mashable.com/2009/06/28/britney-spears-dead/ They clearly point the finger at twitter in the headline, but reading on, and it is clearly a twit pic issue. I see these all over the place. Have you considered some sort of vetting system for sites that are asking for twitter credentials on a 3rd party site? I can see that twitpic may not be able to use o-auth, as they want to be able to stand alone and a image host. If there was some sort of communication where you worked with the large sites like twit pic, it may help. As it is now, I fell for it, I read the headline, and thought ti was a twitter issue. Just some food for thought. On Jun 29, 2009, at 3:54 PM, Alex Payne wrote: Any recent celebrity-related compromises I'm aware of having been, as you said, media 'hacking'. The last issue I'm aware of that resulted from actually taking advantage of a security flaw in our system was the Mikeyy worm that was going around for a weekend several months ago. We've done a lot of security work since then, and there's more in progress. On Mon, Jun 29, 2009 at 15:40, Scott Haneda talkli...@newgeo.com wrote: I heard the other day that in the wake of the MJ stuff, a few high profile celebs accounts where hacked. Is this media hacking and there were just weak passwords, or their email accounts were compromised, or were these real live hacks where someone brute forced, or did otherwise nefarious acts to get in. Some clarification on these events would help to let us know where and how people are getting in, so we can tighten things up on our end. If the hacks are just email accounts being gotten into, there is nothing twitter apps need to do. If it is something else, there may be other things we can do to keep the accounts safe. -- Scott * If you contact me off list replace talklists@ with scott@ * -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Security Best Practices
Apologies, these two sections were under the wrong heading. On Mon, Jun 29, 2009 at 16:32, Support supp...@yourhead.com wrote: Hi Alex, I just thought I'd give you some feedback on the Desktop Application Security section here: http://apiwiki.twitter.com/Security-Best-Practices#DesktopApplicationSecurity Both of the sections below seem to be subheadings under this topic: 1. Under this heading the sub-section of the document titled Lack of Rate Limiting states that we should use a CAPTCHA to slow down hackers. This didn't make much sense to me as when I think of Desktop Application I think of the few that I've used: Twitteriffic, Tweetie, and Destroy Twitter. All of those have direct control of their UI. Although a CAPTCHA could be used to limit scripted behaviors, it would probably be more effective just to directly limit the resource. It's not that a CAPTCHA *couldn't* be used, it's just not something I see very often in a desktop application. It seems to me that CAPTCHA would be more appropriate for a multi-user service than a single user desktop app -- so I was wondering if this section of the document was in the wrong area. 2. Under the sub-section Lack of Information about Threats, it begins, If you think there's an issue with your web application, how do you find out for sure? This is clearly at least a typo in the *desktop* app section, but it goes on to describe creating a dashboard of critical stats. Again, this would make more sense in the context of service administrator, but I'm having trouble understanding what this would mean to a desktop application developer. Am I misunderstanding what is meant by Desktop Application? Does that mean something other than the examples I mentioned? Thanks, Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jun 29, 2009, at 3:34 PM, Alex Payne wrote: I wanted to point out a blog post ( http://apiblog.twitter.com/security-best-practices-for-twitter-apps) that addresses the coming Month of Twitter Bugs. Long story short: Twitter is in the loop, we've got security at the forefront of our daily work right now, and we're available to help if your application is identified as vulnerable or compromised. Please check out the new wiki page ( http://apiwiki.twitter.com/Security-Best-Practices) and let us know what's missing. Thanks! -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: tool to let you know when twitter name is available
Please keep in mind that we keep deleted accounts around for a while, in case users want to restore their accounts. @yourfavoriteusername might appear to be available (that is, you get a 404 when you visit it), but that doesn't mean you'll be able to sign up with it until we've given the original account holder a fair amount of time to reconsider. Handy tool, though! On Wed, Jun 24, 2009 at 09:24, sull sullele...@gmail.com wrote: nice. i've used http://www.changedetect.com for this in the past. will give your service a try. On Jun 24, 2:22 am, drew pushespr...@gmail.com wrote: Hi everyone, I wrote a quick tool to email you when the Twitter name you want is available:http://www.tweettaker.com/ It seems Twitter currently might not be deleting inactive accounts, but they plan to resume automatically deleting them in the future. Any feedback is appreciated. Thanks, Drew -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: WWDC Twitter developer meetup at Twitter HQ: RSVP!
Yup! Wednesday, 5pm. On Thu, May 28, 2009 at 16:08, Damon Clinkscales sca...@pobox.com wrote: Hey Alex/Matt/Doug when you think this can be decided? Can Wed. at 5pm work for the meetup? Thanks, -damon On Thu, May 28, 2009 at 1:49 PM, Pablo Lopez pablitolo...@gmail.com wrote: Count me in too!! On May 21, 5:18 pm, Alex Payne a...@twitter.com wrote: Hi all, There's great crossover between Twitter API developers and Mac/iPhone developers. Andrew Stone, developer of Twittelator Pro, suggested that we all get together during WWDC and coordinate around the Apple Push Notification Service and other issues of mutual interest. Twitter's offices are just a few blocks from Moscone, so it should be easy for any interested coders to make it over here. Please RSVP with a reply to this thread and let us know what dates and times work for you. Andrew was thinking early one morning, but not being much of a morning person, I'd prefer something later in the day. We'll let group consensus decide. Thanks, and hope to see you in early June. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: all replies by friends
it right. Blaming lack of use on a bad UI is just lazy. Twitter is a transport. Different people use it very differently. What Twitter just did is like someone taking email and deciding that mailing lists aren't really very important, since they are used by very few people, so we'll just remove the ability to have a mailing list. After all, it simplifies authentication, and it reduces traffic. Unfortunately, a core set of very important people really, really need mailing lists. It's how they network, meet people, develop ideas, and improve software like... Twitter. Oops. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Social Graph Dump
No. Providing a complete picture of Twitter's social graph is not a goal of our API. We provide portions of the social graph relevant to particular users. On Fri, Apr 24, 2009 at 03:06, Lakshman Prasad scorpion...@gmail.com wrote: Hi, Is there a dump of the twiiter social graph available anywhere, rather than making so many api calls to obtain the same? Thanks. -- Regards, Lakshman becomingguru.com lakshmanprasad.com -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: OAUTH Feature currently disabled
I've started a new thread about this issue. This thread is now closed. On Wed, Apr 22, 2009 at 13:23, Pud pkap...@gmail.com wrote: Official statement from Twitter: http://blog.twitter.com/2009/04/whats-deal-with-oauth.html On Apr 22, 1:20 pm, Dossy Shiobara do...@panoptic.com wrote: On 4/22/09 3:43 PM, Jesse Stay wrote: Why are we learning this from CNet? Transparency. -- Dossy Shiobara | do...@panoptic.com |http://dossy.org/ Panoptic Computer Network |http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
My understanding is, at present, that OAuth consumers are not impacted by this issue. On Wed, Apr 22, 2009 at 13:29, Dossy Shiobara do...@panoptic.com wrote: On 4/22/09 4:27 PM, Alex Payne wrote: In cooperation with this consortium of other OAuth providers (including Yahoo!, Google, Netflix, etc.), we agreed not to disclose the nature of the vulnerability, nor even that a vulnerability existed, until all members of the group agreed to do so. I apologize for what must have seemed unnecessarily tight-lipped communication around this issue, but please understand that we and the other companies involved are trying to mitigate the impact of this vulnerability as much as possible. Can you at least disclose whether OAuth _consumers_ who leave their OAuth callback endpoints up are exposing themselves to risk? -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
We don't consider source registration a key feature. It's an incentive we provide to our developers. We wanted to encourage new developers to look into OAuth. It won't be in beta forever, after all. We have to balance the reality of testing a new technology in our stack with encouraging that technology's adoption. OAuth will provide the Twitter developer community with a number of benefits, and that's the direction in which we want to move, even while there are kinks to work out. On Wed, Apr 22, 2009 at 15:37, bwannon bwan...@gmail.com wrote: If beta for you guys means still in testing, not suitable for production use, then why depreciate key features from basic auth like source registration before you have a production ready release? On Apr 22, 3:27 pm, Alex Payne a...@twitter.com wrote: http://blog.twitter.com/2009/04/whats-deal-with-oauth.html In short: there's a security issue with OAuth, and the major OAuth providers are working together to patch the vulnerability before information about the issue is publicly released. That information will be available athttp://oauth.net/at midnight, PST. In cooperation with this consortium of other OAuth providers (including Yahoo!, Google, Netflix, etc.), we agreed not to disclose the nature of the vulnerability, nor even that a vulnerability existed, until all members of the group agreed to do so. I apologize for what must have seemed unnecessarily tight-lipped communication around this issue, but please understand that we and the other companies involved are trying to mitigate the impact of this vulnerability as much as possible. Please also note that our OAuth support is in beta, albeit public beta. We have not suggested to developers that they rely solely on OAuth until our support of the standard leaves beta. I know that some companies practice a policy of perpetual beta, but at Twitter, we do not. For us, beta really means still in testing, not suitable for production use. Thanks for your patience and understanding. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: This Feature is Temporarily Disabled OAuth Authenticate
Yes. There's an issue with our OAuth implementation that we're currently working to resolve. Please keep in mind that OAuth is still in beta, albeit in public data. We expect a resolution to this issue in the next 48 hours. On Mon, Apr 20, 2009 at 14:55, Jesse Stay jesses...@gmail.com wrote: I'm getting This Feature is Temporarily Disabled when running oauth/authenticate - is it down right now? @Jesse -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Fast140 Dodginess and OAuth Authorization Clarity
means
(like Flickr does) to prevent further surprises. I'm not sure
users
appreciate that an authorised app can:
* Post and delete tweets in your name
* Add and remove users you are following
* Block and unblock users
* Change your name, email address, location, avatar or
description
Thoughts?
This is an excellent point.
--
personal:
http://www.cameronkaiser.com/--
Cameron Kaiser * Floodgap Systems *www.floodgap.com*
ckai...@floodgap.com
-- Sarcasm is a spiritual gift. -- Paul Austin
--
Abraham Williams |http://the.hackerconundrum.com
Hacker |http://abrah.am|http://twitter.com/abraham
Web608 | Community Evangelist |http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States
--
:: Rod Begbie ::http://groovymother.com/::
--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x
[twitter-dev] Re: API Limit
We always supply a reason when rejecting whitelisting requests. That reason should be in the body of the rejection email. If you create a bunch of accounts, our spam team is likely to suspend them. Please address the issues mentioned in the rejection email and re-apply. On Thu, Apr 16, 2009 at 12:34, Brandon Geiger bran...@swarmforce.com wrote: Our users continue to complain about hitting API limits for our app. I applied to get whitelisted, but got rejected. I'm thinking of creating several test accounts that run the more intensive API call procedures as cron jobs, to not use our users' api calls. Any idea why we got rejected? (app name is Swattr) Any objections to this approach? -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: acceptable Profile Image Formats
Yes, and going forward, even GIFs won't be allowed, though some remain in our system. On Thu, Apr 16, 2009 at 14:55, TjL luo...@gmail.com wrote: http://apiwiki.twitter.com/REST+API+Documentation#account/updateprofileimage says image. Required. Must be a valid GIF, JPG, or PNG image So it's safe to assume that anything I pull out of profile_image_url is going to be either .gif or .jpg or .png? TjL -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: list of blocked users
Not presently, but we'll be adding those methods shortly. On Wed, Apr 15, 2009 at 11:09, peterhoneyman peter.honey...@gmail.com wrote: does the twitter api allow me to retrieve the list of users that i have blocked? -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Objective-C/Cocoa open source Twitter client
Very nice. Added to http://apiwiki.twitter.com/Open-source (and tweeted about - hope you get some more contributors). On Wed, Apr 15, 2009 at 07:12, Nick Toumpelis nicktoumpe...@gmail.com wrote: Hi, Just wanted to let everyone know that I've released my (beta) Obj-C/Cocoa twitter client (Canary) as open source here: http://github.com/macsphere/canary, under an MIT-style license. It is a fully-fledged client, with multi-user support, multiple timelines, filters, TwitPic support, automatic URL shortening, iTunes integration etc. Plus, you can do anything you like with the code. :) It uses some third-party code like Growl, Sparkle and BWToolkit controls and icons that are open to use. This is the culmination of my learning experience (though there is still much to learn) but I wanted to give something back to the community as I've gained so much by them. I would also appreciate any feedback. Hope it's of use to you, Nick Nick Toumpelis email: n...@toumpelis.me.uk twitter: macsphere -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: How to add an open source project into wiki?
Done! On Wed, Apr 15, 2009 at 03:54, Gary Zhao garyz...@gmail.com wrote: Could you add my project into the open source project list? http://code.google.com/p/twitterbeis/ Thanks Gary On Thu, Apr 2, 2009 at 10:24 AM, Alex Payne a...@twitter.com wrote: Just let us know what you'd like to add. Unfortunately, we haven't been able to run the wiki in the open due to PBwiki's lack of spam protection. On Wed, Apr 1, 2009 at 19:51, Gary Zhao garyz...@gmail.com wrote: http://apiwiki.twitter.com/Libraries and http://apiwiki.twitter.com/Open-source Thanks -- Gary http://twitter.com/garyzhao -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x -- Gary http://twitter.com/garyzhao -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: IP Address range
You're probably better off writing the firewall rule by domain, if possible. Our IP ranges are going to change and grow, and they'll be hard to keep track of. On Tue, Apr 14, 2009 at 15:12, billbarn42 billbar...@gmail.com wrote: I've got a python script that is monitoring the playlist for our local public radio station, and tweeting when new tracks come up. It is using @wdav as the twitter ID (although that is not relevant to this question...) I am using the twitter.py library to wrap the twitter api. Runs fine on my local laptop, but when I deployed it to my hosted server I had to tell them an IP address it was posting to so they could implement a firewall rule to let the traffic through. I gave them 128.121.146.100, since that's what comes back from a ping to twitter.com. The problem is that it seems the script is frequently trying to use other ip addresses to reach twitter. Is there a range of IP addresses that might be valid Twitter endpoints, that I need to pass on to the hosted server admin team? Any help greatly appreciated! Bill -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Max length of Twitter screen name?
20 characters. On Wed, Apr 15, 2009 at 10:26, Knave archkn...@gmail.com wrote: Does anyone know how long a Twitter screen name can be? Trying to calculate storage space requirements. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: update_profile_image not updating user's profile_image_url
What Cameron said. The first 401 is our servers saying, you need to identify yourself. Once that happens, the request seems to go through. On Tue, Apr 14, 2009 at 08:36, Cameron Kaiser spec...@floodgap.com wrote: Thanks, I have sent you a Charles bebug output. Interesting to see is that with a request I first get a 401 unauthorised error. Strictly speaking, per the HTTP spec, clients should not reply with authentication information to a resource that has not first requested it. The 401 is to make that possible. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Never eat more than you can lift. -- Miss Piggy -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: public_timeline, invalid profile_image?
Yes. We're testing a system that will replace the public timeline method for frequent requesters. On Mon, Apr 13, 2009 at 21:44, Eric Martin emarti...@gmail.com wrote: Alex - seems to still be an issue. Any updates on when we might see a fix? On Mar 30, 12:49 pm, Alex Payne a...@twitter.com wrote: We're on this. Thanks for the reports. On Sun, Mar 29, 2009 at 18:27, Gary Zhao garyz...@gmail.com wrote: I'm seeing it too. 2009/3/29 Günter Grodotzki guen...@grodotzki.ph since some days I am always getting: http://static.twitter.com/images/default_profile_normal.png as profile-image from the user via public-timeline (Data-mining-feed). I checked the announcement-google-group + twitter.com/twitterapi (subscribed to feed anyway ;) ) but could not see any change. The site affected:www.geoheartbeat.com -- Gary http://twitter.com/garyzhao -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: New Ruby Twitter API Library: Grackle
Thanks, Hayes. Added to http://apiwiki.twitter.com/Libraries On Mon, Apr 13, 2009 at 09:19, Hayes Davis ha...@appozite.com wrote: Hi all, Just wanted to let everyone know that I've released a new Ruby Twitter API library called Grackle. It's at http://github.com/hayesdavis/grackle It works with both the search and REST APIs and supports both basic and OAuth authentication. The main thing that sets it apart is that it's designed to be resilient in the face of changes to the API. Everything's dynamic, so new API methods, changes to parameters or modifications to returned data don't require changes to the library itself. That has been quite helpful in my projects (and others that use it as well) as the guys move forward very quickly with new API functionality. Would it be possible to have it included among the available libraries on the wiki? Please let me know if you have any feedback, suggestions for improvement, etc. Thanks. Hayes Davis @hayesdavis -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Search queries not working
Yes. Queries are limited to 140 characters. Basha Shaik wrote: Hi, Is there any Length Limit in the query I pass in search API? Regards, Mahaboob Basha Shaik www.netelixir.com http://www.netelixir.com Making Search Work On Sat, Apr 4, 2009 at 10:27 AM, Basha Shaik basha.neteli...@gmail.com mailto:basha.neteli...@gmail.com wrote: Hi Chad, No duplicates are there with this. Thank You Regards, Mahaboob Basha Shaik www.netelixir.com http://www.netelixir.com Making Search Work On Sat, Apr 4, 2009 at 7:29 AM, Basha Shaik basha.neteli...@gmail.com mailto:basha.neteli...@gmail.com wrote: Hi chad, Thank you. I was trying for a query which has only 55 tweets and i have kept 100 as rpp . so i was not getting next_page. when i decreased rpp to 20 and tried i got now. thank you very much. i Will check if any Duplicates occur with these and let you know. Regards, Mahaboob Basha Shaik www.netelixir.com http://www.netelixir.com Making Search Work On Sat, Apr 4, 2009 at 7:06 AM, Chad Etzel jazzyc...@gmail.com mailto:jazzyc...@gmail.com wrote: next_page -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: [twitter-api-announce] A note on our API change policy
We're not strictly an Agile shop, actually, but thanks. On Mon, Apr 13, 2009 at 18:16, James Deville james.devi...@gmail.com wrote: Another point. If you are fundamentally agile, you should have stories and iterations. What if you posted current breaking change stories at the start of the iteration before you started them. Assuming a 1 or 2 week iteration, we get time to comment, and you won't have to hold code back. JD On Sat, Apr 11, 2009 at 1:19 PM, Abraham Williams 4bra...@gmail.com wrote: If versioning is used how long should versions be supported? A week? A month? Lets just say a month for now. If Twitter pushes out changes every 2 days it is possible that there would be 15 versions running at any given time. This is an extreme example but something to think about. On Sat, Apr 11, 2009 at 13:56, Alex Payne a...@twitter.com wrote: Right now, every new machine we get goes immediately into production. Once we have enough machines that we can get ahead of that capacity planning, I think a beta.api.twitter.com is a great idea. And/or versioning. On Sat, Apr 11, 2009 at 11:00, Yu-Shan Fung ambivale...@gmail.com wrote: I second Jesse's suggestion. Having a staging server to test out API changes would help smooth out transitions (though people needs to be careful about what change they make as presumably this will run against prod database). That way your internal developers can directly push code ready for release immediately to staging instead of waiting 5 days. It'll probably also help sanity internally at Twitter. Who knows, with developers hitting the staging API before it goes out, we might even help catch a bug or two once in a while before it goes out :-) Yu-Shan On Sat, Apr 11, 2009 at 2:21 AM, Jesse Stay jesses...@gmail.com wrote: Doug, can you guys do what Facebook is doing, and release it on a beta server somewhere beforehand so we can test it on our apps before you actually release it to the public? A public staging server of some sort. That will keep these surprises from happening, and we can start working out alerts to have in place when things might break our code that go on that beta server. Best of all, it won't ever affect the end user. Keep the releases on that server, then the releases out to the public on a timed release schedule. It might take a little longer to get out to the public, but you'll have a much happier developer base and in turn a much happier end user by doing so. That would be my number one suggestion. Do you guys do any tracking of Twitter itself for developers complaining about the API? I would also think you could gain some insight from that as well. @Jesse On Fri, Apr 10, 2009 at 12:04 PM, Doug Williams d...@twitter.com wrote: Twitter's development model is pragmatically agile where features enter the code base right alongside bug fixes. You can see this in our changelog [1]. What is not clear from the log is that most of the code is written just days before. April 8th's rapid deprecation of the since parameter/If-Modified-Since header (and to a lesser extent, the removal of undocumented HTTP POST access to accounts/verify_credentials) [5] caught a number of developers off guard. The criticism of this hasty change on the impact to hackers and businesses alike was both valid and appropriate. The results from last month's survey [6] lead us to believe that the use of this parameter was minimal and that it was safe to capture performance gains through the deprecation. In hindsight, our sample size was statistically insignificant because we made a mistake. It is apparent we need to make a change towards transparency. Openness demands we give developers a clear line of communication when changes are made that will break current functionality. While these changes are rare, they do happen. As a result of this week's conversation, we will give a minimum of 5 business days notice before we ship code that removes currently documented functionality. Two notable exceptions are critical security and performance fixes. Five days may seem short notice but it is a compromise from our standard. There are two major concerns we must consider when shelving code that is ready for deploy: 1) We do not write unnecessary code. Code only exists in the deploy pipeline for a feature or defect fix that is ready to go out the door. We view deployable code as an asset that should be handling requests as quickly as possible. 2) Un-merged code adds complexity. The Twitter code base is constantly moving. Deploying code requires merging with the master branch which grows in complexity as an undeployed branch sits idle. We currently use the changelog [1], @twitterapi [2], The API Announce List [3], and the Dev Group [4] to inform developers of changes
[twitter-dev] Re: [twitter-api-announce] A note on our API change policy
-- “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 - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Oauth application directory
Not yet, but soon! On Sat, Apr 11, 2009 at 07:17, Alberto Bajo albertob...@gmail.com wrote: Hi guys, Is there any list or directory with applications implementing OAuth? Thanks :) -- Alberto Bajo alber...@ideateca.com http://filesocial.com -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Article about my experiences deploying a Twitter Web app on Google App Engine Java
Handy! On Sat, Apr 11, 2009 at 09:30, Dave Briccetti da...@davebsoft.com wrote: Perhaps this will save time for some of you. http://briccetti.blogspot.com/2009/04/my-first-scala-web-app-on-google-app.html -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: StalkDaily worm - it's really spreading :)
We've been on it for some time. It's actually not really spreading, and hasn't been for hours. Lots of people are talking about it, but the actual attack vector is closed. On Sat, Apr 11, 2009 at 19:05, Dossy Shiobara do...@panoptic.com wrote: I don't know if the Twitter folks are doing anything about it, but the StalkDaily worm is propagating fast. Better remove the user bio from Twitter profile pages and scrub the database ASAP ... -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Retry twitter name from name
There's currently not a way to look up a Twitter user by their real name via the API. On Thu, Apr 9, 2009 at 05:19, Fux funa@gmail.com wrote: Hi. I'm using java to develop a Twitter application. I have the name of a user but I can't retry his7her screen name or ID... Can I do it?I search on google but I didn't find the solution. Thanks. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: http://twitter.com/direct_messages/new.json failed
400 is the response code we return for rate limiting. Are you sure you're making the request using an HTTP POST? What was the body of the response? On Thu, Apr 9, 2009 at 18:22, Gary Zhao garyz...@gmail.com wrote: http://twitter.com/direct_messages/new.json?user=qinqi7text=test I got The remote server returned an error: (400) Bad Request. Anything wrong with this API invocation? Thanks -- Gary http://twitter.com/garyzhao -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Changes for April 8, 2009
Apologies, Dean. We're going to formalize our API release scheduling so this doesn't happen in the future. On Thu, Apr 9, 2009 at 19:01, dean.j.robinson dean.j.robin...@gmail.com wrote: Especially with regards to the deprecation of certain things. I totally missed the topic about the deprecation of the since param which was only posted on the 8th. Reading it now it said: Please use the next few days to update your application to use the since_id parameter if it is currently using since/If-Modified-Since. This deprecation will happen when the deploy hits our server in the middle to end of the week. ...didn't really get the next few days though... since it seems to have been removed on the 9th Although it does explain why I've been getting constant errors in Hahlo 3 (which uses 'since') and not Hahlo 4 (which uses 'since_id') On Apr 10, 2:38 am, Peter Denton petermden...@gmail.com wrote: Seems like a lot of people are on gmail here. I think a google alert would work nice, that way we could get a stand out email. On Thu, Apr 9, 2009 at 9:14 AM, Carlos Crosetti carlos.crose...@gmail.comwrote: I got mu friends timelines btoken today because you changed from POST to get, now I aligned properly. Would be nice from you tellling this changes in advance. Areyou doing release management? Best regards,, Carlos On Thu, Apr 9, 2009 at 12:20 PM, Matt Sanford m...@twitter.com wrote: Hi all, Sorry for the late email but the deploys yesterday ran late and we didn't get a chance to compile the change log. And a doozy of a change log it is with 10 entries. Other things were deployed as well but here are the 10 API-facing changes: * Changed (REST): The since parameter and If-Modified-Since header are no longer supported. » Discussed athttp://bit.ly/19JZme * Fixed (REST): Methods documented as requiring GET were allowing POST and not counting the rate limit correctly. These methods now require GET and return an error message if POST is used. » Discussed athttp://bit.ly/o38Dl * Fixed (REST): The deprecated email parameter was being silently ignored, an error is now returned. » Discussed athttp://bit.ly/4APnTx » See:http://code.google.com/p/twitter-api/issues/detail?id=353 * Fixed (REST): The /users/show.$fmt method now thorws a 404 error if no recognized parameters are given. » This is a part of the previous issue and many complaints about the user @show being returned as a default * Fixed (OAuth): Rate limiting was incorrectly by IP only when using the Authenitcation header. This has been corrected. » See:http://code.google.com/p/twitter-api/issues/detail?id=376 * Fixed (OAuth): Error messaging for OAuth clients is now more detailed. » See:http://code.google.com/p/twitter-api/issues/detail?id=403 * Fixed (REST): Direct message objects were not returning the large user representations in json responses. They will now begin doing so. * Fixed (REST): Calls to direct message XML methods were incorrectly displaying the nilclass root tag. This has been corrected. » See:http://code.google.com/p/twitter-api/issues/detail?id=406 * Feature (REST): Added /direct_messages/show/$id.$fmt method (where $id is the direct message id and $fmt is xml or json) » See:http://code.google.com/p/twitter-api/issues/detail?id=369 » Note: Still needs to be added to the documentation * Feature (OAuth): Added provisional support for Sign in via Twitter for OAuth applications. An official annoucement will follow after full support is available. » More on this to come in subsequent mails. I need to get another piece in place first. There were also a collection of other fixes which included fixing the Sign out link on the OAuth authorization page. Thanks; — Matt Sanford / @mzsanford -- Carlos Crosetti -- Peter M. Dentonwww.twibs.com i...@twibs.com Twibs makes Top 20 apps on Twitter -http://tinyurl.com/bopu6c -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Weird API problem, Invalid requests, et cetera
There's not quite enough output in your email to help you debug this issue. Also, we'd need to know which library you're using for OAuth. On Sun, Apr 5, 2009 at 22:58, agiorlando agiorla...@gmail.com wrote: I uploaded the OAuth live example source code to my server and plugged in my keys. It doesn't work for some reason, the headers it spits back at me after allowing read access are: HTTP/1.1 401 Unauthorized Date: Mon, 06 Apr 2009 05:56:10 GMT Server: hi Status: 401 Unauthorized WWW-Authenticate: Basic realm=Twitter API Cache-Control: no-cache, max-age=1800 Content-Type: application/xml; charset=utf-8 Content-Length: 152 Set-Cookie: _twitter_sess=BAh7BzoHaWQiJTE4ODg3YTZkOTM5MGQ5NzIzODQ0MGM5NmVjMDU0ZWE4Igpm %250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG %250AOgpAdXNlZHsA--7d2be6af75c7d76c08c88ae22f6473709d8a98e2; domain=.twitter.com; path=/ Expires: Mon, 06 Apr 2009 06:26:10 GMT Vary: Accept-Encoding Connection: close It says hi, and that is the weirdest thing to me. :S -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] April 6: emergency maintenance mode, 1 hour, starting at 1600 PST
Extremely sorry for the unexpected loss of service. See http://blog.twitter.com/2009/04/thanks-for-your-patience.html for an explanation. Please watch http://status.twitter.com/ for updates. Back soon. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Determining Sex/Gender with the API?
http://www.beardorbra.com/ On Thu, Apr 2, 2009 at 10:18, Zac Bowling zbowl...@gmail.com wrote: That would be an interesting challenge. Now this would only work with active users and for English users but you could mine out probability index of gender using other data around the user. Basically you could search back on someone's tweets for keywords that allude you to gender. Like someone saying Us girls have it hard. you could assume a high chance of being female. You could also use the search api and look of people talking about the subject in the third person and you are likely to find the pronouns he or she. For example coming across a tweet like I love @zbowling. He is awesome.. Other ideas are looking for other gender specific words like my beard or my bra . Then you might have the privacy advocates (big brother conspiracy nuts) crying fowl though and gender bombing twitter if you release such a service. Zac Bowling http://twitter.com/zbowling On Thu, Apr 2, 2009 at 9:28 AM, kazvor...@gmail.com kazvor...@gmail.com wrote: As the subject line implies, I need to know how to programmatically determine the sex of a profile owner with the API. Is this supported, in any way at all? Not the sex of the person logged in as the app, but the owners of the profiles in a search, for example. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
